- Overview
- Guides
- Concepts
- Considerations And Constraints
- Absolute File References
- Assembly Colocation Assumptions
- Concurrent Use Of Test Resources
- Cross Application Domain Testing
- Heavily Executed Code Under Test
- Implicit File Dependencies
- Multi Threaded Tests
- Netstandard Test Projects
- Project Atomicity
- Project Build Platform And Configuration
- Rdi Data Point Location
- Test Atomicity
- Unique Test Names
- Using NCrunch With Source Control
- Reference
- Global Configuration
- Overview
- Auto Adjust Clashing Marker Colours
- Build Log Verbosity
- Build Process Memory Limit
- Capabilities Of This Computer
- Coverage Marker Style
- Cpu Cores Assigned To NCrunch Or Ide
- Custom Environment Variables
- Disable Global Hotkey
- Engine Hosting Strategy
- Fast Lane Threads
- Fast Lane Threshold
- Grid Maximum Reconnection Attempts
- Grid Reconnection Delay
- Impact Detection Mode
- Listening Port
- Log To Output Window
- Logging Verbosity
- Marker Colours
- Max Failing Test Trace Log Size
- Max Number Of Processing Threads
- Max Passing Test Trace Log Size
- Max Test Runners To Pool
- NCrunch Tool Window Colors
- Node Id (Name)
- Password
- Performance Aggregation Type
- Performance Display Sensitivity
- Pipeline Optimisation Priority
- Rdi Storage Settings
- Sliding Build Delay
- Snapshot Storage Directory
- Solution Storage Data Limit
- Spinner Colours
- Terminate Test Runners On Complete
- Test Process Memory Limit
- Tests To Execute On This Machine
- Text Output Font
- Workspace Base Path
- Solution Configuration
- Overview
- Additional Files For Grid Processing
- Additional Files To Include
- Allow Parallel Test Execution
- Allow Tests In Parallel With Themselves
- Infer Project References Using Assembly
- Instrumentation Mode
- NCrunch Cache Storage Path
- Only Consider Tests Outofdate If Impacted
- Project Config File Storage Path
- Show Coverage For Tests
- Show Metrics For Tests
- Tests To Execute Automatically
- Project Configuration
- Overview
- Additional Files To Include
- Allow Dynamic Code Contract Checks
- Allow Static Code Contract Checks
- Analyse Line Execution Times
- Autodetect Nuget Build Dependencies
- Build Priority
- Build Process Cpu Architecture
- Build Sdk
- Collect Control Flow During Execution
- Consider Inconclusive Tests As Passing
- Copied Project Dependencies
- Copy Referenced Assemblies To Workspace
- Custom Build Properties
- Data Storage File Size
- Default Test Timeout
- Detect Stack Overflow
- Enable Rdi
- Files Excluded From Auto Build
- Framework Utilisation Types
- Ignore This Component Completely
- Implicit Project Dependencies
- Include Static References In Workspace
- Instrument Output Assembly
- Method Data Limit
- Ms Test Thread Apartment State
- Preload Assembly References
- Prevent Signing Of Assembly
- Proxy Process File Path
- Rdi Cache Size
- Required Capabilities
- Restrict Tostring Usage
- Run Pre Or Post Build Events
- String Length Limit
- Track File Dependencies
- Use Build Configuration
- Use Build Platform
- Use Cpu Architecture
- Runtime Framework
- Overview
- Atomic Attribute
- Category Attribute
- Collect Control Flow Attribute
- Distribute By Capabilities
- Duplicate By Dimensions
- Enable Rdi Attribute
- Environment Class
- Exclusively Uses Attribute
- Inclusively Uses Attribute
- Isolated Attribute
- Method Data Limit Attribute
- Requires Capability Attribute
- Restrict Tostring Attribute
- Serial Attribute
- String Length Limit Attribute
- Timeout Attribute
- Uses Threads Attribute
- Global Configuration
- Troubleshooting
- Tools
- Keyboard Shortcuts
- Manual Installation Instructions
Parallel Execution
Purpose
Because of the need to process large numbers of tests within the shortest possible space of time, NCrunch supports the ability to run tests concurrently in separate processes.
Parallel execution can be hugely advantageous as it gives the engine more flexibility to better manage the test pipeline. It can improve the feedback times on short running tests - as more resources are available to pick up the work when required.
Usage
Note that NCrunch will never run tests concurrently within the same process - so you don't need to be concerned about concurrent access to static members, etc.
Many tests make use of resources outside of the test process (i.e. the file system), and therefore not all tests will immediately support being run concurrently. To prevent these tests from raising alarms while you get to grips with NCrunch, parallel execution is turned off by default. It can be turned on at global level by adjusting the Max Number Of Processing Threads global configuration to a value higher than 1, and at solution level by adjusting the Allow Parallel Test Execution solution configuration option to true.
Adjusting the number of tasks to run concurrently often involves some consideration and a little trial and error. Setting a high number will increase the background system load and may cause your system to start running slowly. The best setting is usually equal to the number of processor cores you have assigned to NCrunch. You can control which processor cores you wish NCrunch to use by adjusting the CPU Cores Assigned To configuration options. For more information, see performance tuning.
It's fairly normal that there will be tests in your solution that won't like being run in parallel. These can often be large resource-intensive integration tests that may use exclusive areas of the file system or a database. You should make sure you decorate these with the ExclusivelyUsesAttribute and/or the InclusivelyUsesAttribute.
Windows Store Apps
Unit test projects targeting Windows Store Apps introduce a constraint for NCrunch's parallel execution. Because Windows Store Apps can only have one process running at one time, tests contained in projects targeting these applications cannot be run in parallel. To handle this, NCrunch will automatically add an exclusively used resource constraint on each Windows Store test project that is equivalent the name of the project.
