Сколько стоит юнит-тестирование перед началом кодирования метода / класса?

Question

Я начинаю (по крайней мере, пытаюсь) делать кодирование, используя принципы TDD, и у меня возникает вопрос: сколько тестов мне нужно написать перед тем, как начать кодирование?

Возьмем, к примеру, гипотетический Math класс и метод Divide(int a, int b).

a) Должен ли я полностью протестировать все методы класса Math (Sum, Average, ...) перед началом кодирования Math?

b) Должен ли я полностью протестировать метод Divide, например, для подтверждения деления на ноль, прежде чем начинать кодировать метод?

в) Или я могу создать простое тестовое утверждение и проверить, что оно не выполнено, написать код и проверить, все ли в порядке, повторяя процесс для каждого из утверждений метода?

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

Answer 1

Ваш вариант c полностью представлен книгой TDD.

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

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

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

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

Статья в Википедии на самом деле довольно хорошая. http://en.wikipedia.org/wiki/Test-driven_development

Answer 2

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

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

Затем вы документируете все (особенно ваши аргументы в пользу рассмотрения угловых случаев).

Answer 3

Как уже упоминали другие, ваш вариант c будет чистым способом TDD сделать это. Идея состоит в том, чтобы создать ваш код с небольшими приращениями красно-зеленого-рефактора. Хороший простой пример этого - Bowling Kata Роберта Мартина .

Answer 4

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

Answer 5

Определение «единицы»: не универсально , иногда единицей является класс, иногда это может быть метод.Так что нет реального универсального ответа.

В этом конкретном случае я бы посчитал, что блок является методом, поэтому не все методы, прежде чем начать кодирование.Вместо этого я бы делал вещи постепенно, методы за методами.Это исключает а).

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

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

Так что мой выбор будет б) .

Answer 6

Ну, вы, вероятно, можете написать

@Test
public void testDivide() {
   Math math = new Math();
   int result = math.divide(20,2);
   Assert.assertNotNull(result);
}

Вот и все, теперь, когда вы запустите это, ваш тест не пройдёт, поэтому вы исправите свой метод Math.divide. и добавьте случаи на следующем шаге

это очень идеальный способ, но все знают, что это не всегда так.