Правильная модульная проверка Философия

Question

Что было бы правильной вещью для каждого случая?

1: Контекст: Тестирование функции, которая создает базу данных, а также создание метаданных для этой базы данных

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

2: Для большинства других функций требуется база данных и метаданные. Было бы лучше назвать предыдущие функции в настройке каждого набора тестов для создания базы данных и метаданных, или было бы лучше жестко запрограммировать требуемую информацию в базе данных?

Answer 1

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

Нет, заказанные тесты плохие. Там ничего не мешает вам иметь тестовый вызов другого метода, который случается испытание, хотя:

@Test 
public void createDataBase(){ 
    ... 
} 

@Test 
public void creatingDuplicateDatabaseShouldFail(){ 
    createDataBase(); 
    try{ 
     //call create again should fail 
     //could also use ExpectedException Rule here 
     createDataBase(); 
     fail(...); 
    }catch(...){ 
    ... 
    } 
} 

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

Если вы используете инфраструктуру тестирования базы данных, такую ​​как DbUnit или что-то подобное, она может повторно использовать одну и ту же настройку db снова и снова в каждом тесте.

Answer 2

Ваш автоматизированный тест должен моделировать следующее:

1. Настройка
2. Упражнение (SUT)
3. Проверьте
4. Teardown

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

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

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