We are just starting to really get into Coded UI. And we are having some debate as to where QA's automation will "live". Our project builds are setup as Continuous Integration, so if we put QA Code into the project a build is kicked off. Recently that
caused a build failure and some upset Developers. I'm not in charge of the Build Definition and I'm not very familiar with its workings.
Is it easy to seperate QA Automation from Application Code so that Builds are not being run (using Continuous Integration) when QA Checks-in Coded UI. And from a Security standpoint QA should not have access to Application Code.
Or is it just easier to keep all QA Automation in a seperate project (with thier own Build Definition) and attempt to associate to test cases from a different project.
移動Tony xiaoModerator2012年3月2日 9:29 (From:Visual Studio UI Automation Testing (includes CodedUI))
As we know that the in TFS CI build (Continuous Integration build) means that every check in will trigger one build. So, if your testers check-in QA code that will trigger one build. And in my opinion, if you have set up your build definition with the
"Continuous Integration" trigger, it is not possible for you avoid building while you check-in.
And the most common way for your scenario is that you can create two branches, one for Testers and for Developrs, from the Main folder. Maybe the folder structure in your Source Control Explorer is similar to:
Main------the main folder which contains all the contents of your application
|__TesterBranch----branched from Main folder which is used by testers
|__DeveloperBranch----branched from Main folder which is used by developers
And then you create two build definitions seperately for the TesterBranch and the DeveloperBranch. That is, all the testers and developers are working with their own source code. These two groups will not affect each other.
In addition, if you testers would like to make sure that all the checked in code can run successfully, you should use the "Gated Check-in" trigger.