Associating CUIT with MTM without a Build Server

29 March 2012 | Daniel Falk | Uncategorized

Here’s an excerpt from a post that talks about how to utilize MTM to execute Automated Tests even if you don’t have the ability to use the Build Process (which is required).

If you aren’t using Team Build to generate your builds yet then you’ll need to use “Fake Builds” that your test plan can reference and use another process to copy your test assemblies / files to the drop location you specify on the fake build, that way when you run your automated tests through MTM it will know where to find the associated test files.  See my earlier post Creating Fake Builds in TFS 2010 for more information on that.  Alternatively you can use tcm.exe to run your tests and point to any share containing your test assemblies / files.

In the most basic scenario you would create an Environment (physical in this case, but there are also virtual environments) that specifies a Test Controller to run your tests against.  When you kick off an automated test run from MTM you’ll have specified the environment to run tests on as well as the build you are running against.  The test assemblies / files from the build you specified will be sent over to the controller & agent much like they were in the previous versions, they’ll be run there, and the results will be posted back to the new system.  From within MTM you can then drill into failed tests and even open up the corresponding trx’s into Visual Studio.

All of this allows you to use all of the new test planning, organization, execution, and tracking features that we’ve added in 2010 with the automated test types that you’ve been producing throughout our earlier releases.  TCM.exe provides some features that allow easier importing of these tests so that you don’t have to generate Test Case work items for each individual test case manually one by one.  It also allows you to easily keep a Test Suite in sync with a unit test assembly for example without having to manually account for added or removed unit tests as you move through the product cycle.

For more details on this refer to this MSDN article.

source link

Leave a Reply