Searching and Filtering Tests in Test Explorer
If you take a quick glance at the Test Explorer window in Visual Studio 2015, you might not notice all of the power that you have in that little window. To start, there is a grouping icon, that allows you to group your tests by various properties. The grouping is a great way to get common tests together so you can easily select them and run them in test explorer.
You have the option to group by:
Group By | Description |
---|---|
Class | This will group by the class name to which the test belongs. Note: This is not the fully qualified class name, so if you have multiple classes in different namespaces with the same name, they will be hard to differentiate. |
Duration | This will group by the duration of the last test run. It uses 3 categories when grouping (Fast < 100ms, Medium > 100ms, and Slow > 1 sec). |
Outcome | This will group by the outcome of the last run of the tests. It uses 3 categories when grouping (Passed Tests, Failed Tests, and Skipped Tests). |
Traits |
This will group tests based on the TestCategory , Owner , Priority , and TestProperty attributes assigned to tests. Note: Tests can have multiple trait attributes assigned to them and thus a single test could appear multiple times in this view.
|
Project | This will group tests by the project to which they belong. |
While the grouping is nice, the real power in this dialog is the search feature. From the documentation, you can search on the following:
Qualifier | Description |
---|---|
Trait | Searches both trait category and value for matches. The syntax to specify trait categories and values are defined by the unit test framework. |
Project | Searches the test project names for matches. |
Error Message | Searches the user-defined error messages returned by failed asserts for matches. |
File Path | Searches the fully qualified file name of test source files for matches. |
Fully Qualified Name | Searches the fully qualified file name of test namespaces, classes, and methods for matches. |
Output | Searches the user-defined error messages that are written to standard output (stdout) or standard error (stderr). The syntax to specify output messages are defined by the unit test framework. |
Outcome | Searches the Test Explorer category names for matches: Failed Tests, Skipped Tests, Passed Tests. |
Let's take an example. Say I have the following tests in my system (implementations removed for brevity):
[TestMethod]
public async Task TestMethodNone()
[TestMethod, TestCategory("Unit")]
public async Task TestMethodUnit()
[TestMethod, TestCategory("DAL"), TestCategory("Unit")]
public async Task TestMethodDALUnit()
[TestMethod, TestCategory("DAL"), TestCategory("Unit")]
public async Task TestMethodDALUnit2()
[TestMethod, TestCategory("DAL"), TestCategory("Integration")]
public async Task TestMethodADALIntegration()
If I group by trait and don't filter anything, then I'll see the following tests:
Next, I could filter the tests by specifying I only want tests with the Unit trait. The search term would be Trait:"Unit"
:
I can also filter to only show tests that are both DAL and Unit tests by using the search term Trait:"Unit" Trait:"DAL"
:
If I want to exclude tests with a given attribute, I could exclude all DAL tests by using the minus symbol, so my search term would be Trait:"Unit" -Trait:"DAL"
:
You can also pair this with other searchable attributes on the tests. So, after a test run, if I want to find all unit tests that failed, I could use the search term Trait:"Unit" Outcome:"Failed"
:
As you can see, the grouping and filtering available to you in the Test Explorer window is pretty robust; it just takes a little time to dig into it and learn the syntax. The Run unit tests with Test Explorer article on MSDN gives a lot of good information on this topic and is a worthwhile read if you are using this window in your day to day work. Thanks to William Custode for asking a question on StackOverflow that gave me inspiration for this blog post.