NCrunch 3.6.0.2 Visual Studio 2008-2017
NCrunch 3.6.0.2 Visual Studio 2008-2017 | 30 Mb
It intelligently runs automated tests so that you don't have to, and gives you a huge amount of useful information about your tested code, such as code coverage and performance metrics, inline in your IDE while you type.
Automatic Concurrent Testing
A normal cycle of test driven development makes you stop to run your tests so often that it's just plain painful. Think about the steps you usually go through:
Write the test
Stop and run the test
Write the code under test
Stop and run tests
Refactor the code under test
Stop and run tests
Drink some coffee and repeat
NCrunch takes away all the pain and leaves a warm happy feeling behind. So you end up with:
Write the test
Write the code under test
Refactor the code under test
Be happy, drink some coffee and repeat!
Code Coverage
NCrunch collects test coverage for your code while it runs your tests.
This is shown next to your code in coloured markers showing which lines the tests touched, with marker colours indicating pass or fail status.
You can also navigate to any covering tests from any line of code, making it easy to see which tests you might impact with a change.
Full code coverage metrics are also available for your entire solution, allowing you to see where your code coverage is heavy and where it's light.
Performance Metrics
NCrunch profiles your tests during their execution to pick up the execution time of every line of code under test.
Metrics are shown inline conveniently with a tooltip, and 'hot spots' are shown with special colouring on the code coverage markers.
Inline Exception Details
The stack traces of exceptions thrown from your tests are processed by NCrunch and projected over the code coverage markers.
This makes it really easy to spot where your tests went wrong, without the information getting in your way.
No matter where you are in your source code, you'll be able to analyse problems quickly and without fuss.
Intelligent Test Execution
NCrunch tracks all sorts of interesting statistics about your tests, and it uses this information in the most intelligent way possible.
Tests that you have recently impacted with your code changes are highly prioritised for execution.
NCrunch uses a powerful weighting system designed to give you the most important feedback as fast as possible.
Distributed Processing
NCrunch can offload build and test work to other computers for processing.
Tasks are cleanly farmed out to any number of connected machines, forming grids to execute tests.
Grid servers can be shared between developers allowing teams to pool their resources.
Grids can even be scaled into the cloud to maximise testing throughput.
Distributed processing with NCrunch is highly effective, allowing concurrent execution of dozens or possibly even hundreds of tests at any one time.
Changes in v3.6
*****
This version of NCrunch introduces changes to the grid protocol. This means that grid node servers
must be updated before they can be used with the new version.
*****
Fixed an issue where the .deps files for .NET Core projects referencing .NET Standard projects were not being generated correctly. This was causing
such environments to fail to correctly initialise, giving IPC and other runtime exceptions when trying to analyse assemblies or run tests.
Stopped NCrunch from running 'dotnet restore' when loading .NET Core/.NET Standard/CLS projects. NCrunch will still run this command when executed
using the console tool for .NET Core and .NET Standard projects. This change has resulted in the following:
- NCrunch will no longer strip project/package changes that are in-memory in Visual Studio when the engine is running. This was happening because
'dotnet restore' was touching the project files and causing VS to reload them, discarding in-memory changes.
- Initialisation performance has been improved, because 'dotnet restore' can sometimes take several seconds for each individual project
- It is less likely that project load will fail due to 'dotnet restore' concurrency issues, though there is still a risk if VS runs this command
while NCrunch is busy loading a project
- There should be less problems now with 'dotnet restore' timing out or kicking up errors when this is run for CLS projects.
Added handling for projects with multiple target frameworks. When NCrunch encounters these, it will internally duplicate the projects to create
separately targeted versions of them. These duplicate projects and their child tests will be shown with a target framework suffix in the Tests Window.
Fixed NCrunch unable to detect some earlier versions of .NET 4.6.2.
Fixed NCrunch failing to detect changes made by some refactoring actions.
NCrunch will now monitor the project.assets.json file, reloading any project for which this file changes. This has solved several synchronisation
issues related to NCrunch not detecting project changes to .NET Core/.NET Standard/CLS projects inside VS.
Fixed an issue where projects built to target .NET 4.6.2 using the new implicit VS2017 build system were not having the copying of their referenced
assemblies correctly suppressed. This was causing downstream problems such as NUnit being unable to find tests in these projects.
Added a sensible error message for when NCrunch is used with a netstandard test project, because such a setup doesn't make practical sense and was
causing obscure downstream problems.
Introduced several workarounds for problems related to the IDE making several broad file system changes when saving .NET Core/CPS source files.
These problems would cause NCrunch to reload the projects involved, erroneously thinking that they had changed.
*****
This version of NCrunch introduces changes to the grid protocol. This means that grid node servers
must be updated before they can be used with the new version.
*****
Fixed an issue where the .deps files for .NET Core projects referencing .NET Standard projects were not being generated correctly. This was causing
such environments to fail to correctly initialise, giving IPC and other runtime exceptions when trying to analyse assemblies or run tests.
Stopped NCrunch from running 'dotnet restore' when loading .NET Core/.NET Standard/CLS projects. NCrunch will still run this command when executed
using the console tool for .NET Core and .NET Standard projects. This change has resulted in the following:
- NCrunch will no longer strip project/package changes that are in-memory in Visual Studio when the engine is running. This was happening because
'dotnet restore' was touching the project files and causing VS to reload them, discarding in-memory changes.
- Initialisation performance has been improved, because 'dotnet restore' can sometimes take several seconds for each individual project
- It is less likely that project load will fail due to 'dotnet restore' concurrency issues, though there is still a risk if VS runs this command
while NCrunch is busy loading a project
- There should be less problems now with 'dotnet restore' timing out or kicking up errors when this is run for CLS projects.
Added handling for projects with multiple target frameworks. When NCrunch encounters these, it will internally duplicate the projects to create
separately targeted versions of them. These duplicate projects and their child tests will be shown with a target framework suffix in the Tests Window.
Fixed NCrunch unable to detect some earlier versions of .NET 4.6.2.
Fixed NCrunch failing to detect changes made by some refactoring actions.
NCrunch will now monitor the project.assets.json file, reloading any project for which this file changes. This has solved several synchronisation
issues related to NCrunch not detecting project changes to .NET Core/.NET Standard/CLS projects inside VS.
Fixed an issue where projects built to target .NET 4.6.2 using the new implicit VS2017 build system were not having the copying of their referenced
assemblies correctly suppressed. This was causing downstream problems such as NUnit being unable to find tests in these projects.
Added a sensible error message for when NCrunch is used with a netstandard test project, because such a setup doesn't make practical sense and was
causing obscure downstream problems.
Introduced several workarounds for problems related to the IDE making several broad file system changes when saving .NET Core/CPS source files.
These problems would cause NCrunch to reload the projects involved, erroneously thinking that they had changed.
[/b]
[b]
Only for V.I.P Warning! You are not allowed to view this text.