This is another post to follow on from my “What is a *.vsmdi file?” post, this time just a quick note about *.trx files. A *.trx file is generated when you execute tests using MSTest. By default they are placed in a sub-directory called “TestResults” with an associated directory containing input and output files and other associated test result data like Code Coverage and Test Impact Data.
Most unit testing frameworks have a similar capability where they output results into a log file that is then used by the server they use for continuous integration to present the outputs for that build. Team Foundation Server actually ingests the *.trx file into its database and presents the information via the analytics cube. So it is actually quite a useful thing, although most people don’t need to track their *.trx files locally and they are certainly never checked into version control.
Sometimes developers have functional automation tests which they cannot run on their build servers, but they may still want to keep track of tests passing and failing. Here the *.trx file being generated can help because after the local test run it is possible to “publish” those tests results to Team Foundation Server and associate them with a build that ran previously. Obviously it is then the responsibility of the developer that they are associating the test results with a build that best represents the code/system that was under test.
Deployment Items & MSTest Performance
As I mentioned earlier, the test result file also has an associated directory, in which you will find two sub-directories, “In” and “Out”. When a test is executed the test assembly and associated dependencies are copied into this directory and then run. The idea behind this is that the tests run in an isolated part of the file system which makes it possible to pick up issues that might be associated with specific file locations. The [DeploymentItem] attribute can be used to push additional files into this directory as an explicit dependency.
Some people don’t like this behaviour which is understandable. Its one of those differences between testing frameworks that make you love it or hate it – but you have to appreciate the reason why it does it. In Visual Studio 2010, the MSTest framework got some significant performance improvements, and one of the changes they made was automatically disabling “deployment” which is that whole file copy business. As soon as you start using deployment items though it gets turned back on and you pay a performance penalty.