Означает ли «очевидная реализация» TDD код сначала, тест после?

Мой друг и я - относительно новый TDD, и у него есть спор о технике «Очевидная реализация» (из «TDD By Example» Кента Бека). Мой друг говорит, что это означает, что если реализация очевидна, вы должны пойти дальше и написать ее - перед любой проверкой этого нового поведения. И действительно, в книге говорится:

Как вы реализуете простые операции? Просто реализуй их.

Также:

Иногда вы уверены, что знаете, как реализовать операцию. Преуспевать.

Я думаю, что автор имеет в виду, что вы должны сначала протестировать, а затем «просто внедрить» его - в отличие от «Fake It ('Till You Make It)” и других методов, которые требуют меньших шагов на этапе реализации. Также после этих цитат автор говорит о получении «красных полос» (неудачных тестов) при выполнении «Очевидной реализации» - как можно получить красную полосу без теста?

Тем не менее, я не смог найти ни одной цитаты из книги, говорящей, что «очевидное» все еще означает «тест в первую очередь».

Что вы думаете? Должны ли мы тестировать сначала или после того, как реализация «очевидна» (в соответствии с TDD, конечно)? Вы знаете книгу или сообщение в блоге, говорящее только это?

Я согласен с вашей интерпретацией - это все еще Red Green Refactor, только с опущенным битом Refactor;)

Итак, сначала напишите несостоявшийся тест, а затем реализуйте очевидное решение, а не медленно создавайте проект «самого простого».

Вы знаете книгу или сообщение в блоге, говорящее только это?

Я бы сказал, что книга Бека говорит именно об этом.

Он продолжает говорить

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

Как вы можете пройти тест, написав код, если он не существует до того, как код существует?

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

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

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

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

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

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

Я узнал, что для тривиального кода не должно быть никакого юнит-теста.

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

может быть, это то, что автор имеет в виду

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."