Как написать модульные тесты в форме спецификации?

Question

Во многих ситуациях мне сложно придумать хорошие названия для юнит-тестов классов и методов. Обычно я стараюсь следовать форме:

public class TestContext
{
    [Fact]
    public void WhenThis_DoThat()
    {
    }
}

Некоторые помещают слова «Дано», «Когда» и «Затем» в части, которые должны быть явными. Мне это нравится, потому что кажется, что модульный тест проясняет, что именно он тестирует. Помимо рассмотрения наборов инструментов BDD, мне нужны некоторые советы о том, как это может работать с простыми старыми инструментами xUnit.

Мне особенно тяжело с такими сценариями:

Когда приложение запускается, загружается основная форма и пользователь видит список ссылки, по которым пользователь может перейти.

или, возможно, лучший сценарий использования:

Пользователь может выбрать ссылку из списка ссылки.

Я не уверен, но я пытаюсь описать поведение, при котором вы запускаете приложение, а форма загружается списком кликабельных ссылок. И превращая это в юнит-тест.

Что такое Данное, Когда и Тогда для этого?

Answer 1

Вот как я пишу тесты в стиле спецификации BDD: http://github.com/orfjackal/tdd-tetris-tutorial

Что нужно, так это возможность иметь несколько тестовых приборов в одном классе. Тогда можно организовать тесты так, чтобы каждый прибор был частью «Given / When», а каждый метод теста - частью «Then». JUnit не поддерживает его, поэтому я написал для него простой тестовый прогон :

@RunWith(NestedJUnit4.class)
public class WerewolfTest extends Assert {
    public class Given_the_moon_is_full {
        @Before public void When_you_walk_in_the_woods() {
            ...
        }
        @Test public void Then_you_can_hear_werewolves_howling() {
            ...
        }
        @Test public void Then_you_wish_you_had_a_silver_bullet() {
            ...
        }
    }
    public class Given_the_moon_is_not_full {
        @Before public void When_you_walk_in_the_woods() {
            ...
        }
        @Test public void Then_you_do_not_hear_any_werewolves() {
            ...
        }
        @Test public void Then_you_are_not_afraid() {
            ...
        }
    }
}

Answer 2

Я цитирую Представляю BDD от Дэна Норта:

Имена методов испытаний должны быть предложениями

Мой первый "Ага!" момент произошел как я было показано обманчиво простым утилита под названием agiledox , написанная моим коллега Крис Стивенсон. Требуется JUnit тестовый класс и распечатывает имена методов в виде простых предложений, поэтому контрольный пример, который выглядит так:

public class CustomerLookupTest extends TestCase { testFindsCustomerById() { ... } testFailsForDuplicateCustomers() { ... } ... }

отображает что-то вроде этого:

CustomerLookup – finds customer by id – fails for duplicate customers – ...

Слово "тест" убрано из обоих имя класса и имена методов, и имя верблюжьего преобразован в обычный текст. Это все это делает, но его эффект удивительно.

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

Вся статья действительно стоит прочитать. Настоятельно рекомендуется!

Answer 3

В вашем сценарии что может пойти не так? Модульный тест должен что-то проверить, так что вы тестируете.

FormHasLinks

LoadForm? // затем проверяем ссылки

Может быть, если вы скажете, что вы проводите тестирование, а не то, что вы делаете, вам будет проще.

Answer 4

Я называю свои тесты после ввода, а не после вывода. Я описываю сценарий, который тестируется: я не пытаюсь определить во имя тестового примера, какой выходной результат требуется в этом сценарии.

Например, следующий тест для проверки поведения клавиши Backspace в текстовом редакторе в различных сценариях:

• Забой после пробела
• Backspace по краям встроенного textrun
• Backspace в начале абзаца
• Backspace в конце строки
• Backspace нормализуется в пределах абзаца
• Backspace выделенное слово и оба пробела
• Backspace выделенное слово и пробел
• Backspace выделенное слово
• Выбор Backspace охватывает два абзаца
• Забой нескольких слов
• Пробел и выбранное слово
• Забой на дальний край другого блока

Таким образом, вы можете более или менее увидеть, какие сценарии тестируются (но он также не пытается сказать вам, каково ожидаемое поведение в каждом сценарии).

Answer 5

Я стараюсь следовать подходу Роя Ошерова:

http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx