Тестирование нескольких реализаций в разных модулях maven? - PullRequest
Новая
       20

Тестирование нескольких реализаций в разных модулях maven?

0 голосов
/ 10 декабря 2018

Теоретический сценарий:

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

Примерно так:

Основной модуль

|- Интерфейс A
|- Интерфейс B
|- ...
|- Интерфейс Z
|- импл
|- GenericImplementationA
|- GenericImplementationB

ModuleA

|- SpecificImplementationOfInterfaceA
|- SpecificImplementationOfInterfaceB
|- ...
|- SpecificImplementationOfInterfaceZ

...

ModuleZ

|- OtherSpecificImplementationOfInterfaceA
|- OtherSpecificImplementationOfInterfaceB
|- ...
|- OtherSpecificImplementationOfInterfaceZ

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

Некоторые возможные решения, о которых я подумал:

  • (A) Написание общих тестов в основном модуле и создание для каждого модуля и каждой конкретной реализации тестового класса, который наследуется от общего теста и проходит определенную реализацию.
  • (B) Создание нового тестового модуля, который наследуется от основного модуля и каждого конкретного модуля, запись там общих тестов и использование Параметризованных тестов junit

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

Есть ли примеры хорошей практики для этого случая?

1 Ответ

0 голосов
/ 10 декабря 2018

Основное назначение модульных тестов состоит в том, чтобы

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

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

Другими словами: когда A имеет некоторую функциональность X, тогда ATest должен проверить это X. Если у вас есть B extends A, то вы хотите провести модульное тестирование всех вещей, которые B имеет «поверх A».

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

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

...