Чи означає "очевидна реалізація" TDD спочатку код, а потім тест?

Ми з моїм другом є відносно новим TDD і маємо суперечку щодо техніки "Очевидне впровадження" (від "КДД за прикладом" Кента Бека). Мій друг каже, що це означає, що якщо реалізація очевидна, вам слід продовжити і написати її - перед будь-яким тестом на цю нову поведінку. І справді книга говорить:

Як ви реалізуєте прості операції? Просто реалізуйте їх.

Також:

Іноді ви впевнені, що знаєте, як здійснити операцію. Іди вперед.

Я думаю, що автор означає, що ви спершу слід перевірити, а потім "просто реалізувати" - на відміну від "Fake It (" Доки ви зробите це) "та інших методів, які потребують менших кроків на етапі впровадження. Також після цих цитат автор розповідає про отримання "червоних смуг" (провальних тестів) під час виконання "Очевидного впровадження" - як можна отримати червону смужку без тесту ?.

Але я не зміг знайти жодної цитати з книги, яка б сказала, що "очевидно" все-таки означає тест.

Що ти думаєш? Чи слід перевіряти спочатку чи після того, коли реалізація є "очевидною" (відповідно, TDD, звичайно)? Чи знаєте ви книгу чи допис у блозі, що говорить саме це?

Я погоджуюся з вашою інтерпретацією - це все-таки червоно-зелений рефактор, лише з Refactor трохи залишився;)

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

Чи знаєте ви книгу чи допис у блозі, що говорить саме це?

Я б заперечував, що книга Бека говорить саме це.

Він продовжує говорити

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

Як ви можете змусити тест пройти, написавши код, якщо він не існує до цього?

Очевидно, що тут немає жорстких і швидких правил, адже вони були спритними, тому ми можемо і повинні адаптуватися під час ітерації :)

Частково це буде залежати від простої операції, і, коли ви практикуєте TDD все більше і більше, ви регулярно знаходите речі, які ви погано перевірили або насправді взагалі не перевіряли, все це є частиною кривої навчання.

Також не забувайте, що TDD дозволяє протестувати інтерфейс та реалізацію, перш ніж скористатись ним живим кодом.

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

Звичайно, тести не означають, що ви вперше правильно пишете код, але ваші зміни визначаються тестом, і тести стають першим клієнтом коду, оскільки тести дуже дешеві і, що важливіше, не ризикують змінити у вас більше впевненості та свободи, розвиваючись.

Якщо ви дійсно намагаєтеся отримати хороше покриття та більш високу якість, то помиліться на стороні більше тестів, для початку, оскільки ви все більше і більше практикуєте TDD, ви будете розвивати власне відчуття рівня необхідного покриття.

Я дізнався, що для тривіального коду взагалі не повинно бути тестування.

Приклад: Якщо у вас є метод getva / setter Java, який відображає метод в локальну змінну, тест для unit було б надмірним.

можливо, саме це означає автор

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