Как написать тесты в первую очередь на Java?

Question

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

Простой пример: у меня есть класс Rectangle. Он имеет private поля width и height с соответствующими геттерами и сеттерами. Общая Java. Теперь я хочу добавить функцию getArea(), которая возвращает произведение обоих, но сначала я хочу написать тест.

Конечно, я могу написать юнит-тест. Но это не тот случай, когда он завершается с ошибкой, а даже не компилируется, потому что функции getArea() пока нет. Означает ли это, что написание теста всегда включает изменение производительного кода, чтобы ввести пустышки без функциональности? Или я должен написать тест таким образом, чтобы он использовал самоанализ? Мне не нравится последний подход, потому что он делает код менее читаемым, и последующий рефакторинг с помощью инструментов не обнаружит его и не нарушит тест, и я знаю, что мы много реорганизуем. Кроме того, добавление «dummys» может включать в себя множество изменений, т. Е. Если мне нужны дополнительные поля, для того, чтобы Hibernate продолжал работать, необходимо изменить базу данных… что кажется мне подходящим изменением кода, когда все еще «пишу только тесты». То, что я хотел бы иметь, - это ситуация, когда я могу на самом деле писать код только внутри src/test/, вообще не касаясь src/main, но без самоанализа.

Есть ли способ сделать это?

Answer 1

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

Например:

1. Вы добавили свой метод, например, getArea(param1, param2) в свой рабочий код с пустым телом.
2. Затем вы пишете тест с правильным вводом и ожидаемым результатом.
3. Вы запускаете тест, и он не пройдёт.

4. Затем вы меняете производственный код и снова запускаете тест.

   • Если это не помогло: вернитесь к предыдущему шагу.
   • Если оно пройдет, вы напишете следующий тест.

Краткое введение можно найти, например, здесь: codeutopia -> 5-шаговый метод, чтобы сделать тест, управляемый разработкой и модулем-тестирование-легкий

Answer 2

Я хотел бы иметь ситуацию, когда я могу писать код только внутри src / test /, вообще не касаясь src / main, но без самоанализа.

Я никогда не видел способа написания теста с зависимостью от новой части API и немедленной компиляции этого теста без предварительного расширения API субъекта теста.

Это самоанализ или ничего.

Но это не тот случай, когда он терпит неудачу, но он даже не компилируется, потому что функции getArea () пока нет

Исторически, написание кода, который не мог скомпилироваться, было частью ритма TDD. Написать немного тестового кода, написать немного рабочего кода, написать немного тестового кода, написать немного рабочего кода и т. Д.

Роберт Мартин описывает это как нано-цикл TDD

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

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

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

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

Answer 3

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

Означает ли это, что написание теста всегда включает изменение производительного кода, чтобы ввести пустышки без функциональности?

Я думаю, что да. Как я понимаю, все тесты эквивалентны всем спецификациям / вариантам использования, которые у меня есть в программном обеспечении. Таким образом, написание теста на провал сначала касается попытки заполнить спецификации требований тестовыми кодами. Затем, когда я попытался заполнить производительный код для прохождения только что написанного TC, я действительно попытался заставить его работать. Пройдя некоторое время, я был очень удивлен тем, что размер моего производительного кода очень мал, но он способен удовлетворить большую часть требований.

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

Итак, основным рабочим процессом является Red - Green - Refactor, который я получил из презентации от Bryan Breecham - https://www.infoq.com/presentations/tdd-lego/

О,

Я хотел бы иметь ситуацию, когда я могу писать код только внутри src / test /, вообще не касаясь src / main, но без самоанализа.

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