Использование базовых юнит-тестов сборки junit и абстрактной проверки

Question

Предположим, что я создаю функцию ежемесячной оплаты подписки для мобильного приложения, есть несколько способов выставить счет.Это может быть через Apple Pay, Google Кошелек, PayPal, Visa / Master зависит от платформы.Каждый провайдер имеет свою собственную реализацию и соответствующие тесты JUnit (так как они используют Java).

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

Вот мой подход,

public abstract class BaseBillingTest 
{
 public abstract BillCharger getBillCharger();
 public abstract void ValidateTest1(Bill input, Bill output); 
 public void tests_case_1(){
  Bill input = new Bill(<some value>);
  Bill Output = getBillCharger().charge(input);
  ValidateTest1(input, output);
 }
}

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

Есть предложения, чтобы подойти к этому более элегантно?Есть ли шаблоны проектирования, которые я могу применить в этом сценарии?

Answer 1

Оригинальный подход, фактически, применяет шаблон проектирования, он называется Шаблонный метод .

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

Answer 2

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

В обоих случаях наследование не является правильным отношением здесь. Вы можете успешно использовать шаблон Factory для «getBillCharger» или более современный шаблон TestDataBuilders или ObjectMother.

Для второго метода вы можете просто использовать вспомогательный класс. Если вам нужно вызывать одну и ту же логику построения несколько раз в классе Test, вы можете использовать @ Before

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