JUnit: одни и те же тесты для разных реализаций и детализированных состояний результатов

Question

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

Команда, создающая эталонную реализацию, создала большое количество тестовых случаев на основе Junit (сейчас ~ 700 тестовых случаев), и эти модульные тесты часто запускаются во время разработки. Мы можем запустить один и тот же набор контрольных примеров для реализации производства.

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

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

Здесь есть несколько категорий:

• (A) контрольных примеров, которые имеют значение только для эталонной реализации и никогда не будут важны для производственной реализации

• (B) тестовые случаи, когда при тестировании реализации производства должны быть пропущены только определенные утверждения (т. Е. Дополнительные значения, указанные в ссылочной реализации)

• (C) контрольные примеры, о которых известно, что они не работают в производственной реализации, поскольку разработка некоторых функций отстает, но должны быть включены позднее

Пока у нас есть следующие варианты:

• Загромождение нашего кода утверждениями if, окружающими утверждения, которые работают только в ссылочной реализации. Это решает (B), но трудно поддерживать.

• Использование acceptTrue. Это нормально для (A), но создает ложное впечатление, что все хорошо в (B).

Я бы хотел иметь

• Возможность пропустить определенные тесты в зависимости от условий выполнения, например, с acceptTrue, но их следует указывать как пропущенные, а не успешные для (C)

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

  • Успех для тестового случая, который, как было известно, работал до
  • Исправлено для теста, который, как было известно, не работал до
  • Ошибка тестового случая, который, как было известно, не работал до
  • регрессия для тестового случая, который, как было известно, работал до
  • Пропущенные

Кто-нибудь делал что-то подобное раньше или это вообще возможно с JUnit (и желательно в сочетании с использованием плагина eclipse JUnit)?

Answer 1

Чтобы пропустить тест с условием времени выполнения, вы можете использовать Фильтр , и вы можете игнорировать тест или нет в зависимости от условия выполнения, основанного на аспекте теста (имя лучше аннотация @Development () или @Version () для метода тестирования).

Чтобы использовать это для решения (B), вам понадобятся разные методы тестирования для каждой версии, один для 3.1 и один для 3.2 и т. Д. Может показаться, что это мешает вашим юнит-тестам, но на самом деле облегчает выбор вашей работы. из испытаний, которые применяются к 3.1.

Для части вашего вопроса о машине времени, для junit очень сложно узнать, прошел ли тест раньше. Вам нужно будет где-то записать старые результаты.

Чтобы проанализировать, какие тесты изменили статус (с пройденных на неудачные), запустите ваши тесты junit систематическим образом, например, с помощью системы CI, а затем сохраните результаты где-нибудь, где они могут быть постобработаны для получения регрессий. , Например, надежные xml-отчеты довольно легко анализируются.

Answer 2

Не могли бы вы создать базовый класс, который содержит все тестовые наборы, которые, как известно, работают в обоих случаях, и расширить его двумя другими классами, которые содержат тестовые наборы, относящиеся к производственной и справочной реализациям?более гранулированный, чем этот (например, тест довольно длинный, и 90% его работает как в prod, так и в ссылках), тогда вы можете использовать тот же подход, но поместить утверждения, которые отличаются переопределенными методами, в подклассы.(вам нужно было создать несколько абстрактных методов в базовом классе для поддержки этого)

Answer 3

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