Сколько поблочного тестирования прежде начинают кодировать метод/класс?
Я начинаю (пробующий, по крайней мере) делать кодирование с помощью принципов TDD, и у меня есть этот вопрос: сколько тестов я должен записать, прежде чем на самом деле начнут кодировать?
Возьмите, например, гипотетически Math класс и метод Divide(int a, int b).
a) Сделайте я должен полностью протестировать все методы Math класс (Sum, Average...) прежде начинают кодировать Math?
b) Сделайте я должен полностью протестировать Divide метод, утверждая, например, для деления на нуль, прежде начинает кодировать метод?
c) Или я могу создать простое тестовое утверждение и проверить, что оно перестало работать, напишите код и проверьте, что оно в порядке, reapeating процесс для каждого из утверждений метода?
Я думаю, что опция c) является корректным, но я не мог найти ответ на нее (я сделал некоторый searchs, но не мог найти категорический ответ).
6 ответов
Ваш вариант c полностью представлен в книге TDD.
Вы пишете один неудачный тест, проверяющий функцию класса, над которым вы работаете, а затем пишете только кода, достаточного для прохождения этого теста. Затем вы делаете это снова для следующего теста.
Поступая таким образом, вы увидите, что каждый новый фрагмент кода, который вы пишете, очень сфокусирован на конкретном сценарии использования / тесте, а также обнаружите, что ваши тесты остаются разными в том, что они охватывают.
В конце концов, вы хотите работать в стиле «красный-зеленый», чтобы периодически возвращаться как к своему коду, так и к тестам, чтобы найти места, где вы можете реорганизовать вещи для улучшения дизайна.
Конечно, в реальном мире вы можете написать много красных тестов или написать больше кода, чем требует конкретный тест, или даже написать код без тестов, но это отходит от TDD и должно выполняться только с осторожностью. .
Статья в Википедии об этом на самом деле неплохая. http://en.wikipedia.org/wiki/Test-driven_development
Ну, вы можете написать
@Test
public void testDivide() {
Math math = new Math();
int result = math.divide(20,2);
Assert.assertNotNull(result);
}
Вот и все, теперь, когда вы запустите это, ваш тест провалится, поэтому вы исправляете свой метод Math.divide. и добавляете случаи в следующем шаге
это очень идеальный способ, но все знают, что это не всегда так.
Если вы стремитесь к полноте, вы должны спроектировать и закодировать свои модульные тесты до разработки, а затем разработать основные функции созданных модульных тестов. Чем тщательнее вы будете, тем четче будет объем и лучше окончательное качество. Если позволяют время и функциональность, я бы создал тесты для каждого метода / функции.
Первое, что вам нужно сделать, это написать спецификацию для каждого метода, который вы хотите реализовать. В вашей спецификации вам необходимо указать столько угловых случаев, сколько вам нужно, и определить поведение, к которому ваш метод должен привести при выполнении этих случаев.
После того, как ваша спецификация будет завершена, вы разрабатываете тесты для каждой части вашей спецификации, гарантируя, что каждый тест не будет пройден или не пройден из-за крайних условий. На этом этапе вы готовы написать код для реализации вашей функции и тестирования. По завершении вы уточняете свою спецификацию / тесты / реализацию по мере необходимости, пока результаты не будут именно такими, как вы хотите от вашей реализации.
Затем вы все документируете (в частности, ваши доводы в отношении обработки угловых случаев).
Как уже говорили другие, ваш вариант c был бы чистым TDD способом сделать это. Идея заключается в том, чтобы наращивать код небольшими шагами "красный-зеленый-рефактор". Хорошим простым примером этого является Bowling Kata Роберта Мартина.
Определение "единицы" не универсально, иногда единицей является класс, иногда это может быть метод. Поэтому универсального ответа не существует.
В данном конкретном случае я бы считал единицей метод, поэтому не стал бы изучать все методы до начала кодирования. Вместо этого я бы делал все постепенно, метод за методом. Это устраняет a).
Однако, когда я пишу тест для метода, я пишу строгий тест, т.е. я тестирую проходящие и непроходящие случаи, тестирую на ограничениях, тестирую специальные значения и т.д. Когда вы пишете тест, вы определяете контракт, и этот контракт должен включать исключительные ситуации. Думать о них с самого начала очень полезно. А для меня смысл в том, чтобы получить зеленый свет, поэтому я хочу, чтобы мой тест был исчерпывающим. И я думаю, что это б).
Если ваш тест не является исчерпывающим, то вы фактически не закончили работу над модулем, даже если тест пройден, и я не вижу в этом смысла. Я думаю, что это c).
Поэтому мой выбор - b).