Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
petalvik
Да, тесты писать легко. Если уже известна архитектура. А откуда она известа? Из опыта предыдущей работы, из опыта написания тысяч строк кода ранее.

Это демагогия. Если разобрать, что обосновывает этот аргумент, то получится примерно "Он доказывает, что программист-юниор не может первым кодом в своей жизни написать тест". Но этот факт в общем малоинтересен :)

А в контексте нашей беседы он вообще не важен. Точно так же, как Вы сфокусировались на одной из деталей TDD, я в своём ответе сфокусировался на одной из деталей Вашей речи. И Ваш тезис выходит за область обсуждения.

petalvik
softwarer
Хороший тест работает выше уровнем, он проверяет требование к проекту.

О как! Юнит-тесты не считаем?

Именно так. 95% кода типичного проекта не нуждается в покрытии юнит-тестами (скорее наоборот - нуждается в их отсутствии). В оставшихся же тесты опять же сосредоточены на интерфейсной части объекта. То есть, если мы, например, хотим протестировать некий класс контейнера (классический пример для юнит-тестов, а по сути - отдельный подпроект внутри основного), мы будем тестировать методы добавления в контейнер, извлечения, поиска итп - то есть его public методы. Но только круглый идиот полезет тестировать его приватные методы, его реализацию. Интерфейс же подобных объектов опять же весьма стабилен. Рефакторинги в основном сосредотачиваются в реализации, редко добавляются или расширяются публичные методы, ещё реже удаляются. Поэтому и тест довольно стабилен и от рефакторингов существенно не ломается.

petalvik
softwarer
Как следствие, он меняется вместе с требованиями

Заказчик просит: сделать зашибись! Напиши тест.
Я ж говорю: сперва тщательное проектирование, обсуждение с заказчиком, выявление этих самых требований, потом тест. Но не сперва тест, а потом всё остальное.

Ты полез в бутылку, не понимая, на что возражаешь.

Ещё раз: при грамотном подходе к тестированию рефакторинг не приводит к постоянной переделке тестов. Что непонятного?
20 авг 15, 19:14    [18048082]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
petalvik
Я не спорю с TDD, я сам его использую.
Я оспорил один тезис: то, что сперва пишутся тесты, а потом код.

Если бы чукча не был писателем, он бы увидел, что десятком сообщений раньше я оспаривал ровно тот же тезис. Но любой интеллектуально честный человек будет вынужден признать, что если из TDD убрать "tests first", это будет уже не TDD. Это будет некая "методика разработки с использованием автотестов".
20 авг 15, 19:16    [18048089]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
petalvik
White Owl
petalvik,

И вообще, ты можешь конечно спорить с удобством и практичностью TDD, но ты никак не можешь спорить о том что это есть такое.


Прочти внимательно то, что я написал.
Я не спорю с TDD, я сам его использую.

Я оспорил один тезис: то, что сперва пишутся тесты, а потом код.
Ну и зря ты с ним споришь. Этот тезис и является основополагающим принципом TDD. Если ты с этим тезисом споришь, то ты никак не можешь использовать TDD.

Ты можешь использовать тесты в разработке - никаких проблем. Но если ты сначала пишешь код, потом тесты для уже написанного и гоняешь эти тесты чтобы случайно не порушить уже отлаженный кусок, то скорее всего ты используешь IID - Interactive and Incremental Development оно-же "итеративная разработка".

Короче говоря - учи матчасть, потом приходи.
20 авг 15, 19:22    [18048100]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
petalvik
White Owl
ISBN 9780321146533

Раздел "Вначале тест (Test First)".
Пример кода оттуда:
Buffer reply = reader.contents();
assertTrue(reader.isClosed());

Сразу возникает вопрос: откуда автор знает, что после выполнения метода reader.contents() сокет закрывается? Значит, он уже писал код (вначале - код!), использующий сокеты, значит штудировал документацию по сокетам (вначале - проектирование!). И лишь потом - тест.

Я повторю в очередной раз: когда гуру программирования и проектирования пишет сперва тест на ещё несуществующий код, это значит, он уже писал ранее похожий код.
И что?
Мало-ли почему кодер решил написать "такой" тест. Главное: написал он этот тест до того как начал кодировать то что надо тестировать или после. Если ДО, то это TDD, если после, то это уже не TDD а любой другой из множества подходов к организации процесса разработки.
На, почитай: https://en.wikipedia.org/wiki/List_of_software_development_philosophies
Выбирай любой на вкус. Все они могут использовать тесты. В половине тесты обязательны. Но только в Test Driven Development и его потомках тесты надо писать до того как написан код. И совершенно не важно почему был написан именно такой тест а не какой-то другой.
20 авг 15, 19:29    [18048118]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
softwarer
"Он доказывает, что программист-юниор не может первым кодом в своей жизни написать тест".

Вот именно! Джуниор должен накопить опыт, он должен написать кучу кода, а уже потом начать писать сперва тесты. Но это будут тесты на ранее написанный код.

softwarer
Именно так. 95% кода типичного проекта не нуждается в покрытии юнит-тестами (скорее наоборот - нуждается в их отсутствии).

Но дело-то в том, что распространение TDD как раз и получил после начала активного применения юнит-тестирования.

softwarer
Но только круглый идиот полезет тестировать его приватные методы, его реализацию.

Это всё пустые слова. Суть в том, что подавляющее большинство современных языков программирования не позволяют легко и просто тестировать приватные методы. Было бы friend как в C++ - тестировали бы и приватные методы. Ну а нет - значит нет.

softwarer
Интерфейс же подобных объектов опять же весьма стабилен.

Почему он стабилен? Откуда появилась эта стабильность? Из ранее написанных проектов! То есть был написан код, потом не раз переписан, потом интерфейс устаканился. Теперь он стабилен.

softwarer
Рефакторинги в основном сосредотачиваются в реализации, редко добавляются или расширяются публичные методы, ещё реже удаляются.

Тут можно порассуждать о понятиях public (открытый) vs publish (опубликованный). Конечно, когда мы спроектировали (сперва - проект!) интерфейс и опубликовали его, то ломать его не будем. Можно его покрыть тестами.

softwarer
Ты полез в бутылку, не понимая, на что возражаешь.

Повторю в очередной раз: сперва тесты - миф.

softwarer
Ещё раз: при грамотном подходе к тестированию рефакторинг не приводит к постоянной переделке тестов. Что непонятного?

При условии предварительного проектирования, выделения и опубликования интерфейса.
20 авг 15, 19:40    [18048142]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
White Owl
И что?
Мало-ли почему кодер решил написать "такой" тест. Главное: написал он этот тест до того как начал кодировать то что надо тестировать или после. Если ДО, то это TDD, если после, то это уже не TDD а любой другой из множества подходов к организации процесса разработки.

Хорошо. Сперва написали тест. Имеем TDD. Стали писать код. Не получилось. Оказалось, нужно ввести дополнительный параметр в метод (в тесте его нет). Пришлось переписать тест. TDD сразу же исчез?
20 авг 15, 19:48    [18048170]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
petalvik
Вот именно! Джуниор должен накопить опыт, он должен написать кучу кода, а уже потом начать писать сперва тесты.

Технически, для накопления первоначальной порции опыта ему достаточно прочитать одну книжку и пошебуршить сколько-то мыслей у себя в голове. Но в любом случае это рассуждения в пользу бедных. К моменту, когда он приходит в проект, он уже имеет какой-то предыдущий опыт, пусть минимальный, а рассуждения о том, что этот опыт был, и поэтому tests таки не first - пустое словоблудие.

petalvik
Но дело-то в том, что распространение TDD как раз и получил после начала активного применения юнит-тестирования.

Ошибаешься. Про TDD-подобный подход я читал ещё в книге семидесятых годов, и судя по всему, тогда он был распространённее, чем сейчас (в том числе в силу того, что задачи больше подходили под "тесты готовим заранее"). Другой вопрос, что в наш век маркетингово-активных невежд сплошь и рядом старая идея в чуть осовремененной обёртке выдаётся за новое слово и идеологический прорыв.

petalvik
Это всё пустые слова. Суть в том, что подавляющее большинство современных языков программирования не позволяют легко и просто тестировать приватные методы. Было бы friend как в C++ - тестировали бы и приватные методы. Ну а нет - значит нет.

Глупость. Тестирование реализации - идиотизм вне зависимости от её доступности. А концепция friend - одно из многих плохих проектных решений C++, отчасти перекочевавшее в другие инструменты. Скажем, в Яве, если мне не изменяет память, friend-ануты классы внутри пакета - но тестированием private классов таки вменяемые люди... не увлекаются, назовём так.

petalvik
softwarer
Интерфейс же подобных объектов опять же весьма стабилен.

Почему он стабилен? Откуда появилась эта стабильность? Из ранее написанных проектов!

Да нет, как правило из двух моментов. Во-первых, необходимость такого объекта осознаётся тогда, когда в написанной части проекта просматривается отчётливый "спрос" на него. Как следствие, понятны требования и легко и естественно проектируется интерфейс. Во-вторых, подход "не делать того, что пока не требуется" обеспечивает непоявление того, что не обеспечено спросом и как следствие, было бы первым кандидатом на рефакторинг.

petalvik
Повторю в очередной раз: сперва тесты - миф.

Ты можешь ещё миллион раз это повторить, но надеюсь, лет через пять-десять до тебя дойдёт, что с этим никто не спорит.

petalvik
softwarer
Ещё раз: при грамотном подходе к тестированию рефакторинг не приводит к постоянной переделке тестов. Что непонятного?

При условии предварительного проектирования, выделения и опубликования интерфейса.

Именно так. В той книге, о которой я выше говорил, предлагался такой подход: проектируется интерфейс высокого уровня, реализуется с заглушками, делаются тесты, начинается реализация, проектируются интерфейсы следующего уровня....
20 авг 15, 20:07    [18048226]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
petalvik
Хорошо. Сперва написали тест. Имеем TDD. Стали писать код. Не получилось. Оказалось, нужно ввести дополнительный параметр в метод (в тесте его нет). Пришлось переписать тест. TDD сразу же исчез?

Да нет, просто программиста (ну или автора примера ;-) надо наказывать за некомпетентность. Описана опасная болезнь под названием "переделка интерфейса в угоду реализации".

В грамотном подходе не может быть "оказалось, что нужно ввести дополнительный параметр". Потому что список параметров - задан требованиями и меняться может только вместе с требованиями. Если согласно требованиям у метода А должен быть один параметр, а реализации в каком-то месте удобно иметь метод А с двумя параметрами - значит, нужно сделать приватный метод А-прим (с двумя параметрами), а из публичного метода А (с одним параметром) его вызывать.
20 авг 15, 20:11    [18048243]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
petalvik
White Owl
И что?
Мало-ли почему кодер решил написать "такой" тест. Главное: написал он этот тест до того как начал кодировать то что надо тестировать или после. Если ДО, то это TDD, если после, то это уже не TDD а любой другой из множества подходов к организации процесса разработки.

Хорошо. Сперва написали тест. Имеем TDD. Стали писать код. Не получилось. Оказалось, нужно ввести дополнительный параметр в метод (в тесте его нет). Пришлось переписать тест. TDD сразу же исчез?
Если этот дополнительный параметр был сначала добавлен в метод, а потом под этот параметр написали тест - то да, исчез.
Для TDD важно что сначала мы делаем тесты, потом кодируем. Если мы решили что в метод надо добавить параметр, то в духе TDD будет сначала исправить существующий тест (или написать дополнительный тест специально для этого параметра), убедиться что этот тест падает, и только потом начать изменять метод.
20 авг 15, 20:11    [18048244]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
White Owl
то в духе TDD будет сначала исправить существующий тест (или написать дополнительный тест специально для этого параметра), убедиться что этот тест падает, и только потом начать изменять метод.

Что-то мне подсказывает, что "этот тест" будет не "падать", а "не компилироваться" :)
20 авг 15, 20:13    [18048251]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
softwarer
petalvik
Хорошо. Сперва написали тест. Имеем TDD. Стали писать код. Не получилось. Оказалось, нужно ввести дополнительный параметр в метод (в тесте его нет). Пришлось переписать тест. TDD сразу же исчез?

Да нет, просто программиста (ну или автора примера ;-) надо наказывать за некомпетентность. Описана опасная болезнь под названием "переделка интерфейса в угоду реализации".
Это совершенно не важно для темы топика.

softwarer
В грамотном подходе не может быть "оказалось, что нужно ввести дополнительный параметр". Потому что список параметров - задан требованиями и меняться может только вместе с требованиями.
Ну так а требования то могут поменяться. С чего ты вдруг решил что новый параметр появился по плохим причинам?


softwarer
Если согласно требованиям у метода А должен быть один параметр, а реализации в каком-то месте удобно иметь метод А с двумя параметрами - значит, нужно сделать приватный метод А-прим (с двумя параметрами), а из публичного метода А (с одним параметром) его вызывать.
Вовсе не обязательно. Речь может идти о новой версии программы, или вообще о форке. Для рефакторинга может существовать множество причин.
20 авг 15, 20:19    [18048266]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
White Owl
Это совершенно не важно для темы топика

Но важно с точки зрения обсуждения приведённого примера - вернее, его бессмысленности.

White Owl
Ну так а требования то могут поменяться.

Конечно, могут. Но не в процессе реализации кода (то есть - не вследствие того, что программист принимает действия по реализации кода, заданного этими требованиями). Источник изменения требований должен быть внешним - заказчику пришла новая хотелка или типа того. Единственный сценарий, когда источник внутри - если в ходе реализации обнаружена ошибка в требованиях. Но это само по себе караул, это значит, что на предыдущих этапах кто-то.. хлопал ушами.
20 авг 15, 20:29    [18048289]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
softwarer
petalvik
Хорошо. Сперва написали тест. Имеем TDD. Стали писать код. Не получилось. Оказалось, нужно ввести дополнительный параметр в метод (в тесте его нет). Пришлось переписать тест. TDD сразу же исчез?

В грамотном подходе не может быть "оказалось, что нужно ввести дополнительный параметр". Потому что список параметров - задан требованиями и меняться может только вместе с требованиями.

Я и говорю: сперва выявление требований, проектирование, затем - тесты. Но тесты не на первом месте.
Ладно, пусть не параметр. Ещё раз этот пример:
Buffer reply = reader.contents();
assertTrue(reader.isClosed());

Внезапно оказалось, что сокет не закрыт. Тест нужно переписать. TDD исчез? Если да, то я согласен: я не практикую TDD. Как и 99,(9)% разработчиков.

softwarer
проектируется интерфейс высокого уровня, ... делаются тесты, ...

Сперва - проект, потом - тесты. Я удовлетворён.
20 авг 15, 20:52    [18048343]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
White Owl
petalvik
Хорошо. Сперва написали тест. Имеем TDD. Стали писать код. Не получилось. Оказалось, нужно ввести дополнительный параметр в метод (в тесте его нет). Пришлось переписать тест. TDD сразу же исчез?
Если этот дополнительный параметр был сначала добавлен в метод, а потом под этот параметр написали тест - то да, исчез.
Для TDD важно что сначала мы делаем тесты, потом кодируем. Если мы решили что в метод надо добавить параметр, то в духе TDD будет сначала исправить существующий тест (или написать дополнительный тест специально для этого параметра), убедиться что этот тест падает, и только потом начать изменять метод.

Договорились. С такой формулировкой согласен.
20 авг 15, 20:55    [18048357]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
petalvik
Ладно, пусть не параметр. Ещё раз этот пример:
Внезапно оказалось, что сокет не закрыт. Тест нужно переписать.

Это снова изменение требований. Пример в общем не отличается от предыдущего.

petalvik
TDD исчез?

Вы видите где-нибудь в описании TDD запрет на переписывание тестов? Тогда исчез.
20 авг 15, 21:56    [18048566]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
softwarer
Это снова изменение требований.

Нет, требования не изменились, остались прежними. Просто автор теста не знал досконально поведение вызываемого кода/используемой библиотеки.
Знать это поведение он может либо в том случае, когда уже писал код с ней (сперва - код!), либо проведено проектирование с тщательным изучением всего и вся (сперва - проект!). Тест в обоих случаях не первый.
20 авг 15, 22:01    [18048591]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
petalvik
softwarer
Это снова изменение требований.

Нет, требования не изменились, остались прежними. Просто автор теста не знал досконально поведение вызываемого кода/используемой библиотеки.

Всё. TDD исчез

Давайте Вы попробуете объяснить ситуацию - что за код пишет автор, что он тестирует итп? С Вашей точки зрения?
20 авг 15, 22:10    [18048628]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
kmaw
Member [заблокирован]

Откуда: бобруйск
Сообщений: 24786
petalvik
На мой взгляд, главный миф о TDD - то, что тесты нужно писать раньше кода. Это теоретически невозможно!
Сейчас обосную!

В мелких статейках и бложиках многие программеры, едва познакомившиеся с юнит-тестированием, нахватавшись разных (глупых) идей, начинают кукарекать: сперва тесты, потом код!
Но ни в одной серьёзной нормальной большой статье, а тем более в книгах по тестированию я не встречал такой бред. Если кто знает такую книгу - упомяните.

Да, мне неоднократно пытались доказать, что они сперва пишут тесты, а потом код. При внимательном изучении всегда оказывалось, что это не так. Возможны два случая:
1. В прошлом этот разработчик уже писал похожий код в подобном проекте; поэтому в нынешнем проекте он автоматически переносит куски кода оттуда; в таком случае действительно можно сперва написать тесты, а потом код; но на самом-то деле код уже был написан ранее!
2. Сперва ведётся тщательнейшее проектирование, расписывается до мелочей взаимодействие модулей, всё чуть ли не до локальных переменных определено. Пример такого проектирования описан в книге Крэга Лармана "Применение UML и шаблонов проектирования". Дальнейшая работа сводится к тупому кодированию. Вот теперь, после проектирования, можно написать тесты, а потом код. Но тесты не были первыми! Сперва был проект!

Одной из культовых книг считается "Рефакторинг" Фаулера. Если её почитать, то он по ходу повествования постоянно переносит код из одного метода в другой, потом в другой класс, выносит параметры в поля, потом обратно, через несколько итераций возвращает метод в первоначальный класс, но уже с другими параметрами... Вот как тут писать тесты? Написал и тут же выкинул.
Да, если мы не уверены, что в процессе рефакторинга ничего не сломаем, то сперва нужно написать тесты. Но это на уже работающий код. А если код ещё не работает, даже не компилируется, если мы ищем способ как вообще его написать - о каких тестах может идти речь? А если тесты всё же очевидны, тот тут смотри выше два описанных случая: либо похожий проект писался раньше и поэтому код (большая его часть) заранее известен, либо было проведено тщательное проектирование (сперва проект - затем тест и тупое кодирование).

Или вот, например, презенташка http://blacksheep.parry.org/wp-content/uploads/2010/03/State-of-the-Art-Testability.ppt (Java)
Изначально было три класса. Постепенно, в ходе рефакторинга кода для улучшения тестирования (а также уменьшения связности, внедрения зависимостей и пр.) классов стало восемь. Нужно ли было писать тесты на первые три класса? При условии, что вся эта работа по написанию кода была проведена за один день? Имхо, это бессмысленно, да и невозможно: в первой версии методы внутри себя создают другие классы и их нельзя подменить/замокать.

Можно ли было написать сразу конечную версию с восемью легко тестируемыми классами? Можно! При этом сперва можно (и нужно) написать тесты. Казалось бы, я противоречу сам себе (смотрите тезис в первом абзаце). Но дело в том, что чтобы дойти до такого дизайна нужно сперва наломать кучу дров, написать тысячи строк хрупкого сильносвязанного кода, набить шишки. То есть сперва - код! И лишь затем, по прошествии месяцев или лет, набравшись опыта, научиться сходу проектировать легкотестируемый код. То есть, опять же: вначале по-любому будет код - в голове разработчика, код из предыдущих проектов, из опыта. А тесты - потом.



прям мои мысли один в один :)
20 авг 15, 22:46    [18048799]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
ViPRos
Member

Откуда:
Сообщений: 9389
softwarer,

я вот работаю программистом около 40 лет
ни разу не видел ТЗ или что то еще его заменяющее, что бы можно было его прямиком перевести на язык программирования
(хотя видел, но это было тогда, когда считали количество использованных ячеек памяти - но там тестировать ничего не надо было, так как постановка практически один в один соответствовала программе на языке)
обычно ТЗ пишется по ходу или по (очередного :)) окончания проекта
обычно проект завершается только тогда, когда инициатор либо увольняется, либо вырастает
конечно я понимаю что проекты касперского или МС можно и через ТДД и через ПДД писать, так как это их Собственная кухня и понимание
но, пробовали бы они таким макаром написать что нить для росатома или алмаза или мценског спирт завода
я не знаю, где ты трудишься (думаю, где то преподавателем), но ты очень далек от народа российского, или мне всю жисть не везло с местом работы
21 авг 15, 01:00    [18049056]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
ViPRos
Member

Откуда:
Сообщений: 9389
если я потребую, что надо провести обследование или не дай бог попрошу ТЗ на уровне хотя бы точных хотелок (не формализованных хоть как то , а просто список самых важных), я просто не получу проект
я могу показать ТЗ!!!, от которого ты упадешь со стула
короче - он написал 2 абзаца
я переведу одним предложением - хочу видеть МГНОВЕННО любую интересующую информацию по любому аспекту в любом разрезе
я (мы) согласился(ись)
21 авг 15, 01:14    [18049068]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
mayton
Member

Откуда: loopback
Сообщений: 39224
Мне один бизнес на митинге говорил дескыть. Надо сделать так чтоб "было круто".

Мы кивали головами...
21 авг 15, 12:15    [18050712]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
ViPRos
я вот работаю программистом около 40 лет
ни разу не видел ТЗ или что то еще его заменяющее, что бы можно было его прямиком перевести на язык программирования

Я видел. Правда, один раз, но я видел некий документ с названием "детальная спецификация", полностью и подробно описывающий проект. Так, что получил задание "делаешь пункт 2.3.4 и дальше все подряд сколько успеешь", и после этого пару месяцев по сути никого ни о чём не спрашивал, просто сидел и работал (пока соседи делали другие пункты). Заказчиком была РОСНО, если тебе интересно.

ViPRos
обычно ТЗ пишется по ходу или по (очередного :)) окончания проекта

Есть такое. Именно поэтому я очень ценю комментарии (в программном коде) и тесты. Потому что как раз они и составляют наиболее актуальную и достоверную документацию по проекту. Скажем, у меня был случай, когда клиент собирался принимать проект по галочкам - мол, такой-то пункт тз сделан, такой-то сделан, такой-то сделан. И накануне был жуткий шухер, потому что в ТЗ было написано "сделать нечто", а никто (включая клиента) не мог объяснить, что такое это "нечто" и как это должно работать, но при этом принимать он собирался по галочкам - то есть "нечто сделано? работает?" Будешь смеяться, но в итоге, грубо говоря, сделали кнопку "Сделать нечто", просто выдававшую "ОК", и в таком виде сдали проект. А вот тесты... когда есть тест, и он работает, это говорит, что этот сценарий был кому-то нужен, работающий именно так, и по коду теста обычно даже можно понять - зачем.

ViPRos
обычно проект завершается только тогда, когда инициатор либо увольняется, либо вырастает

Это ты говоришь про внутренние проекты. Когда проект на внешнего заказчика, "бесконечность" не устраивает ни одну из сторон.

ViPRos
конечно я понимаю что проекты касперского или МС можно и через ТДД и через ПДД писать, так как это их Собственная кухня

Здесь ты прав. По Бековским методикам - и по XP, и по TDD - хорошо видно, что они предназначены для внутренних разработок, в которых вопрос "уложить эту функциональность в этот бюджет" в общем не стоит. Именно этим обусловлены их широко критикуемые недостатки и провалы при попытках применить "как написано в книгах".

ViPRos
но, пробовали бы они таким макаром написать что нить для росатома или алмаза или мценског спирт завода

Фи, Сахават.

Знаешь, за последние двадцать лет я не видел ни одного хорошего и разумного подхода к разработке, про который бы те или иные "трудяги от сохи" не высказались бы в стиле "попробовали бы эти теоретики применить это на практике - лоханулись бы так же, как мы, и говнокодили бы так же, как мы". При мне так говорили и про SQL, и про ООП, и про.... в общем, не вспомню про что не говорили. Не стоит присоединяться к этому хочу неудачников.
21 авг 15, 13:16    [18051150]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
scf
Member

Откуда:
Сообщений: 1477
petalvik,

Вы правы и неправы одновременно. Да, разработка начинается с проектирования. Нет, это не означает отказ от тестов.

Тесты вовсе не обязаны быть полными, и выбор того, что именно мы тестируем - это искусство, которое приходит только с опытом.

Вот простейший пример написания куска кода по TDD:
1. Формулируем требования к этому коду. Эти требования не обязательно должны быть полными, но они должны покрывать основные кейсы, без которых этот код неспособен решать свою задачу. Да-да, это фаза проектирования и одно из главных преимуществ TDD - это встраивание явного проектирования в процесс разработки.
2. Пишем интерфейс для реализации сформулированных требований. Обычно это просто функция с параметрами и возвращаемыми значениями
3. На каждое требование готовим тестовые данные, которые его проверяют и пишем тесты
4. пишем реализацию, которая удовлетворяем этим тестам
5. Если есть желание расширить и углубить требования (например, добавить негативные кейсы и угловые случаи) - гоу ту 1.
6. Рефакторинг написанного кода

Главный смысл - итеративность. Проектирование - тесты - код. Проектирование - тесты - код. Почему не проектирование - код - тесты? Потому, что при написании кода после проектирования сложно реализовывать требования по списку, у кода другая структура. А на этапе тестов про эти требования уже все забудут.
21 авг 15, 14:02    [18051472]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
ViPRos
Member

Откуда:
Сообщений: 9389
softwarer
ViPRos
но, пробовали бы они таким макаром написать что нить для росатома или алмаза или мценског спирт завода

Фи, Сахават.

Знаешь, за последние двадцать лет я не видел ни одного хорошего и разумного подхода к разработке, про который бы те или иные "трудяги от сохи" не высказались бы в стиле "попробовали бы эти теоретики применить это на практике - лоханулись бы так же, как мы, и говнокодили бы так же, как мы". При мне так говорили и про SQL, и про ООП, и про.... в общем, не вспомню про что не говорили. Не стоит присоединяться к этому хочу неудачников.

уровень заказчиков таких пещерный
с ними невозможно говорить на уровне спецификаций, целостности, непротиворечивости. доказуемости,...,
и они не готовы платить, за обследование, сбор требований. обобщение и формализацию,...,
им "все" (как раз сами не знают что это такое- надеются на красную кнопку или пытаются навязать свои "бест практикс", которое полное УГ) нужно вчера и даром
а нам надо жить и заработать тяжелым трудом на эту жисть
естественно, хотелось бы иметь точные, логичные требования и исходное состояние, а трансформацию бы мы и сами сделали если что (а иногда нужны и четкое описание методов трансформации), тогда можно было бы применить самую подходящую технологию проектирования, т.е. я не против ТДД или там ПДД, но только не с этими ОАО и ГАИ
ладно, слишком много времени на это ТДД потратили
21 авг 15, 18:37    [18053143]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
scf
Да, разработка начинается с проектирования. Нет, это не означает отказ от тестов.

С этим я полностью согласен. Я вовсе не говорю, что тесты не нужны. Они нужны, я их использую в реальной работе.
Я только лишь оспорил тезис, что тесты стоят во главе всего, на первом месте.

В целом было полезно пообщаться с оппонентами. За сим позвольте раскланяться.
21 авг 15, 18:56    [18053190]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / Программирование Ответить