Как автоматизировать тестирование против другой версии клиентского кода

Question

Допустим, у нас есть Android-клиент и Java-сервер API и код фиксируется в одном и том же хранилище SVN с другой подпапкой

Svn Версия 1: [Версия сервера 1]

Svn версия 2: [версия сервера 1] [версия клиента 1]

Svn версия 3: [версия сервера 2] [версия клиента 1]

Svn версия 4: [версия сервера 2] [версия клиента 2]

Svn версия 5: [версия сервера 3] [версия клиента 2]

Когда разработчик регистрирует версию 5, легко настроить buildserver и попросить maven выполнить интеграционное тестирование, используя последнюю версию клиента версии 2, против кода сервера версии 3.

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

У меня вопрос: есть ли в maven / buildserver что-нибудь встроенное для этого интеграционного теста?

Для моего примера я использую teamcity и maven для автоматизации моего интеграционного теста.

=============================================== ========

После запроса рекомендации Козелки вот способ, которым я собираюсь автоматизировать тест:

Схема Svn

svn repository
    client trunk
    server trunk
    released version
        client release version 1
        client release version 2

каждый раз, когда разработчик регистрируется в стволе сервера, teamcity build будет пытаться выполнить «maven install» серверного кода, упаковать его как артефакт войны и установить в локальный репозиторий maven.

И тогда teamcity будет запущен для проверки клиентской ветви V1, в клиентской версии 1 pom, он зависел от последнего серверного артефакта и запустит джет с использованием последнего серверного артефакта перед интеграцией. протестируйте и протестируйте его, используя представление API версии клиента 1.

То же самое относится и к клиентской версии version2, и для каждого поддерживаемого выпуска клиента потребуется создать отдельный подпроект в teamcity, чтобы гарантировать, что последний сервер обратно совместим со старым представлением API.

Answer 1

Если эти две части находятся в разных подпапках в SVN, я думаю, что вы ищете два отдельных проекта на вашем сервере сборки - и способ их развертывания по отдельности. Если у вас есть версии, которые вам нравятся, вызовите свои юнит-тесты.

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

Я думаю, что в TC вы бы сделали это, имея другой тип "build", который просто развертывает что-то еще. Другие инструменты рассматривают развертывания как отдельные действия.

Answer 2

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

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

Для SVN разветвление описано здесь . Фактически, это просто копирование дерева проекта в другое место (обычно в / branch /), потому что у SVN нет отдельной концепции ветвей. Другие системы контроля версий работают по-разному, но независимо от того, какую из них вы используете, ветки кажутся вам подходящими.

Вероятно, единственным "недостатком" является то, что вам нужно поддерживать тесты отдельно в каждой ветке. Если это проблема (= у вас действительно большое количество тестов), вы можете решить ее, разделив код теста на отдельные модули, разделенные между ветвями. Но, как правило, вы просто объединяете коммиты из одной ветви в другую для достижения той же или аналогичной функциональности; эта опция важна, когда код в ветвях и их тесты достаточно отличаются.