VB.NET и NUnit - TDD - PullRequest
       3

VB.NET и NUnit - TDD

5 голосов
/ 28 июня 2010

Я изучаю TDD с VB.NET и NUnit. Я хочу знать, что лучше всего делать: использовать много методов Assert внутри тестового метода или использовать assert для метода?

Это мой код. Спасибо.

Imports NUnit.Framework

<TestFixture()> _
Public Class CalculatorTest
<Test()> _
Public Sub TestAdd()
    Dim calculator As Calculator = New Calculator()

    Assert.AreEqual(2, calculator.sum(1, 1))
    Assert.AreNotEqual(3, calculator.sum(2, 2))
    Assert.AreEqual(-1, calculator.sum(0, -1))
        Assert.AreNotEqual(3, calculator.sum(1, 1))
    End Sub
End Class

Ответы [ 4 ]

7 голосов
/ 28 июня 2010

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

В вашем примере вы на самом деле тестируете 4 вещи, хотя вам, вероятно, нужны только две из них, поскольку они охватываютна той же земле.Я бы посоветовал проверить, что происходит, когда вы добавляете два положительных числа, два отрицательных числа и отрицательное и положительное с отрицательными и положительными результатами.Тогда я бы подумал о математических свойствах и тестовой коммутативности и аддитивной идентичности (ноль).Наконец, я бы протестировал граничные условия - положительное и отрицательное переполнение и т. Д. Обратите внимание, что это может или не может быть исчерпывающим, то есть я думаю, что я охватил основы, но я не слишком стараюсь, чтобы быть исчерпывающим;Я просто хочу проиллюстрировать, как вы будете думать о том, какие тесты писать, и, да, я бы сделал каждый из этих отдельных тестов с одним утверждением.

Для чего-то более сложного, у вас может быть большечем утверждают, что тестирует ту же «вещь» - например, вы можете проверить, правильно ли вставлена ​​строка в БД с заданным набором входных данных.Я думаю, что вполне приемлемо проверить, что все столбцы имеют правильное значение в одном тесте, а не тестировать каждое свойство в отдельности.Другие могут отличаться, но я не думаю, что в этом случае вы создаете какие-либо зависимости, проверяя, что все свойства имеют свои правильные значения, потому что вставка является атомарным действием.

5 голосов
/ 28 июня 2010

Общепринятая «Лучшая практика» - это одно утверждение на тест. (По словам Роя Ошерова)

Однако этот конкретный тест можно выполнить немного проще с помощью NUnit с использованием TestCases:

<Test()> _
<TestCase(1, 1, 2)> _
<TestCase(1,-1, 0)> _
<TestCase(0,-1,-1)> _
Public Sub Calculator_Add_ReturnsExpectedResult(Integer a, Integer b, Integer expected)
    Dim calculator As Calculator = New Calculator()

    Assert.AreEqual(expected, calculator.sum(a, b))
End Class

Также обратите внимание на название, которое я там использовал, чтобы уточнить, что именно тестирует.

Принцип, лежащий в основе практики «Одно утверждение на тест», заключается в том, что вы хотите, чтобы неудачный тест означал нечто очень конкретное. То есть каждый тест должен сообщать вам, работает ли какая-то конкретная вещь.

0 голосов
/ 17 июня 2014

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

0 голосов
/ 28 июня 2010

Это интересная дискуссия, которая может сводиться к стилю. Мне нравится мнение Роя Ошерова о том, что у вас должно быть только одно утверждение на юнит-тест.

Прочитайте подробное обсуждение этого вопроса здесь .

Также отметьте это .

...