Я уверен, что большинство из вас пишут множество автоматических тестов и что вы также столкнулись с некоторыми распространенными ошибками при модульном тестировании.
Мой вопрос: вы следуете любым правилам поведения для написания тестов, чтобы избежать проблем в будущем? Чтобы быть более конкретным: каковы свойства хороших модульных тестов или как вы пишете свои тесты?
Рекомендуются предложения по языку для агностиков.
Позвольте мне начать с подключения источников - Прагматическое тестирование модуля в Java с помощью JUnit (Там версия с С# -Nunit тоже.. но я есть этот.. его агностик по большей части. Рекомендуем.)
Хорошие тесты должны быть TRIP (акроним не достаточно липкий). У меня есть распечатка текста в книге, которую я должен был вытащить, чтобы убедиться, что я прав. )
Профессиональный. В конечном итоге у вас будет такой же тестовый код, как и производство (если не больше), поэтому следуйте тому же стандарту хорошего дизайна для вашего тестового кода. Хорошо укомплектованные методы-классы с раскрывающимися намерениями именами, без дублирования, тесты с хорошими именами и т.д.
Хорошие тесты также работают Быстро. любой тест, который занимает более половины секунды для запуска, должен быть обработан. Чем дольше набор тестов будет работать, тем реже он будет запущен. Чем больше изменений, разработчик попытается прокрасться между прогонами.. если что-то сломается.. потребуется больше времени, чтобы выяснить, какое изменение было виновником.
Обновление 2010-08:
Кроме того, большинство других - это руководящие принципы, которые ограничивают работу с низкой выгодой: например, "Не проверяйте код, который у вас нет" (например, сторонние библиотеки DLL). Не ходите на тестирование геттеров и сеттеров. Следите за соотношением цены и прибыли или вероятности дефекта.
Большинство ответов здесь, по-видимому, относятся к лучшим методам тестирования модулей в целом (когда, где, почему и что), вместо того, чтобы писать сами тесты (как). Поскольку вопрос казался довольно конкретным в части "как", я думал, что опубликую это, взятое из презентации "коричневого мешка", которую я провел в своей компании.
1. Используйте длинные имена описательных методов тестирования.
- Map_DefaultConstructorShouldCreateEmptyGisMap()
- ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
- Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2. Напишите свои тесты в Стиль Arrange/Act/Assert.
3. Всегда указывайте сообщение об ошибке с помощью своих утверждений.
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element
processing events was raised by the XElementSerializer");
4. Комментировать причину теста - что такое бизнес-предположение?
/// A layer cannot be constructed with a null gisLayer, as every function
/// in the Layer class assumes that a valid gisLayer is present.
[Test]
public void ShouldNotAllowConstructionWithANullGisLayer()
{
}
5. Каждый тест должен всегда возвращать состояние любого ресурса, к которому он прикасается
Помните эти цели (адаптированные из книги xUnit Test Patterns by Meszaros)
Некоторые вещи, чтобы сделать это проще:
Не забывайте, что вы можете выполнить тестирование интеграции с вашей инфраструктурой xUnit слишком , но проводить тесты интеграции и отдельные тесты
Некоторые свойства больших модульных тестов:
Когда тест терпит неудачу, сразу же должно быть очевидно, где проблема. Если вам нужно использовать отладчик для отслеживания проблемы, ваши тесты не достаточно гранулированы. Имеет ровно одно утверждение за каждый тест.
Когда вы рефакторинг, тесты не должны терпеть неудачу.
Тесты должны выполняться так быстро, что вы никогда не стесняетесь их запускать.
Все тесты должны проходить всегда; нет недетерминированных результатов.
Модульные тесты должны быть хорошо учтены, как и ваш производственный код.
@Alotor: Если вы предлагаете, чтобы библиотека имела только модульные тесты в своем внешнем API, я не согласен. Я хочу модульные тесты для каждого класса, включая классы, которые я не выставляю внешним абонентам. (Тем не менее, если я чувствую необходимость писать тесты для частных методов, тогда мне нужно рефакторинг.
EDIT: Был комментарий о дублировании, вызванном "одним утверждением за тест". В частности, если у вас есть код для настройки сценария, а затем вы хотите сделать несколько утверждений об этом, но только одно утверждение для каждого теста, вы можете дублировать настройку на нескольких тестах.
Я не принимаю такой подход. Вместо этого я использую тестовые приспособления для каждого сценария. Вот пример:
[TestFixture]
public class StackTests
{
[TestFixture]
public class EmptyTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
}
[TestMethod]
[ExpectedException (typeof(Exception))]
public void PopFails()
{
_stack.Pop();
}
[TestMethod]
public void IsEmpty()
{
Assert(_stack.IsEmpty());
}
}
[TestFixture]
public class PushedOneTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
_stack.Push(7);
}
// Tests for one item on the stack...
}
}
Тесты должны быть изолированы. Один тест не должен зависеть от другого. Более того, тест не должен опираться на внешние системы. Другими словами, проверьте свой код, а не код, на котором ваш код зависит. Вы можете протестировать эти взаимодействия как часть ваших интеграционных или функциональных тестов.
То, что вам нужно, - это определение поведения тестируемого класса.
Основное намерение - увеличить уверенность в поведении класса.
Это особенно полезно при анализе кода. У Мартина Фаулера есть интересная статья статьи относительно тестирования на его веб-сайте.
НТН.
веселит,
Rob
Тест сначала должен завершиться неудачей. Затем вы должны написать код, который заставляет их пройти, иначе вы рискуете написать тест, который прослушивается и всегда проходит.
Мне нравится аббревиатура Right BICEP из вышеупомянутого Прагматическое тестирование модулей:
Лично я чувствую, что вы можете получить довольно далеко, проверяя, что вы получаете правильные результаты (1 + 1 должен возвращать 2 в функции добавления), проверяя все граничные условия, о которых вы можете думать (например, используя два числа сумма которого больше целочисленного максимального значения в функции добавления) и вызывая условия ошибки, такие как сбои сети.
Хорошие тесты нуждаются в ремонте.
Я не совсем понял, как это сделать для сложных сред.
Все учебники начинают откликаться по мере того, как ваша база кода начинает в сотни тысяч или миллионы строк кода.
Хорошая архитектура может контролировать некоторый взрыв взаимодействия, но неизбежно, как системы становятся более сложными, а автоматизированная система тестирования растет вместе с ней.
Здесь вы начинаете иметь дело с компромиссами:
Вам также нужно решить:
Где вы храните тестовые примеры в своей базе кода?
Я мог бы продолжать вечно, но я хочу сказать, что
Тесты нуждаются в ремонте.
Я рассмотрел эти принципы еще в Это статья MSDN Magazine, которая, как мне кажется, важна для любого разработчика, чтобы читать.
Способ определения "хороших" модульных тестов - это если они обладают следующими тремя свойствами:
Jay Fields имеет много хороших советов о написании модульных тестов и должность, где он обобщает наиболее важные советы. Там вы прочтете, что вы должны критически думать о своем контексте и судить, стоит ли вам совет. Здесь вы получаете массу удивительных ответов, но зависит от вас, что лучше для вашего контекста. Попробуйте их и просто рефакторинг, если он плохо пахнет вам.
С уважением
Никогда не предполагайте, что будет работать тривиальный 2-строчный метод. Написание быстрого unit test - это единственный способ предотвратить пропущенный нулевой тест, неправильный знак минуса и/или тонкую ошибку охвата от кусания вас, неизбежно, когда у вас есть еще меньше времени для решения проблемы, чем сейчас.
Во второй ответ "A TRIP", за исключением того, что тесты ДОЛЖНЫ полагаться друг на друга!!!
Почему?
DRY - Dont Repeat Yourself - также относится к тестированию! Тестовые зависимости могут помочь: 1) сохранить время настройки, 2) сохранить ресурсы прибора и 3) точно определить неисправности. Конечно, только учитывая, что ваша среда тестирования поддерживает первоклассные зависимости. В противном случае я признаю, что они плохие.
Последующие действия http://www.iam.unibe.ch/~scg/Research/JExample/
Часто модульные тесты основаны на макет-объекте или макет данных. Мне нравится писать три типа модульных тестов:
Цель состоит в том, чтобы избежать повторного воспроизведения всего, чтобы иметь возможность проверять каждую функцию.
Подумайте о двух типах тестирования и рассмотрите их по-разному - функциональное тестирование и тестирование производительности.
Используйте разные входы и метрики для каждого. Возможно, вам понадобится использовать различное программное обеспечение для каждого типа теста.
Я использую согласованное соглашение об именовании тестов, описанное Roy Osherove Unit Test Стандарты именования. Каждый метод в данном классе тестового случая имеет следующее стиль именования MethodUnderTest_Scenario_ExpectedResult.
В каждом разделе используется верхний чехол для верблюда и разделяется под балл.
Я нашел это полезным, когда я запускаю тест, тест сгруппирован по имени тестируемого метода. И соглашение позволяет другим разработчикам понять намерение тестирования.
Я также добавляю параметры к имени метода, если тестируемый метод перегружен.