Может люди мой доклад посмотрели. ;) А на самом деле очень хороший пример win-win для работодателя и сотрудников.

Погодите, то что вы перечислили — это малая часть программирования. А вот о прикладной разработке очень мало что «говорит наука». Есть узкие области в тестировании, которые тоже хорошо формализованы научно, например нагрузочное тестирование использует много из теории вероятности и статистики. Много разных алгоритмов для изображений используется как основа визуального тестирования и инструментов автоматизации как Sikuli. В дополнение к этому существует подход graph based testing, который основан на теории графов… :)

Попробуйте, кто же мешает. Только может с программирования начать лучше? ;)

К сожалению, эта отрасль развивается так быстро, что притяжение научных методов не везде уместно. Но много где есть вполне себе математические модели и алгоритмы, например в visual testing.

Вы назадавали вопросов на еще несколько статей. Писать их в комментариях мне кажется нецелесообразным. К тому же, попробуйте просто вдуматься в данные мной ответы, а не сразу же писать свой новый вопрос. Просто вот эти ваши уточнения кидают тень на вообще суть понимания вами моих ответов:

Писать код не думая? :)
Если мы можем предусмотреть в тесте, что тоже вряд ли мы сразу все предусмотрим, то почему не можем в коде? :)
Вы об ассертах в тестах?
То есть: заложили в TDD жирный метод -> реализовали метод -> он жирный -> зарефакторили тесты -> зарефакторили метод.
Мы можем решить при написании теста, что это нормально. :)
Был класс с приватными членами, а стал класс без приватных членов, использующий другой класс без приватных членов…
Но если нужно избавляться от private, то Вы таки против инкапсуляции, которая одна из священных коров ООП (не для меня)? :)
Он попытается все сам решить у спросит вас при конфликте.
Одновременно править один и тот же код не стоит.
Чем чаще мерджится, тем меньше конликтов. :)
Если все делают разработчики, то тестировщики не нужны? :)

То есть о побочных явлениях думать не нужно?
А в тестах их тоже не нужно предусматривать? :)

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

А они ставятся не во время написания кода? :)
А их нельзя отключить? :)

Так проблема в том, что они по умолчанию выключены. А расставлять мне лично больше всего нравится в рамках написания валидационных тестов на исключительные ситуации с параметрами.

И он во время написания кода не проверяет его работоспособность? :)

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

А при TDD все методы легкие? :)

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

Ну так если будет ясная задача реализовать API, то разработчик его и реализует :)
Часто задача имеет undefined behaviour из-за дальнейшей правки которого все падает :)
Тут что тесты писать до, что после. :)

Речь не о глобальном API приложения, а на уровне класса (его публичного поведения) или связки классов. В тестах вы смотрите на еще не существующий код с точки зрения вызывающего и делаете правильный удобный API.

А почему такая уверенность, что их не сделают при TDD? :)

Потому что ты в тесте написал «true, false, true» и сразу очевидно какая фигня на выходе получается. А просто по сигнатуре метода эта боль так не чувствуется.

Стоп, стоп, стоп.
Мы TDD тест по вашему написали до кода. Откуда же внезапные private?

Вопрос был задан на тему существующего кода, который разрабатывался не по TDD.

То есть нафиг ООП и инкапсуляцию? :) (сам я не адепт секты ООП)

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

При чем это к private?

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

Используйте git…

Так его и использует большинство. Вот только как git может помочь при логическом изменении несколькими людьми одного и того же кода? Мержиться придется чаще, а это чревато ошибками.

То есть не TDD?
Но веб в основном — это работа с базой. :) Для веба TDD не подходит? :)

Почему не TDD? TDD — это стиль разработки, при котором вы отталкиваетесь от тестов и идете к реализации. И совершенно не важно веб это или база данных.

Если база медленная, то скорее всего она большая. :)
Если большая, то не влезет в память.
Если влезет, то она бы и на диске летала бы :)

Просто набор оторванных от реальности утверждений. Доказывать вам обратное на реальных примерах слишком затратно по времени. Поэтому просто поверьте на слово. :)

Тестирование веб-интерфейса должен писать разработчик или тестер?
Это TDD или нет?

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

Это прокатит с мелким API.
Автоматическую генерацию тестовых параметров все равно нужно будет запрограммировать :)
Предполагается ли тестировать корректность работы таких генераторов? :)

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

Кстати, не сказано, что тесты нужны прежде всего как индикатор, что что-то сломалось при изменениях. Отсутствие багов вообще они не гарантируют. :)

Отсутствие багов вообще никто и никогда не гарантирует. Ваша задача свести вероятность к минимуму и уменьшить потенциальную критичность дефекта.

Так прикол в том, что он пишется быстрее, потому что подавляющее большинство кода генерируется IDE, а не вводится руками.

Именно так! Это подход к разработке, который характеризуется началом каждого цикла с написания теста. Идея очень простая и берется из связки «требование-реализация». Чтобы что-то реализовывать, нужно иметь требование, причем формализованное. Тест как раз такое требование выкладывает из головы в код и позволяет неоднократно его проверять по мере необходимости. А уже отталкиваясь от требования, можно разрабатывать реализацию.

Вот мой часовой доклад строго про TDD для уровня данных. А так обычно полный рассказ с практикой занимает на тренинге 2 дня. Поэтому в рамках конференционного доклада не всегда получается покрыть все.

Я неоднократно показывал как работать по TDD на уровне доступа к данным. И на весьма себе реалистичных примерах. :)

Николай работает на совершенно реальнейших проектах всю свою жизнь. Это легко отследить по профилю Николая. И только на последнем проекте Николай не пишет код, потому что ему нужно организовать работу 12 команд на проекте в 150+ человек, чтобы они на регулярной основе делали поставки работающего продукта заказчику. И да, на проекте жесточайшие дедлайны и сильное давление со стороны заказчику. При этом, большинство активно использует TDD именно по причине ускорения разработки и устранения фактора «поспешишь — людей насмешишь!».

Я полностью согласен, Java — не лучший выбор для функциональных тестов и работы не разработчиков. Во всех динамических языках библиотеки тестирования куда стройнее и проще в использовании. Да и нужно искать как заинтересовать разработчиков участвовать в тестировании более активно. Это один из вариантов.

Ну питон простой достаточно и для тестирования реально выглядит неплохо.

Совершенно необязательно. Это даже прикольная возможность изучить другой язык на простой сравнительно задаче.

Много чего делается в направлении model-based testing. И инструменты появляются, но не на уровне модульных тестов.

Я за подход с тестируемостью приложения, заложенную в самом приложении. Не вижу ничего плохого тут. Это тренд сейчас везде практически.

По поводу ожиданий реации уже сделано много в WebDriver. Есть механизм конфигурируемого ожидания на стороне браузера, можно ждать на стороне теста, но это короткие засыпания в цикле с проверкой при просыпании.

У меня нет опыта работы с Vaadin, но я когда-то разбирался как там все устроено. На уровне модульных тестов нет никаких проблем, на уровне UI WebDriver общается с браузером, поэтому ему все равно что тестировать. Но нужны будут усилия со стороны разработчиков, чтобы сделать приложение тестируемым. Обычно для веб UI это означает продуманную стратегию использования id и class атрибутов. С TestBench я дела не имел, поэтому не могу ничего сказать.

Речь не идет о «писать сразу ужасно преужасно», а о «фокусироваться на решении проблемы, а уже потом с решенной проблемой улучшать дизайн». И фаза рефакторинга в ТДД обязательна, вы не переходите к следующему тесту пока не привели код к хорошему дизайну. И накопить технический долг не удастся, потому что объем кода для одного теста сравнительно небольшой. А по поводу технического долга как раз сегодня написал статейку со ссылкой на полезное видео.

Может быть, но в хорошо построенном процессе за описанные действия отвечают совсем другие люди — лидеры команд, тестировщики, вся команда, ответственные за саппорт и т.д. Если менеджер занялся такими делами, то остальным плевать.