Юнит тесты и TDD

[Wolverene]

Привет всем. Встречался мне вопрос на интервью - "Как вы проводите тестирование? Как относитесь к юнит тестам? Как вы смотрите на Test Driven Development?". В общем что-то в этом роде.

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

Т.е. получается подход - вначале контуры, общая картина, а потом уже добавление мелких штрихов для целостности. В общем интервьюеру это не понравилось, как я понял. А как вы занимаетесь тестами написанного кода (ну если не перекидывать через забор тестеру)? Следуете ли принципу "вначале тест, потом код"?

[fruit6]

Про "вначале тест, потом код" говорят только "говоруны", лунатики и проф непригодные, начитавшиеся журнала "CIO".

Если точно нужна такая работа, то так и говорите: Пока не покрою юнит тестами 100%, к имплементации не приступаю.

Если у Вас расплывчатые спеки, то Вы все делаете правильно.

[PrettyVacant]

Вопрос о TDD как бы сам по себе намек. Надо было радостно рассказать, как это помогает, особенно на ранних этапах разработки, да еще в сочетании с каким-нибудь NCrunch - вообще сказка (и действительно чудесный тул). Потом сделать озабоченное лицо и сказать, что по опыту, последовательное воплощение TDD прибавляет примерно 30% ко времени разработки проекта, хотя и обеспечивает лучшее качество и в итоге более продуманную архитектуру, так что, увы, часто ближе к концу проекта TDD приносят в жертву графику. Как-то так.

[Sergunka]

Зависит от задачи понятно.

Если нужен сервис, то сначала пишешь интерфейсы, а потом накатываешь BDD тесты на Cucumber и потом уже вдумчиво пробиваешь тулово сервиса. Большая экономия времени и усилий получается + плюс эксептенс критерия по джире уже забиты.

Если же вычислеж какой, то можно вполне и JUnit обойтись.

Я лично потихоньку мозги выедаю коллегам BDD Сucumber... просто испытываю невероятное удовлетворении от того как их штырит от одной мысли, что "сначала тест, а потом код"

[Сабина]

Про "вначале тест, потом код" говорят только "говоруны", лунатики и проф непригодные, начитавшиеся журнала "CIO".

Если точно нужна такая работа, то так и говорите: Пока не покрою юнит тестами 100%, к имплементации не приступаю.

Если у Вас расплывчатые спеки, то Вы все делаете правильно.

На самом деле я таки начинала иногда с тестов и получалось все как начитавшиеся лунатики завещали . Но в целом да - тесты уже after all. У нашего теперяшнего архитектра требование 80%+ test coverage. Я заметила что если пользуешь rest easy для интеграционных тестов оно на coverage не влияет хотя по сути all layers of webservice are involved. Вот где настоящее горе - обьяснять что тестов не так мало как может показаться

[Sergunka]

Не ну а чо? Если я один или нас двое то тесты это просто для прикола и для резюме. А вот если там уже больше трех, а обычно средний тим 6/7 человек, то отсутсвие тестов в начале разработки это обезьяник где каждая обезьяна наровит украсть чужой банан.

[Wolverene]

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

Кто-нибудь порекомендует книгу / софт / хороший подход - для веб-сервисов на Java? Чтобы разумный подход был. В целом пользуюсь JUnit / Mockito, интеграционные REST тесты через Python / Nose, запускаются автоматически на каждый pull request, раз в неделю гоняем тесты с больших покрытием, regression тесты, проводили нагрузочные тесты и тесты на производительность, профилирование среднего времени исполнения. Так, думаю об улучшении качества кода - релиз близок, прорыв есть, работает все быстрее относительно предыдущей версии раз в 10-20, но поджилки трясутся все на production выставлять...

[Wolverene]

Сорри, кажется не туда топик запихнул - наверное надо было в "Вопросы и новости IT"...

[Sergunka]

Сорри, кажется не туда топик запихнул - наверное надо было в "Вопросы и новости IT"...

Господь с Вами - в вопросах ИТ народ мейнфреймы обсуждает на ТДД они с топором бросаться будут.

[fruit6]

Зависит от задачи понятно.

Если нужен сервис, то сначала пишешь интерфейсы, а потом накатываешь BDD тесты на Cucumber и потом уже вдумчиво пробиваешь тулово сервиса. Большая экономия времени и усилий получается + плюс эксептенс критерия по джире уже забиты.

Если же вычислеж какой, то можно вполне и JUnit обойтись.

Я лично потихоньку мозги выедаю коллегам BDD Сucumber... просто испытываю невероятное удовлетворении от того как их штырит от одной мысли, что "сначала тест, а потом код"

Не совсем понятно из контекста, Вы работаете по waterfall, и кто-то уже определил интерфейсы и критерии приемки?

[Sergunka]

Зависит от задачи понятно.

Если нужен сервис, то сначала пишешь интерфейсы, а потом накатываешь BDD тесты на Cucumber и потом уже вдумчиво пробиваешь тулово сервиса. Большая экономия времени и усилий получается + плюс эксептенс критерия по джире уже забиты.

Если же вычислеж какой, то можно вполне и JUnit обойтись.

Я лично потихоньку мозги выедаю коллегам BDD Сucumber... просто испытываю невероятное удовлетворении от того как их штырит от одной мысли, что "сначала тест, а потом код"

Не совсем понятно из контекста, Вы работаете по waterfall, и кто-то уже определил интерфейсы и критерии приемки?

Классический аджайл с продакт онер и бизнес аналист. Критерии пишут они фактически. Все вполне прозрачно. Если критерии меняются соотвественно переписывается интерфейс + сценарий в тесте ну и само собой джира.

Разве у Вас не так?

[fruit6]

да-да, я видел много раз какого рода продукт производят "продакт онер и бизнес аналист" -- "Utter shit", как выражается наш друг с мейнфрема.
И факт что Вы называете это достаточным для тестирования говорит всего лишь что Вы адаптировались к правилам игры.

[zhuravl]

Пишу сначала тесты, потом код. От правила стараюсь не отступать. Да, добавляет 30% ко времени разработки на начальных этапах. Но это не моя проблема, деньги платят, а я делаю как считаю нужным. Зато потом хорошо. Если работодателю это не нравится, то я его меняю. Впрочем, особых проблем с этим не возникало, предыдущие работодатели уговаривали остаться. Я уходил по другим причинам.

Можно это сравнить с хирургической операцией. Представьте, что вы хирург и делаете операцию на сердце. А вам говорят - давай быстрее. Я просто решил для себя, что не хочу это слышать. Морально готов увольнению на почве сдачи проекта позднее, чем ожидается и к спорам с менеджерами. Решил, что париться по этому поводу смысла нет, когда вокруг так много вакансий на рынке. Была бы ситуация на рынке другая - не вы....вался бы.

[Vladimir Kr.]

"Юнит тесты и TDD" ограниченно полезны. Надо понимать, что юнит тесты не должны подменять и исключать функциональные/интеграционные тесты. Юнит тесты - они для тестирования алгоритмов бизнес логики, их можно применять для большего, но подменяя ими ф.т. будет только хуже.
А вот функциональные тесты и ТДД могут сильно помочь в разработке, это когда BA и QA пишут тесты для новых фичь, а FE/BE/fullstack девелоперы делают имплементацию, чтобы эти тесты проходили. Но в СI надо разделять backlog(in development) test cases, которые еще сделаны и должны фэилиться, и completed которые не должны фэилиться, иначе ПМ будет ругаться.
Про классический аджайл ... я не буду придираться к словам, но это работаюций, а не классический адажайл. По манифесту, в классическом, все тулзы и писанные критерии стоят на шестом месте, а на первом - ПМ, ПО и ВА.