Совместное требование TDD

Question

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

<code>MethodOne()
{
  int errorCode = sectionOfDiverseCode();</p>

<p>//SharedCode
  string userMessage = localizeError(errorCode);
  displayUserMessage(userMessage);
}</p>

<p>MethodTwo()
{
  int errorCode = anotherSectionOfDiverseCode();
//SharedCode
  string userMessage = localizeError(errorCode);
  displayUserMessage(userMessage);
}

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

Answer 1

Я бы предложил иметь набор тестов для localizeError, а другой набор для displayUserMessage.Кажется, нет никакой причины для того, чтобы они были связаны вместе;локализованные ошибки могут попадать в журнал, и вы можете захотеть отображать сообщения, не связанные с ошибками, верно?

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

РЕДАКТИРОВАТЬ: Помните, что TDD это не серебряная пуля.В этом случае ключевым моментом является то, что модульные тесты подходят для localizeError и displayUserMessage, но, возможно, описанный вами тест на основе требований не совсем подходит для methodOne и methodTwo.В зависимости от вашей организации, возможно, в UAT лучше использовать тест верхнего уровня «проверьте правильность отображения».Общие правила о том, что «не повторяйся» и все другие хорошие правила разработки программного обеспечения, применимы и к написанию тестов.