Это должен быть “Arrange-Assert-Act-Assert”?
Существует новая библиотека, которая аккуратно объединяет функции вместе с таймаутами, чтобы вы могли избежать ада обратного вызова.
Превращает это:
setTimeout(function(timeout){
function1();
setTimeout(function(timeout){
function2();
setTimeout(function(timeout){
function3();
}, timeout, timeout)
}, timeout, timeout)
}, 10, 10);
в это:
Sequencr.chain([function1, function2, function3], 10);
И имеет встроенную поддержку для петель что "спит" между каждой итерации.
7 ответов
Here's an example.
public void testEncompass() throws Exception {
Range range = new Range(0, 5);
assertFalse(range.includes(7));
range.encompass(7);
assertTrue(range.includes(7));
}
It could be that I wrote Range.includes() to simply return true. I didn't, but I can imagine that I might have. Or I could have written it wrong in any number of other ways. I would hope and expect that with TDD I actually got it right - that includes() just works - but maybe I didn't. So the first assertion is a sanity check, to ensure that the second assertion is really meaningful.
Read by itself, assertTrue(range.includes(7)); is saying: "assert that the modified range includes 7". Read in the context of the first assertion, it's saying: "assert that invoking encompass() causes it to include 7. And since encompass is the unit we're testing, I think that's of some (small) value.
I'm accepting my own answer; a lot of the others misconstrued my question to be about testing the setup. I think this is slightly different.
Зависит от вашей среды / языка тестирования, но обычно, если что-то в части Arrange не удается, генерируется исключение, и тест не отображает его вместо запуска части Act. Так что нет, я обычно не использую вторую часть Assert.
Кроме того, в случае, если ваша часть Arrange довольно сложна и не всегда генерирует исключение, вы могли бы подумать о том, чтобы поместить ее в какой-нибудь метод и написать собственный тест, поэтому вы можете быть уверены, что он не потерпит неудачу (без создания исключения).
Это не самая распространенная вещь, но все же достаточно распространенная, чтобы иметь собственное имя. Этот метод называется Guard Assertion . Вы можете найти его подробное описание на странице 490 в прекрасной книге Тестовые шаблоны xUnit Джерарда Месароса (настоятельно рекомендуется).
Обычно я сам не использую этот шаблон, так как нахожу его правильнее написать конкретный тест, который проверяет любое предварительное условие, которое я считаю необходимым обеспечить. Такой тест всегда должен завершаться неудачно, если предварительное условие не выполняется, а это означает, что мне не нужно, чтобы оно было встроено во все другие тесты. Это дает лучшую изоляцию проблем, поскольку один тестовый пример проверяет только одну вещь.
Может быть много предварительных условий, которые должны быть выполнены для данного тестового примера, поэтому вам может потребоваться более одного утверждения Guard Assertion.
Я уже читал об этой технике - возможно, от вас, кстати, - но я ею не пользуюсь; в основном потому, что я привык к форме тройной А для своих модульных тестов.
Теперь мне становится любопытно, и у меня возникают некоторые вопросы: как вы пишете свой тест, вызываете ли вы это утверждение с ошибкой после красного -зеленый-красный-зеленый-цикл рефакторинга, или вы добавляете его потом?
Вы иногда терпите неудачу, возможно, после рефакторинга кода? Что это вам говорит? Возможно, вы могли бы поделиться примером, в котором это помогло. Спасибо.
Добавление утверждения «проверка работоспособности» для проверки состояния перед выполнением действия, которое вы тестируете, является старой техникой. Я обычно пишу их как тестовые строительные леса, чтобы доказать себе, что тест делает то, что я ожидаю, и удаляю их позже, чтобы избежать загромождения тестов тестовыми шаблонами. Иногда оставление строительных лесов внутри помогает тесту служить повествованием.
Я делал это раньше, когда исследовал неудачный тест.
После того, как я сильно почесал голову, я определил, что причина в том, что методы, вызываемые во время «Аранжировки», работали некорректно. Провал теста вводил в заблуждение. Я добавил утверждение после аранжировки. Это привело к тому, что тест не прошел в месте, которое выявило реальную проблему.
Я думаю, что здесь также есть запах кода, если часть теста Arrange слишком длинная и сложная.
Его также можно указать как Arrange- Assume -Act-Assert.
В NUnit для этого есть техническая поддержка, как в примере здесь: http://nunit.org/index.php?p=theory&r=2.5.7