Должен ли он быть «Упорядочить-Утвердить-Действовать-Утвердить»?

Что касается классического тестового шаблона Arrange-Act-Assert , я часто добавляю контрутверждение, которое предшествует Act. Таким образом, я знаю, что проходящее утверждение действительно проходит как результат действия.

Я думаю об этом как об аналоге красного в красно-зеленом-рефакторинге, где, только если я видел красную полосу в процессе тестирования, я знаю, что зеленая полоса означает, что я написал код, который имеет значение. Если я напишу проходной тест, то любой код его удовлетворит; аналогично, что касается Arrange-Assert-Act-Assert, если мое первое утверждение терпит неудачу, я знаю, что любой Act прошел бы последнее Assert - так что фактически он ничего не проверял в отношении Act.

Следуют ли ваши тесты этой схеме? Почему или почему нет?

Уточнение обновления : первоначальное утверждение по существу противоположно окончательному утверждению. Это не утверждение, что Arrange сработал; это утверждение, что Закон еще не сработал.

Это не самое обычное дело, но все же достаточно распространено, чтобы иметь собственное название. Этот метод называется Guard Assertion . Вы можете найти подробное описание этого на странице 490 в отличной книге xUnit Test Patterns Джерарда Месароша (настоятельно рекомендуется).

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

Может быть много предварительных условий, которые должны быть выполнены для данного тестового примера, поэтому вам может потребоваться более одного утверждения Guard. Вместо того, чтобы повторять их во всех тестах, наличие одного (и только одного) теста для каждого предварительного условия делает ваш тестовый код более устойчивым, поскольку в этом случае у вас будет меньше повторений.

Она также может быть определен как расположе- Предположим -act-Утверждай.

В NUnit есть техническая поддержка для этого, как в примере здесь: http://nunit.org/index.php?p=theory&r=2.5.7

Вот пример.

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
    range.encompass(7);
    assertTrue(range.includes(7));
}

Возможно, я Range.includes()просто написал, чтобы вернуть истину. Я этого не сделал, но могу представить, что мог. Или я мог написать это неправильно любым другим способом. Я бы надеялся и ожидал, что с TDD у меня все получилось правильно - это includes()просто работает - но, возможно, я этого не сделал. Итак, первое утверждение - это проверка работоспособности, чтобы убедиться, что второе утверждение действительно значимо.

Читая само по себе, assertTrue(range.includes(7));говорится: «Утвердите, что измененный диапазон включает 7». В контексте первого утверждения, в нем говорится: «Утверждают, что вызов encompass () приводит к включению 7. И поскольку encompass - это модуль, который мы тестируем, я думаю, что это имеет некоторую (небольшую) ценность.

Я принимаю свой ответ; Многие другие неверно истолковали мой вопрос как о тестировании установки. Я думаю, это немного другое.

Arrange-Assert-Act-AssertТест всегда может быть переработан в двух тестов:

1. Arrange-Assert

а также

2. Arrange-Act-Assert

Первый тест будет утверждать только то, что было настроено на этапе Arrange, а второй тест подтвердит только то, что произошло на этапе Act.

Это дает более точную обратную связь о том, потерпел неудачу этап Arrange или Act, в то время как в оригинале Arrange-Assert-Act-Assertони объединены, и вам придется копать глубже и точно исследовать, какое утверждение не удалось и почему оно не удалось, чтобы узнать, не удалось ли провалилась договоренность или действие.

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

Наконец, имейте в виду, что всякий раз, когда вы видите похожие разделы Arrange в разных тестах, вы должны попытаться вытащить их в общие вспомогательные методы, чтобы ваши тесты были более СУХИМИ и более удобными в обслуживании в будущем.

Я сейчас этим занимаюсь. AAAA другого типа

Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions

Пример теста обновления:

Arrange: 
    New object as NewObject
    Set properties of NewObject
    Save the NewObject
    Read the object as ReadObject

Act: 
    Change the ReadObject
    Save the ReadObject

Assemble: 
    Read the object as ReadUpdated

Assert: 
    Compare ReadUpdated with ReadObject properties

Причина в том, что ACT не содержит чтения ReadUpdated, потому что это не часть действия. Акт только меняется и спасает. Итак, на самом деле, ARRANGE ReadUpdated для утверждения, я вызываю ASSEMBLE для утверждения. Это сделано для того, чтобы не запутать раздел ARRANGE.

ASSERT должен содержать только утверждения. Остается ASSEMBLE между ACT и ASSERT, который устанавливает assert.

Наконец, если вы не справляетесь с Arrange, ваши тесты неверны, потому что у вас должны быть другие тесты, чтобы предотвратить / найти эти тривиальные ошибки. Поскольку для сценария, который я представляю, уже должны быть другие тесты, которые проверяют READ и CREATE. Если вы создаете «Утверждение защиты», вы можете нарушить DRY и создать обслуживание.

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

Я уже читал об этой технике - возможно, от вас, кстати, - но я ею не пользуюсь; в основном потому, что я привык к форме Triple A для своих модульных тестов.

Теперь мне становится любопытно, и у меня есть несколько вопросов: как вы пишете свой тест, вызываете ли вы это утверждение с ошибкой, следуя циклу рефакторинга красный-зеленый-красный-зеленый-зеленый, или вы добавляете его позже?

Иногда вы терпите неудачу, возможно, после рефакторинга кода? Что это вам говорит? Возможно, вы могли бы поделиться примером, в котором это помогло. Спасибо.

Я делал это раньше, когда исследовал неудачный тест.

После того, как я сильно почесал голову, я определил, что причина в том, что методы, вызываемые во время «Аранжировки», работали неправильно. Провал теста вводил в заблуждение. Я добавил утверждение после аранжировки. Это привело к тому, что тест не прошел в месте, которое выявило реальную проблему.

Я думаю, что здесь также есть запах кода, если часть теста Arrange слишком длинная и сложная.

В общем, мне очень нравится "Arrange, Act, Assert", и я использую его как свой личный стандарт. Однако единственное, о чем он не напоминает мне, - это дезорганизовать то, что я организовал, когда утверждения выполнены. В большинстве случаев это не вызывает особого раздражения, поскольку большинство вещей автоматически исчезают через сборку мусора и т. Д. Однако, если вы установили подключения к внешним ресурсам, вы, вероятно, захотите закрыть эти подключения, когда закончите. с вашими утверждениями, или у вас есть сервер или дорогой ресурс где-то там, где-то есть соединения или жизненно важные ресурсы, которые он должен быть в состоянии отдать кому-то другому. Это особенно важно, если вы один из тех разработчиков, которые не используют TearDown или TestFixtureTearDown.чтобы очистить после одного или нескольких тестов. Конечно, «Arrange, Act, Assert» не несет ответственности за то, что я не смог закрыть то, что я открываю; Я упоминаю об этой "ловушке" только потому, что я еще не нашел хорошего "A-word" синонима для "утилизации", чтобы рекомендовать! Какие-либо предложения?

Взгляните на статью Википедии о дизайне по контракту . Святая троица Arrange-Act-Assert - это попытка закодировать некоторые из тех же концепций и доказывает правильность программы. Из статьи:

The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:

    Acceptable and unacceptable input values or types, and their meanings
    Return values or types, and their meanings
    Error and exception condition values or types that can occur, and their meanings
    Side effects
    Preconditions
    Postconditions
    Invariants
    (more rarely) Performance guarantees, e.g. for time or space used

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

Зависит от вашей среды / языка тестирования, но обычно, если что-то в части Arrange выходит из строя, генерируется исключение, и тест не отображает его вместо запуска части Act. Так что нет, я обычно не использую вторую часть Assert.

Кроме того, в случае, если ваша часть Arrange довольно сложна и не всегда генерирует исключение, вы можете подумать о том, чтобы обернуть ее внутри какого-либо метода и написать для нее собственный тест, чтобы вы могли быть уверены, что он не потерпит неудачу (без бросая исключение).

Я не использую этот шаблон, потому что думаю сделать что-то вроде:

Arrange
Assert-Not
Act
Assert

Это может быть бессмысленно, потому что якобы вы знаете, что ваша часть Arrange работает правильно, а это означает, что все, что находится в части Arrange, также должно быть протестировано или должно быть достаточно простым, чтобы не нуждаться в тестах.

Используя пример вашего ответа:

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7)); // <-- Pointless and against DRY if there 
                                    // are unit tests for Range(int, int)
    range.encompass(7);
    assertTrue(range.includes(7));
}

Если вы действительно хотите протестировать все в примере, попробуйте еще тесты ... например:

public void testIncludes7() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
}

public void testIncludes5() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(5));
}

public void testIncludes0() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(0));
}

public void testEncompassInc7() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(7));
}

public void testEncompassInc5() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(5));
}

public void testEncompassInc0() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(0));
}

Потому что в противном случае вы упускаете так много возможностей для ошибки ... например, после encompass диапазон включает только 7 и т.д ... Существуют также тесты на длину диапазона (чтобы убедиться, что он также не охватывает случайное значение), и другой набор тестов полностью для попытки охватить 5 в диапазоне ... что мы ожидаем - исключение в encompass или диапазон, который останется неизменным?

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

Я использую:

1. Setup
2. Act
3. Assert 
4. Teardown

Потому что чистая настройка очень важна.