如何针对不同版本的客户端代码进行自动化测试
假设我们有一个 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 install”，并且将其打包为 war 工件并安装到本地 Maven 存储库。
然后teamcity将被触发对客户端V1分支进行签出，在客户端版本1 pom中，它依赖于最新的服务器工件，并将在集成测试和测试之前使用最新的服务器工件启动jetty它使用客户端版本 1 api 视图。
同样的事情也适用于客户端 version2 分支，并且对于每个受支持的客户端版本，都需要在 teamcity 中构建一个单独的子项目，以确保最新的服务器向后兼容旧的 api 视图。
Let say we got an android client and a java api server
and code are commit to same svn repository with different subfolder
Svn Version 1: [Server version 1]
Svn Version 2: [Server version 1] [Client version 1]
Svn Version 3: [Server version 2] [Client version 1]
Svn Version 4: [Server version 2] [Client version 2]
Svn Version 5: [Server version 3] [Client version 2]
When developer checkin version 5, it is easy to setup buildserver and ask maven to do integration-test using latest client version2 against server version 3 code.
However we had a large group of user using version 1, we certainly need backward compatability for client version 1 in serverversion 3.
My question would be does maven/buildserver had anything build-in for this type integration-test?
For my instance I am using teamcity and maven to automate my integration test.
=======================================================
After seeking Kozelka's recommendation, here are the way I am going to get the test automated:
Svn layout
svn repository
client trunk
server trunk
released version
client release version 1
client release version 2
every time developer checkin to the server trunk, teamcity build would try to do "maven install" of the server code, and package it as a war artifact and install to local maven repository.
And then the teamcity will be triggered to do a checkout of client V1 branch, in the client version 1 pom, it had a dependency to the latest server artifact, and will start the jetty using the latest server artifact before the integration-test and test it using client version 1 api view.
The same thing apply to client version2 branch too and for every supported client release, will need to build a seperate sub-project in teamcity to ensure the latest server are backward comptable to old api view.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您对您想要支持的任何版本使用分支。您可以为需要维护的任何版本创建分支。
如果您的测试发现回归，您将向该特定分支提交修复；对于您提出的场景，无法进行（和提交）修复，因此整个测试的用处要小得多。
对于 SVN，分支在此处进行了描述。
事实上，它只是将项目树复制到另一个位置（通常在/branches/下），因为SVN没有单独的分支概念。其他版本控制系统的工作方式有所不同，但无论您使用哪一个，分支似乎都是您应该采取的方式。
唯一的“缺点”可能是您需要在每个分支中单独维护测试。如果这是一个问题（=您有大量的测试），您可以通过将测试代码拆分为跨分支共享的单独模块来解决它。但通常情况下，您只需将提交从一个分支合并到另一个分支即可达到相同或相似的功能；当分支中的代码及其测试偏差足够大时，此选项很重要。
I recommend you to use branches for any version that you want to support. You can create a branch for any version that you need to maintain.
If your test finds regression, you will commit fixes to that particular branch; with your presented scenario there is no way to make (and commit) fixes so the whole testing is much less useful.
For SVN, branching is described here.
In fact, it is just copying the project tree to another location (typically under /branches/) because SVN does not have separate concept of branches. Other revision control systems work differently, but no matter which of them you use, branches seem to be the way you should IMHO go.
Probably the only "disadvantage" is that you need to maintain tests separately in each branch. If this is an issue (= you have really big number of tests), you can solve it by splitting the test code to separate modules shared across branches. But typically you will just merge commits from one branch to another to reach the same or similar functionality; this option is important when the code in branches, and their tests, deviate enough.
如果这两个部分位于 SVN 中的不同子文件夹中，我认为您正在构建服务器中寻找两个不同的项目 - 以及单独部署它们的方法。当您拥有喜欢的版本时，调用单元测试。
您面临的部分挑战是您想要的部署时间决策与在“构建”时间完成的大部分测试和部署逻辑之间的不匹配。如果你把这两个概念分开，你可能会更幸运，
我认为在 TC 中，你可以通过另一个“构建”类型来实现这一点，它只部署其他东西。其他工具将部署视为单独的活动。
If the two pieces are in different sub-folders in SVN, I think you are looking for two distinct projects in your build server - and a way to deploy them individually. When you have the versions you like, invoke your unit tests.
Part of the challenge you are facing, is an mismatch between deployment time decisions of what you want out there, and having much of your testing and deployment logic done at "build" time. If you break those two concepts apart, you might have more luck,
I think in TC, you would do that by having another "build" type that just does a deployment of something else. Other tools treat deployments as separate activities.