mesierПоддержу по всем пунктам!
Использование TDD как бэ заставляет обеспечивать 100% покрытие. Но, нмв, снижает эффективность работы. Приходится снова и снова возвращаться к одному и тому же коду (в данном случае коду тест-метода) - то стаб не учли, то сигнатуру сервис-метода поменяли, то ещё чего-нибудь. Это во время разработки самого метода, для которого заранее написали тест я имею в виду..
И куда как проще и быстрее, нмв - написал метод, написал тесткейс, проверил, "забыл"..
Вобщем, у меня что-то не сложилось с TDD, как не пыжился. Удовольствия от работы никакого. ))

Основная проблема видимо в том, что у вас хреновое ТЗ, впрочем так зачастую и бывает в реальной жизни. ТДД имеет смысл только если спецификация четкая и все пункты понятны, иначе как и у вас это превращается в трудноподдерживаемое говно. И писать тесты надо ровно по пунктам ТЗ, а не checkIfValidSpringContext(), checkMemebrsInjected() и тому подобная инфраструктурная хрень зависящая от имплементации. Где-то слышал это называется Behaviour Driven Development.

А тесты ради тестов пишут или неопытные, или тем кому нефиг делать.

DEVcoach, я вас понял и много где согласен, но боюсь вы не поняли меня:) постараюсь объяснить.


DEVcoachКоллега, давайте снимем розовые очки. Никогда ТЗ не бывает идеальным. Никогда . Поэтому зачем об этом говорить вообще?

Конечно никогда, но думаю вам повезло работать с вменяемыми заказчиками или самому на себя. В мире ынтырпрайза это очень редкий случай) Поясню, ТЗ по дефолту неполное и ущербное, но есть разные градации. Нормальное ТЗ - 1) откуда взять данные 2) описаны все депенденси(веб-сервисы, база и тп) 3) Юс кейсы использования 4) Обработка ошибок. 5) Мокап страницы(формы)
6) Правила бизнес-логики.
Понятно, что детали могут измениться. Допустим было понятие "юзер из австралии" - это юзер, у которого в таблице кантрис - поле tenant=7. В процессе выяснилось, что должны быть соблюдены еще два условия - что срок полиси у него должен быть в текущем году, и какое-то поле в таблице users должно быть AUS. Это нормально.
Но когда извините меня, в ТЗ стоит - определить австралиец ли это или нет, можно дернув какой-то веб-сервис(пока не ясно какой, мы предоставим детали позже) а может мы будем использовать какую-то стороннюю приблуду для интеграции с системой аккаунтинга - то это полный шлак. И да, все прекрасно понимают что это говно, но ничего сделать не могут, начинают гадать, возводить абстракции и тп. Может даже какие-то юнит-тесты писать, которые со 100% уверенностью потом будет геморройно поддерживать.
DEVcoachДалее, изменчивость ТЗ никак не связана с "поддерживаемостью" приложения. Ну вот вообще никак.

Так я этого и не говорил, я говорю что когда ТЗ говно и на него написаны тесты - тебе придется поддерживать не только код но и эти тесты, и это пипец какое удовольствие.
DEVcoach Я пишу миддлварный продукт. У нас тут требования мы сами придумываем по принципу "а вдруг рынку это надо?". Иногда угадмываем, иногда не очень. Иногда вообще не угадываем . И никак это не поддерживаемости не сказывается. Ошиблись? Выпилили старое, запилили новое. В чем проблема?

Угу, вам повезло работать на себя, вокруг все не так:)
DEVcoachВ корне не согласен. Разговор идет про unit-тесты . А unit-тест во своему смыслу кроет конкретный минимальный атомарный функционал. Настолько маленький, что его не будет видно ни в ТЗ, ни в архитектуре, нигде, кроме кода. Поэтому те тесты, про которые вы говорите, это что угодно, но только не unit-тесты.


Безусловно вы правы, я привел неправильный пример, потому что правильный пример привести сложно). Я имел ввиду что юнит тест должен покрывать только "открытые методы" и только независимым от имплементации способом(на мой взгляд конечно). Подумаю над примером, где нет много деталей, надеюсь мысль и так понятна.

DEVcoachВ корне не согласен. Разговор идет про unit-тесты . А unit-тест во своему смыслу кроет конкретный минимальный атомарный функционал. Настолько маленький, что его не будет видно ни в ТЗ, ни в архитектуре, нигде, кроме кода. Поэтому те тесты, про которые вы говорите, это что угодно, но только не unit-тесты.


Хотя ладно убедили, я больше имел ввиду интеграционные тесты для веб-контроллеров, написанные на JUnit.

DEVcoachrfqВ идеале - разработчик тестов, находящийся с разработчиком продукта в равных условиях: оба опираются на спецификацию. Если же спецификации нет, то это не идеал, а жопа.Коллега, вы опять говорите не про юнит-тесты. Юнит-тесты пишет разработчик и никто иначе. Цель юнит-теста - убедиться, что атомарный кусок кода работает, как ожидается. Этот кирпичик программы может быть настолько маленьким и специфичным, что вы его не заметите ни в требованиях, ни в архитектуре.
Поэтому мы можем спорить на тему того, кто должен писать функциональные тесты. Мы можем спорить, кто должен писать интеграционные и load-тесты.
Но мы не можем спорить, кто должен писать unit-тесты, это обязанность разработчика и точка.

Хорошо, а что тогда по-вашему TDD? На мой взгляд это не только юнит-тесты

DEVcoachзабыл никХорошо, а что тогда по-вашему TDD? На мой взгляд это не только юнит-тестыЯ уже отвечал на этот вопрос выше. Unit-тесты - это инструмент . TDD - это методология , которая активно использует этот инструмент.
Ок, тогда, хоть это и не совсем по теме ТС, но я переформулирую свое утверждение. TDD без вменяемой спецификации - время на ветер. Не для холивара ради, а чтобы окончательно пояснить свою мысль. По юнит-тестам с вами согласен