Тесты Junit совместно используют один и тот же объект данных? Должен ли я высмеивать это или что?

Question

У меня есть три класса, которые мне нужно протестировать, скажем, Load, Transform, Perform, и все они начинают или работают с одним и тем же объектом данных, по крайней мере, это то, что требуется, из одного объекта данных X методы Load выполняют свою работу затем он передается Transform, который также выполняет свои методы, и Perform, который немного изменяет объект данных и готов.

Теперь я хочу написать тесты для Load, Transform и Perform.

Объект тестовых данных, если я просто сделаю статический метод в классе Load, как

public static TestData makeTestData(...makeit...)

ИЛИ я должен создать класс TestDataMock или TestDataTest? Который может вернуть пример этого? И сделать новый класс TestDataTest в каждом Load, Transform и Perform, когда им нужно работать над ним?

Answer 1

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

JUnit не поддерживает зависимости, но TestNG поддерживает:

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

@Test(dependsOnMethods = "load")
public void transform() { ... }


@Test(dependsOnMethods = "transform")
public void perform() { ... }

Если transform() не пройден, в итоговом отчете будет указано "1 Passed (load), 1 Failed (transform) and 1 Skipped (perform)", и вы точно знаете, где искать.

Answer 2

Вы всегда должны стремиться сделать юнит-тесты независимыми друг от друга.По этой причине вы всегда должны создавать любые входные тестовые данные, свежие для каждого теста, когда это возможно.То, что вы хотите проверить, это «заданные входные данные X, убедитесь, что выходные данные - Y».JUnit имеет аннотацию @Before, которую можно использовать для аннотирования метода, который должен запускаться перед каждым тестовым примером в этом классе.Как правило, именно здесь вы должны поместить весь свой код настройки (создание и инициализация макетов объектов, создание или загрузка тестовых данных и т. Д.).

Альтернативно, вы можете объединить свои действия Load, Transform и Perform водин контрольный пример, но это было бы больше интеграционным тестом, чем модульным тестом.

Answer 3

Большинство классов тест-кейсов должны быть в стиле класс тест-кейсов на класс : если у вас есть класс X , у него есть один соответствующий класс X Test.Но это не единственный способ делать вещи;если у вас есть группа взаимодействующих классов, вы можете использовать JUnit для какого-либо низкоуровневого интеграционного тестирования взаимодействующих классов.Вам нужно только придумать подходящее имя для этого класса теста.

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

Или вы пытаетесь сказать, что не знаете, как тестировать свои три класса изолированно, потому что они очень тесно связаны, иповедение одного нельзя описать без ссылки на два других?Это говорит о том, что у вас плохой дизайн: рассмотрите редизайн, чтобы вы могли описать требуемое поведение каждого класса в отдельности и, следовательно, протестировать их (по крайней мере частично) в отдельности.