CodeRush for Roslyn: Part 1 - useful features for development through testing
We are releasing a new product - CodeRush for Roslyn (hereinafter CRR ). For over 10 years, we have another product that is simply called CodeRush , or CodeRush Classic ( CRC for short ). The main difference between CRR and CRC is that the Roslyn version uses parsing and language services built into Visual Studio. CRR is completely written from scratch, so it is fast, easy and already contains everything you need to work effectively.
In this article I will talk about support for test frameworks in CRR . In almost all examples, the github.com/dewe/Money project will be used.. This project uses the NUnit Framework, but we also support xUnit, MSpec and MS Test Framework. All of the practices discussed below work the same regardless of which test framework you use.
If we classify developers by the way they use the workspace in Visual Studio, we can distinguish those who hide all the additional Tool Window and allocate maximum free space to the code window, and those who use the Tool Window in the workspace. For the first group, we support the test run directly from the code editor.
As a rule, tests are repaired in more than one iteration, and the developer repeats the sequence of actions several times: changes the code, runs a red test, and checks the result. You can reduce the time required to complete these routine operations usingRepeat Last Test Run in the context menu. After running the tests, you can see the result directly in the editor, also CRR can determine the line that broke the test.
More detailed information on a broken test is also available when you hover over the icon of a problem test.
For those who use the Tool Window, our test runner has a window that can be attached at the bottom of the Visual Studio window, where Output is usually located. Test Runner Tool Window is available through the CodeRush | Windows | Test Runner .
For those who have a wide monitor, it makes sense to place the test runner window on the left or right.
After the run, they usually work with problem tests. In the Test Runner Tool Window, you can set a filter so that only failed tests are displayed.
From the Tool Window, you can go to the code for the problem test or fixture by selecting Go to test ( Go to class ) in the context menu.
In addition to information about the last test run, the Test Runner Tool Window also displays the time taken to run the test or fixture. Thus, slow tests are always visible. You can optimize them or run them separately. Sessions are useful for this. For example, you can add slow tests to a separate session.
After adding the Slow Tests session for brake tests andCommon Tests for everyone else, the Test Runner window will look like this ( Main is the default session, which always contains all the tests).
CodeRush for Roslyn is a new convenient tool for running tests directly in Visual Studio. In addition to the features shown in the article, CRR supports parallel test runs, splitting console output into tests, and much more.
You can download a try in the Visual Studio Gallery .
In the next part, we’ll look at CRR features for writing better code.
In this article I will talk about support for test frameworks in CRR . In almost all examples, the github.com/dewe/Money project will be used.. This project uses the NUnit Framework, but we also support xUnit, MSpec and MS Test Framework. All of the practices discussed below work the same regardless of which test framework you use.
If we classify developers by the way they use the workspace in Visual Studio, we can distinguish those who hide all the additional Tool Window and allocate maximum free space to the code window, and those who use the Tool Window in the workspace. For the first group, we support the test run directly from the code editor.
As a rule, tests are repaired in more than one iteration, and the developer repeats the sequence of actions several times: changes the code, runs a red test, and checks the result. You can reduce the time required to complete these routine operations usingRepeat Last Test Run in the context menu. After running the tests, you can see the result directly in the editor, also CRR can determine the line that broke the test.
More detailed information on a broken test is also available when you hover over the icon of a problem test.
For those who use the Tool Window, our test runner has a window that can be attached at the bottom of the Visual Studio window, where Output is usually located. Test Runner Tool Window is available through the CodeRush | Windows | Test Runner .
For those who have a wide monitor, it makes sense to place the test runner window on the left or right.
After the run, they usually work with problem tests. In the Test Runner Tool Window, you can set a filter so that only failed tests are displayed.
From the Tool Window, you can go to the code for the problem test or fixture by selecting Go to test ( Go to class ) in the context menu.
In addition to information about the last test run, the Test Runner Tool Window also displays the time taken to run the test or fixture. Thus, slow tests are always visible. You can optimize them or run them separately. Sessions are useful for this. For example, you can add slow tests to a separate session.
After adding the Slow Tests session for brake tests andCommon Tests for everyone else, the Test Runner window will look like this ( Main is the default session, which always contains all the tests).
CodeRush for Roslyn is a new convenient tool for running tests directly in Visual Studio. In addition to the features shown in the article, CRR supports parallel test runs, splitting console output into tests, and much more.
You can download a try in the Visual Studio Gallery .
In the next part, we’ll look at CRR features for writing better code.