Начало работы с модульным тестированием

Модульное тестирование - это, грубо говоря, тестирование битов вашего кода изолированно с тестовым кодом. Непосредственные преимущества, которые приходят на ум:

  • Выполнение тестов становится автоматизируемым и повторяемым
  • Вы можете тестировать на гораздо более детальном уровне, чем тестирование методом "укажи и щелкни" через графический интерфейс

Rytmis

Мой вопрос: каковы текущие «лучшие практики» с точки зрения инструментов, а также когда и где использовать модульное тестирование как часть вашего ежедневного кодирования?

Давайте попробуем быть несколько независимыми от языка и охватывать все основы.

19.08.2008 20:18:09
7 ОТВЕТОВ
РЕШЕНИЕ

Хорошо, вот несколько советов от того, кто не проводит юнит-тест столько, сколько должен ... кашляет.

  1. Убедитесь, что ваши тесты проверяют одно и только одно.
  2. Пишите юнит-тесты по ходу дела. Желательно, прежде чем писать код, с которым вы тестируете.
  3. Не проводите модульный тест GUI.
  4. Разделяй свои заботы .
  5. Минимизируйте зависимости ваших тестов.
  6. Ложная behviour с издевается .
22
20.07.2012 11:39:41
Привет Джон, не могли бы вы рассказать, почему вы не будете тестировать GUI?
itsmatt 17.09.2008 19:05:51
Да, пожалуйста, объясните, почему вы не должны тестировать графический интерфейс.
Malfist 30.01.2009 20:36:19
Вы запускаете различные поведенческие типы тестов в графическом интерфейсе?
brian_d 19.01.2011 22:14:45

Семейство xUnit является основой модульного тестирования. Они интегрированы в Netbeans, Eclipse и многие другие IDE. Они предлагают простое, структурированное решение для модульного тестирования.

Одна вещь, которую я всегда стараюсь делать при написании теста, - минимизировать использование внешнего кода. Под этим я подразумеваю: я стараюсь свести к минимуму код настройки и демонтажа для теста в максимально возможной степени и стараюсь максимально избегать использования других модулей / блоков кода. Хорошо написанный модульный код не должен требовать слишком много внешнего кода при его установке и разборке.

1
19.08.2008 20:27:34

Так называемый фреймворк xUnit широко используется. Первоначально он был разработан для Smalltalk как SUnit, эволюционировал в JUnit для Java, и теперь имеет много других реализаций, таких как NUnit для .Net. Это практически стандарт де-факто - если вы говорите, что используете модульные тесты, большинство других разработчиков будут предполагать, что вы имеете в виду xUnit или подобное.

3
19.08.2008 20:29:23

Большой ресурс для «лучших практик» - это блог Google Testing , например, недавний пост о написании тестируемого кода - фантастический ресурс. В частности, их еженедельные посты из серии «Тестирование в туалете» отлично подходят для публикации вокруг вашего куба или туалета, поэтому вы всегда можете подумать о тестировании.

3
19.08.2008 20:33:16

NUnit - хороший инструмент для любого из языков .NET.

Модульные тесты могут быть использованы несколькими способами:

  1. Тестовая логика
  2. Увеличьте разделение блоков кода. Если вы не можете полностью протестировать функцию или часть кода, то составляющие его части слишком взаимозависимы.
  3. Разработка диска, некоторые люди пишут тесты, прежде чем они пишут код для тестирования. Это заставляет вас думать о том, что вы хотите, чтобы код делал , а затем дает вам определенное руководство, когда вы этого добились.
0
19.08.2008 20:44:56

Возможно, вы захотите взглянуть на TDD на трех карточках-указателях и трех карточках-указателях, чтобы легко запомнить суть разработки, основанной на тестировании :

Карта № 1. Три закона дяди Боба

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

Карта № 2: Первые принципы

  • Быстро: невероятно быстро, как сотни или тысячи в секунду.
  • Изолировано: тест четко выявляет неисправность.
  • Повторяемый: я могу запустить его несколько раз, и он будет проходить или выходить из строя один и тот же путь каждый раз.
  • Самопроверка: тест однозначно не прошел.
  • Своевременно: производится в шаге с небольшими изменениями кода.

Карта № 3: ядро ​​TDD

  • Красный: тест не пройден
  • Зеленый: тесты пройдены
  • Рефакторинг: чистый код и тесты
14
19.08.2008 22:28:56

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

0
27.08.2008 21:00:32