Модульное тестирование - TDD - C # - PullRequest
1 голос
/ 22 января 2012

Я создаю прототип для робота, используя тестовую разработку (C #, консольное приложение). Сначала я создал тестовый проект и класс RobotTest. Здесь я написал тестовые методы, чтобы потерпеть неудачу и пройти, я создаю класс Robot. Затем я создал класс RobertPrototype, в котором создается объект класса Robot для использования методов в классе Robot. Наряду с этим, я добавил некоторые другие методы (для анализа ввода) в RobertPrototype.

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

Пожалуйста, ведите меня. Благодарю.

Ответы [ 3 ]

2 голосов
/ 23 января 2012

Одной из реализаций TDD является Red-Green-Refactor.Когда вы пишете тесты (красный), вам нужно будет добавить методы к роботу, чтобы пройти (зеленый).Следующим шагом является организация кода, возможно, в другие классы (Refactor).Исходный код, используемый для прохождения теста, может относиться к другому классу, чем ваш окончательный код.

2 голосов
/ 23 января 2012

Нужно ли включать все методы в сам класс Robot?

Я не понимаю вопроса. Вы уже сказали, что ваши тесты находятся в отдельном проекте, и что вы пишете отдельный класс клиента RobotPrototype, который использует класс Robot.

На данный момент это кажется разумным дизайном.

Я думаю, что вы вводите себя в заблуждение, записывая биты всех ваших классов для каждого бита "рабочего" теста, который вы пишете для какого-либо метода класса Robot. Это не способ думать о TDD. Это НЕ означает, что вы пишете неудачный тест для создания объекта Robot, затем пишете оболочку конструктора Robot, пишете оболочку класса, который использует робота, пишете оболочку клиента, который использует RobotPrototype. Затем напишите неудачный тест, затем напишите пустой метод Robot, напишите код RobotPrototype, который использует этот метод, напишите код клиента, который использует то, что использует RobotPrototype. нет, нет, нет.

Каждый класс в вашем дизайне робота будет иметь свой собственный соответствующий класс Test. Каждый метод в каждом классе будет иметь свой собственный соответствующий метод в своем соответствующем тестовом классе. Цикл TDD выполняется для каждого метода отдельно.

Попробуйте это:

  • Сосредоточьтесь на одном классе и соответствующем тестовом классе. Очевидно, вам нужен робот, прежде чем что-либо еще. Начните с класса Робот.
  • Используя цикл TDD, напишите функциональные методы.
  • Если у вас достаточно функций Robot, чтобы что-то сделать, вы можете начать писать код, использующий робот (класс RobotPrototype).
  • Класс RobotPrototype имеет свой собственный соответствующий класс Test. Каждый из его методов будет иметь соответствующий метод Test. Вы должны были написать достаточно функциональности робота, чтобы завершить любой данный метод RobotPrototype. Если нет, остановись. Вернитесь к роботу и напишите там методы работы.

Учитывая вышесказанное, очки, которые нужно забрать:

  • Сначала вы написали полные "основные" методы. Каждый метод имеет рабочие тесты, когда вы закончите.

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

  • Таким образом, ваше приложение построено на слоях проверенного кода .

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

  • Насколько это практически возможно, у каждого класса есть тестовый класс, а у каждого метода есть (хотя бы один) тестовый метод.

1 голос
/ 22 января 2012

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

...