【问题标题】:How to automate test against different version of client code如何针对不同版本的客户端代码自动测试
【发布时间】:2011-08-16 03:22:04
【问题描述】:

假设我们有一个 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,我们当然需要在服务器版本 3 中向后兼容客户端版本 1。

我的问题是 maven/buildserver 是否为这种类型的集成测试内置了任何东西?

对于我的例子,我使用 teamcity 和 maven 来自动化我的集成测试。

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

在寻求 Kozelka 的建议后,我将通过以下方式使测试自动化:

Svn 布局

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

每次开发人员签入服务器主干时,teamcity build 都会尝试对服务器代码进行“maven 安装”,并将其打包为战争工件并安装到本地 maven 存储库。

然后将触发 teamcity 进行客户端 V1 分支的检出,在客户端版本 1 pom 中,它依赖于最新的服务器工件,并将使用集成之前的最新服务器工件启动码头-使用客户端版本 1 api 视图对其进行测试和测试。

同样的事情也适用于客户端 version2 分支,对于每个受支持的客户端版本,都需要在 teamcity 中构建一个单独的子项目,以确保最新的服务器向后兼容旧的 api 视图。

【问题讨论】:

    标签: java android maven continuous-integration


    【解决方案1】:

    我建议您为想要支持的任何版本使用分支。您可以为需要维护的任何版本创建分支。

    如果您的测试发现回归,您将提交对该特定分支的修复;对于您提出的方案,无法进行(和提交)修复,因此整个测试的用处要小得多。

    对于 SVN,分支描述为 here。 实际上,它只是将项目树复制到另一个位置(通常在 /branches/ 下),因为 SVN 没有单独的分支概念。其他版本控制系统的工作方式不同,但无论您使用哪一个,分支似乎都是恕我直言的方式。

    可能唯一的“缺点”是您需要在每个分支中分别维护测试。如果这是一个问题(= 你有大量的测试),你可以通过将测试代码拆分为跨分支共享的单独模块来解决它。但通常你只会将提交从一个分支合并到另一个分支以达到相同或相似的功能;当分支中的代码及其测试有足够的偏差时,此选项很重要。

    【讨论】:

    • 感谢您的回答,很好地使用了 svn 分支功能。
    【解决方案2】:

    如果这两个部分位于 SVN 的不同子文件夹中,我认为您正在构建服务器中寻找两个不同的项目 - 以及单独部署它们的方法。当你有你喜欢的版本时,调用你的单元测试。

    您面临的部分挑战是您想要的部署时间决策与在“构建”时完成大部分测试和部署逻辑之间的不匹配。如果你把这两个概念分开,你可能会有更多的运气,

    我认为在 TC 中,您可以通过另一种“构建”类型来实现这一点,该类型只是部署其他东西。其他工具将部署视为单独的活动。

    【讨论】:

    • 是的,你是对的,maven 一直在教我们将各个方面打包到一个构建过程中,但是有了多客户端支持,你只需要两步验证。
    猜你喜欢
    • 1970-01-01
    • 2012-06-25
    • 2013-06-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-11
    • 2011-11-01
    • 2011-04-25
    相关资源
    最近更新 更多