andrej писал(а):Goldsmith я бы добавил еще пару тестов - для остро и тупоугольного треугольников.
А то был у нас случай, когда один из разработчиков отрефакторил класс, считая что у него все треугольники прямоугольные, забыв, что классом его еще другие пользуются....
Это довольно тонкий момент. С одной стороны, желательно протестировать все ветви функции и все возможные сочетания параметров. С другой - лишние тесты тоже нежелательны. В идеальном тестовом наборе каждый тест отвечает за одну возможную ошибку. И наоборот, каждая ошибка вызывает провал ровно одного теста. В случае избыточности одна ошибка проваливает несколько тестов, и на первый взгляд не так легко определить, одна это ошибка или их сразу несколько.
В нашем случае (использована формула Герона) никак не разделяются остроугольные, прямоугольные и тупоугольные треугольники, формула одна для всех видов. Предположим, мы реализовали три теста. Если по какой-то причине формула "испортится" (например, из-за опечатки вместо (p-a) будет набрано (p+a) и т.п.), откажут сразу все три эти теста. В общем в этом нет ничего страшного, разобраться в такой ситуации будет несложно, но вообще так не принято.
Теперь рассмотрим такую ситуацию. Предположим, что некто нашел лучший способ решения задачи, но с отдельными формулами для каждого вида треугольников:
Код: Выделить всё
if (остроугольный)
формула_1;
else if (тупоугольный)
формула_2;
else // прямоугольный
формула_3;
Все это замечательно, но в процессе улучшения формула_1 или формула_2 (а возможно, и обе) были реализованы с ошибкой. Но у нас имеется единственный тест для прямоугольного треугольника, т.е. реально тестируется только формула_3. Получается неприятная ситуация: после изменения кода все тесты прошли, а необнаруженные ошибки остались в коде. Три предложенных вами теста спасли бы положение.
Однако, к сожалению, все сочетания мы заранее предусмотреть не можем. Например, наш "благодетель" пошел дальше и ввел отдельные ветки для равнобедренных и равносторонних треугольников (разумеется, опять наделав ошибок). На эти случаи мы не догадались припасти тестов, а они очень бы пригодились. Получается, у нас как будто и есть тестовый набор, но он пропускает ошибки, как решето воду. Сама идея тестирования дтскредитируется.
К счастью, не все так плохо. Во-первых, как я упоминал в статье, желательно периодически профилировать выполнение тестов. Профиль покажет, что в процессе тестирования не все ветки проверяемой функции были выполнены, а значит, тестовый набор
необходимо расширить. Во-вторых, в последней (на данный момент) статье, посвященной TDD, приводится важное правило: ни строчки кода без соответствующего теста. Если твердо придерживаться этого правила, все добавляемые ветки будут протестированы. Важно лишь придерживаться его и при разработке, и при рефакторинге.
Но в любом случае: если сомневаетесь, стоит ли добавлять тест, - обязательно добавьте. Избыточный тестовый набор гораздо лучше неполного.
