Использование зависимого проекта для тестовых объектов

Предположим, что у меня есть несколько java-проектов, все они используют maven: Project A и Project B.

  • Проект А — это библиотека.

  • Project B — это приложение, использующее Project A.

Оба проекта разрабатываются одновременно. Новые требования проекта A выполняются с новой версией проекта B.

В основном я тестировал свой код вручную, что, как и ожидалось, дало неоптимальное покрытие кода и, следовательно, качество.

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

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

С другой стороны, это создаст своего рода циклические зависимости. В проекте B pom.xml я бы определил обычную зависимость от проекта A, в то время как у проекта A была бы зависимость от проекта B в test-области.

Поэтому следующие вопросы:

  • Возможно ли это технически, или у меня возникнут проблемы с циклическими зависимостями с самого начала или позже? (Я полагаю, что видел, как кто-то делал что-то подобное, где им нужно было определить правильную версию проекта A в разделе проекта A <dependencyManagement>, чтобы убедиться, что при тестировании используется текущий код, а не версия, определенная в проекте B. Я могу' я больше не нахожу его, поэтому я не могу это проверить, но я помню, как меня смущало, почему они определяли версию своих проектов в этом разделе Редактировать: я думаю, что нашел его снова, но, похоже, это что-то другое, я возможно, просто запутался, исследуя junit и тестируя;))
  • Желательно ли использовать нижестоящий проект для классов для тестового примера или есть проблемы, с которыми я могу столкнуться позже? (Моей первой мыслью было бы, что я столкнусь с проблемой, как только заменю проект A сторонней зависимостью в проекте B, поэтому потеряю все свои тестовые примеры для проекта A)
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
1
0
170
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Нет, это не очень хорошая идея.

Прежде всего, вы создаете циклические зависимости. Во-вторых, вы не тестируете то, что хотите протестировать, а именно проект А (не проект Б).

Итак, что ты собираешься делать вместо этого?

Во-первых, подумайте, действительно ли имеет смысл иметь два отдельных проекта А и Б, если они разрабатываются одновременно. Вместо этого вы можете поместить их в многомодульный проект.

Во-вторых, если A — это в основном интерфейсы, может быть более разумно тестировать B (в интеграции с A), а не только A. Если вы обнаружите, что в A есть вещи, которые стоит протестировать, вы можете использовать mocking (например, mockito), чтобы имитировать интерфейсы, которые появляются в ваших тестах.

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

tgdavies 26.12.2020 13:52

Спасибо за ответ! Возможно, мне следует уточнить, что я немного, так как я не совсем уверен, подходит ли вышеизложенное к моему случаю: эти интерфейсы используют отражение (например, для сериализации объекта определенным образом). Простое издевательство над интерфейсом, насколько я понимаю, приведет к пустой сериализации. Тестирование B в интеграции с A звучит как хорошая идея, но можно ли вообще запускать эти тесты автоматически из инструментов CI, таких как действия github? Тесты в A будут запускаться автоматически в процессе сборки A, тесты, написанные в проекте B, не будут запускаться в процессе сборки A.

Jojomatik 26.12.2020 14:44

Насмешка может дать любой ответ, в зависимости от контекста. Вы можете использовать тесты JUnit, которые проверяют B и A вместе. Они будут работать в процессе сборки B.

J Fabian Meier 26.12.2020 19:31

Совместное тестирование A и B, вероятно, бесполезно для меня, так как я хотел бы знать, не сломали ли что-нибудь дополнения к моему коду, как только я отправлю их на github. Но я подробнее рассмотрю насмешки над проектом А. Спасибо.

Jojomatik 26.12.2020 20:29

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

J Fabian Meier 26.12.2020 20:59

Это имело бы смысл. Спасибо. Я не могу сделать это лично, поскольку эти библиотеки изначально разрабатывались в команде для другого проекта, который был приостановлен по внешним причинам, но разработка этих библиотек продолжалась, так как я также завишу от них в своем частном проекте B (который это причины, по которым я не могу поместить оба в один репозиторий), и поскольку мы намерены в конечном итоге продолжить более крупный проект. В любом случае спасибо за отличный вклад :) Я приму ваш ответ, поскольку эти аргументы имеют для меня смысл. По вышеупомянутым причинам я, вероятно, буду тестировать каждый проект отдельно.

Jojomatik 27.12.2020 00:32

Другие вопросы по теме