Our team is currently facing a situation where we are changing a feature that is in the product today. This feature has Selenium automation tests associated with it.
We are performing a fairly major overhaul of the system, including its UI. We expect this work to take quite a few sprints. During this time, other teams may do work that would affect the feature as it exists today. For this reason, we want the existing automation tests for the feature to remain intact so that they can detect issues.
Of course, we will need to write automation for the feature as it will be after our changes are done. The most efficient way for us to do this from a Dev/QA perspective would be to modify the existing test cases in a separate branch (testing locally) and then merge those changes in when the feature is ready. That way the existing automation continues to function and we don’t have to do extra work duplicating each test.
However, this separate branch doesn’t fit well with the principles of continuous integration (which our organization likes to adhere to). Is our only CI-compliant option to do the extra overhead of duplicating the tests for modification?
6
I would try to see it from this point of view:
-
you are going to develop a parallel branch for a defined time interval (which is of course oppsoed to the “standard” CI model)
-
this will cause a parallel development of your tests as well – branch them accordingly (and merge them back into the trunk when you merge the main source code).
-
apply that branch to your CI environment as well – for example, if you have automated builds and tests on a server, let your server build and test both, the trunk as well as the branch, as long as the branch exists
-
you can still apply continuos integration techniques to your trunk and your branch separately
-
to minimize the effort of merging later, you should try to merge any changes in the trunk back into the development branch as often as possible, once per day would be best. This may not be simple in the area where the UI of the dev branch differs from the trunk, so try to restrict changes to the trunk UI in that area to a minimum during that time.
As you see, when you leave the “CI” path and make a long-term branch and merge, you may have to do it completely, for your whole source code including the tests and the CI environment, causing additional administrative effort. But sometimes pure CI is just not the development model you need and it may be worth it.
EDIT: as an alternative, you could try avoid branching within your VCS and solve your problem with a feature toggle. You could design that toggle in a way so can switch between the old and the new UI at runtime. This may be used within your Selenium tests – modfiy the tests in a way so the old tests run only against the old UI (feature disabled), and the tests adapted to the new UI only against the new UI (feature enabled).
4