Предположим, что у меня есть несколько 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-области.
Поэтому следующие вопросы:
<dependencyManagement>, чтобы убедиться, что при тестировании используется текущий код, а не версия, определенная в проекте B. Я могу' я больше не нахожу его, поэтому я не могу это проверить, но я помню, как меня смущало, почему они определяли версию своих проектов в этом разделе Редактировать: я думаю, что нашел его снова, но, похоже, это что-то другое, я возможно, просто запутался, исследуя junit и тестируя;))



Нет, это не очень хорошая идея.
Прежде всего, вы создаете циклические зависимости. Во-вторых, вы не тестируете то, что хотите протестировать, а именно проект А (не проект Б).
Итак, что ты собираешься делать вместо этого?
Во-первых, подумайте, действительно ли имеет смысл иметь два отдельных проекта А и Б, если они разрабатываются одновременно. Вместо этого вы можете поместить их в многомодульный проект.
Во-вторых, если A — это в основном интерфейсы, может быть более разумно тестировать B (в интеграции с A), а не только A. Если вы обнаружите, что в A есть вещи, которые стоит протестировать, вы можете использовать mocking (например, mockito), чтобы имитировать интерфейсы, которые появляются в ваших тестах.
Спасибо за ответ! Возможно, мне следует уточнить, что я немного, так как я не совсем уверен, подходит ли вышеизложенное к моему случаю: эти интерфейсы используют отражение (например, для сериализации объекта определенным образом). Простое издевательство над интерфейсом, насколько я понимаю, приведет к пустой сериализации. Тестирование B в интеграции с A звучит как хорошая идея, но можно ли вообще запускать эти тесты автоматически из инструментов CI, таких как действия github? Тесты в A будут запускаться автоматически в процессе сборки A, тесты, написанные в проекте B, не будут запускаться в процессе сборки A.
Насмешка может дать любой ответ, в зависимости от контекста. Вы можете использовать тесты JUnit, которые проверяют B и A вместе. Они будут работать в процессе сборки B.
Совместное тестирование A и B, вероятно, бесполезно для меня, так как я хотел бы знать, не сломали ли что-нибудь дополнения к моему коду, как только я отправлю их на github. Но я подробнее рассмотрю насмешки над проектом А. Спасибо.
Если эти проекты тесно связаны, может быть лучше управлять ими в одном репозитории git как многомодульный проект.
Это имело бы смысл. Спасибо. Я не могу сделать это лично, поскольку эти библиотеки изначально разрабатывались в команде для другого проекта, который был приостановлен по внешним причинам, но разработка этих библиотек продолжалась, так как я также завишу от них в своем частном проекте B (который это причины, по которым я не могу поместить оба в один репозиторий), и поскольку мы намерены в конечном итоге продолжить более крупный проект. В любом случае спасибо за отличный вклад :) Я приму ваш ответ, поскольку эти аргументы имеют для меня смысл. По вышеупомянутым причинам я, вероятно, буду тестировать каждый проект отдельно.
Просто протестируйте код из A с помощью модульных тестов в A и код из B с помощью модульного тестирования в B. Что, если вы закончите с проектом C, который также реализует интерфейсы из A? Очевидно, что для этого потребуется набор тестов, отличный от тех, что есть в реализациях B, поэтому тесты должны находиться там, где живет реализация, а не интерфейс.