CODEWITHSUNDEEP
javaandroidmavencontinuous-integration
laiBilly
laiBilly

Reputation: 77

How to automate test against different version of client code

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.

Upvotes: 0

Views: 349

Answers (2)

EricMinick
EricMinick

Reputation: 1477

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.

Upvotes: 1

Petr Kozelka
Petr Kozelka

Reputation: 7990

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.

Upvotes: 1

Related Questions