In Visual Studio 2015, Microsoft introduced a feature called IntelliTest. It allows developers to go into their existing code base and create developer unit tests where there have not been any unit tests before. Even if the code has some level of unit test coverage, IntelliTest could be used to help uncover different test pathway that you might not have considered before. If you are not familiar with IntelliTest, check out our previous blogs on the subject here and here.
With Visual Studio 2017 (VS2017), Microsoft has kicked up the developer unit testing experience a notch by adding a new feature called “Live Unit Testing.” When enabled, Live Unit Testing will automatically run all the unit test in your solution in the background, let you know which ones have passed and failed, and hints of their code coverage in the left gutter of the code window.
The dash indicates that the code does not have any test coverage. The red X signifies the line was executed by at least one unit test and failed. The green checkmark signifies the code was executed and any tests that ran passed.
Getting Started
Live Unit Testing supports the top three unit testing frameworks: MSTest, NUnit, and xUnit. If you are using any of these frameworks, you will need to make sure you have latest test adapters and frameworks in your project, which can be obtained through NuGet.
If you do not have the right adapters and frameworks in your solution, don’t worry, Live Unit Testing will remind you in the output window with a message similar to the following:
[08:36:36.548 Error] No test adapters are referenced by this solution. If you have a test project, add a NuGet reference to a test adapter corresponding to the test framework used in order to run the tests. If you already have the required NuGet reference in your test project, performing a NuGet restore may resolve the issue.
[08:36:36.548 Info] Start failed.
[08:36:36.588 Info] Live Unit Testing stopped.
To turn on Live Unit Testing, simply select Live Unit Testing > Start from the Test menu. Once the service starts, it will run all the unit tests in your project. You can pause, stop, or restart the service at any time.
The real value of Live Unit Testing is when the service is running. As soon as you start making changes to your code under test or add/update a TestMethod, Live Unit Testing will be checking your code to make sure your test passes. If your tests are supposed to fail because you are making some major changes, it can help you figure out what TestMethods you need to update. If you don’t expect your tests to fail and they are, then you might have to rethink your changes.
If your code is failing its tests, you can hover over the red X and see how many tests cover that particular line of code. To see which tests are actually failing, clicking on the red X will bring up a dialog that shows which tests have passed and failed. If you hover your mouse over the failed test in the list, you will see the exception message to why it failed. Then you can click on the test name and you will be taken to the test code.
You might be thinking, “I have hundreds (or thousands) of unit tests in my solution...I don’t want this service to run them all.” No worries! You have the option to include or exclude any Unit Test Class files you want Live Unit Testing to use. Select the Unit Test class you want on include or exclude from the context menu.
Unfortunately, at this time, you cannot select specific TestMethods nor is there any indicator either in Solution Explorer or Test Explorer which tests have been included or excluded.
It make you change the way you code
Everyone seem to tote the “test first” or “test driven development” approach to coding and everyone has their own implementation of said approaches. However, regardless of your approaches, using Live Unit Testing just might change the way you code in general. I found the engine to be really fast and when I was using it on a recent project, it made me think twice about the code I was about to update because I going to introduce code to resolve the issue I was tasked with but I immediately found out that lines which had green checkmarks came up with red Xs as soon as typed in my “solution.” After a few minutes, I realized I was thinking too narrow about my solution and needed to broaden my scope. Having the immediate feedback definitely helped me realize I could have introduced more problems then what I attempting to fix. I would have been tasked to correct any addition mistakes I would have introduced. Once I broadened my view, I was able to make the code changes and all indicates stayed green (at least for now).
Excelsior!
