Использование утверждает. Неокончательный
4 ответа
Когда я использую VS для генерации модульных тестов, я получил Assert.Inclusive для сгенерированных методов тестирования, и обычно я меняю утверждение на что-то еще, когда работаю с ними. Я использую вопросительные знаки Assert.Inconclusive в результатах теста в качестве маркеров, чтобы быстро сказать мне, какие тесты я еще не завершил.
Ну, я так и использую. Судя по названию «Неубедительный», я думаю, вы можете использовать его для обозначения своего недетерминированного состояния, если документируете его значение.
Однако из описания вашего метода Average () я думаю, что возможно, ваш модульный тест недостаточно атомарен, чтобы охватить только одну «единицу», один конкретный сценарий. Иногда, Я пишу 2 или 3 метода модульного тестирования для одного метода. Или вы можете разбить свой метод Average () на более мелкие методы, охватывающие отдельные обязанности. Таким образом, вы можете выполнить модульное тестирование этих небольших методов перед модульным тестированием Average () одного.
Johannes,
Вот как я бы реализовал Sum () и Методы Average () .
public static class MyMath
{
private static void ValidateInput(ICollection<int> numbers)
{
if (numbers == null)
throw new ArgumentNullException("numbers", "Null input. Nothing to compute!");
if (numbers.Count == 0)
throw new ArgumentException("Input is empty. Nothing to compute!");
}
public static int Sum(int[] numbers)
{
ValidateInput(numbers);
var total = 0;
foreach (var number in numbers)
total += number;
return total;
}
public static double Average(int[] numbers)
{
ValidateInput(numbers);
return Sum(numbers) / numbers.Length;
}
}
Для простоты я просто выбрасываю исключения ArgumentException из метода ValidateInput (ICollection . Вы также можете проверить возможность переполнения и выбросить OverflowException в методе ValidateInput (ICollection .
С учетом сказанного, вот как я бы протестировал Функция Average (int []) .
[TestMethod]
public void AverageTest_GoodInput()
{
int[] numbers = {1, 2, 3};
const double expected = 2.0;
var actual = MyMath.Average(numbers);
Assert.AreEqual(expected, actual);
}
[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void AverageTest_NullInput()
{
int[] numbers = null;
MyMath.Average(numbers);
}
[TestMethod]
[ExpectedException(typeof(ArgumentException))]
public void AverageTest_EmptyInput()
{
var numbers = new int[0];
MyMath.Average(numbers);
}
При такой настройке тестов Я могу быть уверен, что когда все тесты пройдены, моя функция верна. Ну кроме случая переполнения. Теперь я могу вернуться к методу ValidateInput (ICollection , чтобы добавить логику для проверки переполнения, а затем добавить еще один тест, чтобы ожидать, что OverflowException будет выдано для типа входов, вызывающих переполнение. Или сделайте это в обратном порядке, если вы хотите использовать TDD.
Надеюсь, это поможет прояснить идею.
Неубедительный тест - это тест, по которому вы не можете определить результат. Например, что, если у вас есть тест, который использует какой-то внешний ресурс (например, подключение к Интернету). Если соединение в настоящее время недоступно, это не означает, что тест завершился неудачно. С другой стороны, вы не должны просто отмечать его как успешное, не выполняя его. Таким образом, вы отмечаете это как неубедительное, и это можно увидеть в отчете о тестировании.
ПРИМЕЧАНИЕ: В целом, вы не должны использовать такие внешние ресурсы в своих тестах, поскольку это может сделать тесты нестабильными.
Для еще не завершенных тестов я использую атрибут MbUnit Explicit .
Я только Assert.Inconclusive для модульных тестов, которые я еще не написал. Иногда, когда я что-то пишу, я осознаю какой-то угол, который не хочу пропустить. Поэтому я быстро перескакиваю, пишу метод теста с описательным именем и добавляю одну строку Assert.Inconclusive.
Причина этого в том, что он предоставляет документацию о вещах, которые мне нужно протестировать, не прерывая слишком сильно мой рабочий процесс. Это также позволяет быстро отфильтровывать неудачные тесты в списке результатов. Безрезультатный сбой означает, что я ничего не сломал, мне просто нужно написать еще тесты.
Assert.Inconclusive указывает, что либо:
Я еще не написал тест; Мы создали только тестовый метод
-или-
У моего теста есть зависимость, и эта зависимость недоступна. Например
List<Customer> custs = o.GetAllCustomers();
if (custs.Count == 0)
{
Assert.Inconclusive("No customers to test");
return;
}