In most likelihood, you run your tests run on a hardware with multiple cores. To make best use of all the cores, you can use the ability of test frameworks to create multiple threads and run your tests in parallel. Multiple test frameworks like XUnit, TestNG, etc support multi-threaded execution. As an example, to enable threads in TestNG, the number of threads are defined in an xml file like below.<\/p>\n
\n \n Defining number of threads in TestNG\n<\/p>\n \n \u00a0\n<\/p>\n Parallelism can be enabled at different levels like test cases, classes, etc and depends on how thread safe your tests are. Depending on the degree of parallelism, you can easily see more than 50% reduction in test run time.<\/p>\n Distribute runs to multiple machines<\/strong><\/p>\n Another way to speed up your unit tests is to distribute your test runs to multiple machines. For example, if you have 3 Build Agent machines, you could distribute 1\/3rd<\/sup> of the tests to each machine and achieve a faster build time.<\/p>\n Lets explore how we can use this technique in TFS. We will start with a Build Definition that build and then runs unit tests in a serial manner, like the one below.<\/p>\n \n \u00a0 \u00a0<\/p>\n Step1. Divide your unit tests into logical sets. For example, you can divide your tests equally across the sets. Or you can do it in terms of priority, or any other way that works for you. For this example, I divide my tests into 3 sets \u2013 MyShuttleTests, MyShuttleClientTests and MyShuttleServerTests<\/p>\n \u00a0<\/p>\n Step2. Add a new variable in the Build Definition with values MyShuttleTests, MyShuttleClientTests and MyShuttleServerTests. I name the variable MyShuttle<\/p>\n \n \u00a0 \n Step3. In the Options section, check the box for \u2018MultiConfiguration\u2019, use the variable name \u2018MyShuttle\u2019 in the Multipliers textbox and also check Parallel.\n<\/p>\n \n \u00a0 \u00a0<\/p>\n Step4. Use the variable name in the Test selection \/ filtering logic of the test task so that one of the slices gets picked up.<\/p>\n \n \u00a0 \u00a0<\/p>\n Step5. Save and Queue the Build. When the Build starts running, 3 parallel builds are created for the 3 values of the \u2018Multiplier\u2019 variable (MyShuttle). Since \u201cParallel\u201d was checked, all 3 builds will start at the same time provided 3 Build Agent machines are available in the Build pool.<\/p>\n Note the 3 builds with the 3 values of the variable MyShuttle starting in parallel.<\/p>\n \n \u00a0 \u00a0<\/p>\n \u00a0Once the run is complete, you can see your test results as in the screenshot below. Since we divided up the tests into 3 sets, we get 3 different runs reported against the build.<\/p>\n \n \u00a0 \u00a0<\/p>\n This approach works for non C# unit tests also. For example, for JAVA tests running using an Ant task, you can create multiple build.xml files, each of which points to one of the test suites. These files will then become the \u2018Multiplier\u2019 for the parallel runs. Below screenshots show sequence of steps for an ANT task.<\/p>\n \n \u00a0 \n Defining the variable with build files\n<\/p>\n \n \u00a0\n<\/p>\n \n \u00a0 \n Using the variable in the ANT task\n<\/p>\n \n \u00a0\n<\/p>\n![\"\"](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/07\/6283.i1.jpg\")
<\/a>\u00a0\n<\/p>\n<\/a>\n<\/p>\n<\/a>\n<\/p>\n<\/a>\n<\/p>\n<\/a>\n<\/p>\n<\/a>\n<\/p>\n<\/a>\n<\/p>\n<\/a>\n<\/p>\n<\/a>\n<\/p>\n