CodeRush for Roslyn: Part 1 - useful features for development through testing
We are releasing a new product - CodeRush for Roslyn (hereinafter CRR ). For more than 10 years, we have another product that is simply called CodeRush , or CodeRush Classic (abbreviated as CRC ). 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 the support of 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 the MS Test Framework. All the practices discussed below work the same way regardless of which test framework you use.
If you classify developers by the way they use the workspace in Visual Studio, you can select 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 running the tests directly from the code editor.
')
As a rule, tests are not repaired in one iteration, and the developer repeats the sequence of actions several times: changes the code, starts the red test, checks the result. To reduce the time to perform these routine operations, you can use the Repeat Last Test Run item in the context menu. After running the tests, you can see the result directly in the editor, and CRR can determine the line that broke the test.
Also available is more detailed information on the broken test when you hover the cursor on the problem test icon.
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 main menu CodeRush | Windows | Test Runner .
For those who have a wide monitor, it makes sense to have a 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 those that did not pass tests are displayed.
From the Tool Window, you can go to the problem test code or fixture by selecting the Go to test ( Go to class ) item in the context menu.
In addition to the information on the last test run, the Test Runner Tool Window displays the time taken to run a test or fixture. Thus, slow tests are always visible. You can make them optimized 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 and Common 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 handy tool for running tests directly in Visual Studio. In addition to the features shown in the article, CRR supports parallel test execution, splitting console output by test, and much more.
You can download it in the Visual Studio Gallery .
In the next section, we will look at CRR features for writing better code.
In this article I will talk about the support of 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 the MS Test Framework. All the practices discussed below work the same way regardless of which test framework you use.
If you classify developers by the way they use the workspace in Visual Studio, you can select 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 running the tests directly from the code editor.
')
As a rule, tests are not repaired in one iteration, and the developer repeats the sequence of actions several times: changes the code, starts the red test, checks the result. To reduce the time to perform these routine operations, you can use the Repeat Last Test Run item in the context menu. After running the tests, you can see the result directly in the editor, and CRR can determine the line that broke the test.
Also available is more detailed information on the broken test when you hover the cursor on the problem test icon.
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 main menu CodeRush | Windows | Test Runner .
For those who have a wide monitor, it makes sense to have a 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 those that did not pass tests are displayed.
From the Tool Window, you can go to the problem test code or fixture by selecting the Go to test ( Go to class ) item in the context menu.
In addition to the information on the last test run, the Test Runner Tool Window displays the time taken to run a test or fixture. Thus, slow tests are always visible. You can make them optimized 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 and Common 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 handy tool for running tests directly in Visual Studio. In addition to the features shown in the article, CRR supports parallel test execution, splitting console output by test, and much more.
You can download it in the Visual Studio Gallery .
In the next section, we will look at CRR features for writing better code.
Source: https://habr.com/ru/post/303008/
All Articles