А вы используете TDD в своих проектах?

Ой-ой-ой, TDD-шная невеста нас всех разоблачила.

Это всё красиво, но проблемы клиентов решают программы. Тесты (tdd-шные) решают чуть больше чем ничего. Не могу сказать, что сталкивался со всеми ситуациями и раскладами, но по своему опыту:

1. Сначала надо изучить отрасль в которой плавает клиент - иначе все старания в жопу. 2. Сформировать в схемах _все_ бизнес-процессы, в которых участвует клиент. 3. Проектировка, проектировка, проектировка.

Я не против функциональных тестов, даже всеми конечностями ЗА! Но ставить тесты во главу угла - глупость.

Это может проканать в вебе, но в комплексной автоматизации, я бы за это ставил к стенке.

Мнение моё, и не факт что правильное.

тестировать private методы

По идее при TDD никак, даже если программное окружение позволяет. Это же детали реализации. А вот с юнит-тестами как быть? Читал разные мнения на этот счет. Вроде как приватный метод тоже юнит. Сам пишу тесты и для них, кроме совсем тривиальных.

Например в джаве приватные методы из другого класса не вызвать. Либо тесты писать в теле тестируемого класса (не принято), либо жуткий изврат с вызовом через рефлекшн.

По идее при TDD никак, даже если программное окружение позволяет. Это же детали реализации.

не детали, просто при хорошей архитектуре «наружу» (относительно класса, модуля библиотеки и т.п.) ничего лишнего торчать не должно, тестирование же требует обратного, или эпичных костылей. Очевидно что TDD при клинической стадии амозглия разработчика потребует всего и вся.

А по хорошему надо то только интерфейсы API тестить.

Нет никакого смысла отказываться от TDD, т.е. он не приводит к негативным последствиям.

Он в большинстве случаев абсолютно неуместен. Вот, например, парсер. Как ты его юнит-тестировать будешь? Он монолитен. Только integration tests!

И самый смак в том, что с TDD архитектуру хорошую построить легче.

Напряги мозг! Архитектура предполагает наличие иерархии, TDD, наличие местячковых результатов. Грубо говоря, TDD говорит, что кирпич способен выдержать около 25кг, на излом. А вот архитектура говорит, что при правильной кладке степень воздействия нивелируется и на 2-3 слое кирпич выдержит пару центнеров.

Да, аналогия - говно, но уж больно похожа.

Как меня уже достало это TDD и Agile. На каждом углу о нем кричат. Ну а при приеме на работу чуть ли не главное требование к кандидату.
Откуда этот мейнстрим пошел? Из рубиворлда?

Например в джаве приватные методы из другого класса не вызвать.

Сейчас глянул, powermock умеет mocking приватных методов. Значит востребовано, раз сделали.

с хабра вроде, у нас же русскоязыных айтиресурсов нет, а на хабре там реклама мс или сабжевая фигня

Вроде речь про тестирование, а не про мокинг.

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

По-хорошему, надо тестить всё

но ставить тесты как руководство к разработке - идиотизм!

тут на балансе этих двух высказываний и стоит весь дискусс. даже у вас в нем противоречие - «надо, но идиотизм» в итоге молодые, вьюноши с горячими ушами и грязными от университестких конспектов ладошками возводят храмы TDD и приносят ему в жертвы остатки своего разума.

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

и мне тоже парочку таких, а то даже по многим протоколам спеки не полные писаны идиотами и реализуются разными конторами по разному 8)

не детали, просто при хорошей архитектуре «наружу» (относительно класса, модуля библиотеки и т.п.) ничего лишнего торчать не должно

С точки зрения TDD детали. Возможно, я неправильно понимаю TDD, но мне представляется процесс так - спроектировали интерфейс, описали его в тестах, дальше пишем реализацию. Тут вроде нет места приватным членам. Разве что на этапе проектирования их сразу выделить, что как то нереально. Или же писать тесты по мере добавления методов, что уже никак не отличается от обычного юнит-тестирования.

Во, кстати, господа TDD'шники. А разрисуйте-ка как ваш подход вырулит в экспертных системах? Ну там где однозначные ответы типа «канает-никанает» вырастают в «приемлимо, более приемлимо, нейтрально, не очень приемлимо, приемлимо с оговорками, неприемлимо», только не надо звиздеть про «логики энного порядка», всё это практически решается, только не вот в такой бинарной постановке вопроса «Вован, ты это, типа тест прошёл?».

Вроде речь про тестирование, а не про мокинг

Там не только мокинг, но есть и invokeMethod. Я имел ввиду, что работа с приватными методами при тестировании востребована. То есть whitebox не антипаттерн даже в джаве.

ты не правильно понимаешь приватность - приватность это просто «не (публичный интерфейс)» а не только ключевое слов на методе (хотя и оно тоже)

При TDD тяжелее наваять хреновую архитектуру. Без TDD можно сделать хорошую, с этим не спорю.

смак

Так аргументы будут? Хотя бы один недостаток TDD можете привести?

Зачем тестировать private методы? TDD этого не требует.

При TDD тяжелее наваять хреновую архитектуру.

Не не так, TDD накладывает некоторые требования на архитектуру, например модульность (хотя лысые юнит тесты делают тоже), что полезно, с одной стороны с другой он накладывает требования излишней публичности многих вещей, и заставляет извращаться с наприме инициализацией системы - рисовать толпы заглушек и играть в пасочки с системой

Если он у вас монолитен, то он и есть «юнит».

еще один 8)

ХЗ откуда он пошел, но весьма годен. По крайней мере на мои навыки повлияло положительно. Благодаря тому же TDD у меня фейлов крупных на продакшене не было уже года полтора, а до того - случались раз в несколько месяцев примерно. Еще мне кажется, что новый функционал/изменение старого стали проходить гораздо легче.

Что еще один? Покажите пруф, где требует. Или я вы вообще не о том и я не понял?

А у тебя «не публичный интерфейс» не является «закрытым» в терминах языка? Как так?

Есть такая штука, как вероятности и статистика.

Не не так, TDD накладывает некоторые требования на архитектуру, например модульность (хотя лысые юнит тесты делают тоже), что полезно, с одной стороны

Ok

накладывает требования излишней публичности многих вещей

Поясните

рисовать толпы заглушек и играть в пасочки с системой

Ну так это и просто для юнит-тестов требуется. При чем пишется один раз или вообще генерируется(тут зависит от языка, на C#, например, можно моки генерировать, на плюсах - ручками).

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

> накладывает требования излишней публичности многих вещей
Поясните

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

ты не правильно понимаешь приватность - приватность это просто «не (публичный интерфейс)»

Для клиентского кода приватных методов вообще не существуют. А при TDD тесты - это такой первичный клиент, как тут говорили уже. То есть по идее для TDD whitebox-тестирование - плохая практика. А если при тестировании рассматривать класс изнутри, то согласен, приватные методы - часть интерфейса (непубличная). Потому я их тоже стараюсь тестировать.

А в сложных задачах юниты всегда крупные. И ООПищу там не место. И ТДД неприменим.

Я не говорю что оно не нужно. Я просто говорю что говорят о нем больше чем о самом коде.

TDD и Agile

Что это вообще в одном перечислении делает? Первое - методика программирования, второе - buzzword.

Ты как собираешься тестировать private методы? это примитивно.

Нет, батенька, это вы обосрались с таким вопросом. Это вопрос из разряда самых ламерских про тесты и никакого отношения к архитектуре он не имеет, а просто выдает непонимание того как нужно писать тесты.

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

Во! Таки да!

А вот с юнит-тестами как быть?

Вот этот вопрос тоже из разряда самых первых вопросов, которые задают новички. Всегда хочется спросить: юнит-тест это цель или средство?

TDD и все ваше написание тестов для быдлокодеров и низкоквалифицированных программистов, от индусов оно и появилось. Если у вас есть здравый смысл, то вы должны понимать, что погрузить объект во всевозможные состояния очень сложно, а иногда и просто невозможно. Ну и конечно же, кто тестирует ваши тесты? Давайте примеры больших Open Source проектов где это использут? Linux Kernel не используют.

не там где это уместно, а вообще везде.

Я пришел к выводу, что общий подход везде применим, но вот конкретные техники да, нужно адаптировать под каждый случай. Если тупо мокать все зависимости и писать только изолированные юнит-тесты, то получим mock hell, и туеву кучу не особо полезных тестов.

TDD и все ваше написание тестов для быдлокодеров и низкоквалифицированных программистов, от индусов оно и появилось.

http://www.morekoda.ru/?block=47

:)

А если серьезно, то вот это «погрузить объект во всевозможные состояния очень сложно» ни разу не аргумент, как и любые черное-белые заявления. Даже тестирование только happy path уже сильно бустит разработку. Тут нужно пользоваться правилом 80/20.

Получаем обьект В.

Минуточку, и что мешало написать на это тест?

Эмерджентность систем - аргумент?

В пользу чего? Тесты - это не способ формальной верификации систем, это способ ускорить разработку и повысить качество.

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

Писать в 2 раза больше кода - это ускорить разработку? Повысить качество?

Представляете, да. Извините, но вы видимо вообще не разбирались в теме. Можете или мои посты почитать, я тут уже распинался на эту тему, или лучше книжки.

Не представляю:) Прочитанного думаю достаточно для того, чтобы сделать вывод, что это не нужно. Мир.

Лучше потратить это время на продумывание архитектуры чем на стучание по клавишами и набору очередной тучи тестов

Почему ты так боишься набирать буковки на клавиатуре? Или ты очень медленно это делаешь?

Мне интересней думать;)

Мне интересней думать;)

Тогда какое отношение к программированию ты имеешь? Ты - архитектор. В лучшем случае, философ. Топик о практическом применении методики.

Видимо я не туда попал, а вы на каком языке программируете?