Модульное тестирование: специфическое тестирование и контроль потока

Question

Я новичок в модульном тестировании и тестировании в целом. Я занимаюсь разработкой с помощью phpUnit, но поскольку мой вопрос носит более общий характер / вопрос дизайна, фактическая среда не должна иметь слишком большого значения.

Полагаю, хорошей практикой является написание ваших тестовых случаев как можно более конкретным . Например (чем позже, тем лучше):

assertNotEmpty($myObject);              // myObject is not Null 
assertInternalType('array', $myObject); // myObject is an array
assertGreaterThan(0, count($myObject)); // myObject actually has entries

Если это так, вот мой вопрос :

Является ли общепринятой практикой писать некоторый элемент управления потоком внутри тестового сценария , если состояние объекта, с которым он тестируется, зависит от внешних источников (то есть БД) - или даже вообще?

Как:

if (myObject !== null) {
    if (count(myObject) > 0) {
    // assert some Business Logic
    }
    else {
    // assert some different Business Logic  
    }
} 

Допустим ли этот вид управления потоком внутри тестового набора или это «кодовый запах» и его следует обойти? Если все в порядке, есть ли какие-нибудь советы или практики, о которых следует помнить здесь?

Answer 1

Ответ Пола касается области применения метода проверки и утверждений, но код вашего вопроса подразумевает, что вы будете проверять A, если возвращаемый объект будет иметь значение X, а тест B, если он будет иметь значение Y. Другими словами, ваш тест будет ожидать многократногооценивать и тестировать разные вещи в зависимости от того, что он на самом деле получил.

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

• Заполните базу данных набором фиксированных данных, используемых всеми тестами.Это будет развиваться по мере того, как вы будете добавлять новые тесты и функциональные возможности, и это может стать громоздким, чтобы поддерживать его в актуальном состоянии по мере движения.Если у вас есть тесты, которые изменяют данные, вам необходимо либо сбрасывать данные после каждого теста, либо откатывать изменения.
• Создать упорядоченный набор данных для каждого теста.Во время setUp() тест отбрасывает и воссоздает базу данных, используя ее конкретный набор данных.Изначально это может облегчить написание тестов, но вы все равно должны обновлять наборы данных по мере развития объектов.Это также может сделать выполнение тестов более длительным.
• Используйте mocks для ваших объектов доступа к данным, когда не тестируете эти DAO напрямую.Это позволяет вам указать в тесте, какие именно данные должны быть возвращены и когда.Так как вы не тестируете код DAO, все в порядке.Это ускоряет выполнение тестов и означает, что вам не нужно управлять наборами данных.Тем не менее, вам все равно придется управлять ложными данными и писать код для насмешек.В зависимости от ваших предпочтений существует множество фреймворков, в том числе встроенная в PHPUnit.

Answer 2

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