- 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
Engine Modes
By default, NCrunch supports four basic modes of operation. You can toggle between these options through the NCrunch extension menu in your IDE. It's also possible for you to customise NCrunch's operation mode for maximum control over the continuous behaviour.
Run All Tests Automatically
This is the default mode of operation for NCrunch. When in automatic mode, NCrunch will monitor your open windows (along with the file system) for changes made to your projects. As soon as changes are made, NCrunch will automatically build the affected projects then churn through all of the tests in projects related to the change.
Run All Tests Manually
When in manual mode, NCrunch will still monitor all changes to your code and build your projects automatically, but it will not run tests until told to do so. When selecting the Run All Tests option in the top menu or the tests window, execution of these tests will be kicked off in their usual order of priority. This allows you to make several changes in a batch, then have the tests kick off all at the same time and in the most efficient sequence possible.
Manual mode is particularly useful if you are in a situation where the code you are writing is intentionally unstable and is simply not ready for testing. You can also use it as a substitute for automatic mode if you generally wish to have more control over when tests are run - but it is important to still ensure you run your tests routinely, as otherwise your code coverage can get out of date.
Run Pinned Tests Automatically, Others Manually
This mode is best described as semi-continuous. NCrunch will act as though set in manual mode, but it will still automatically queue tests for execution that have been pinned to the Tests Window. This mode is ideal for still getting many of the benefits of a continuous test runner on solutions that haven't been designed with NCrunch in mind. Under this mode, newly created tests will be automatically pinned to the Tests Window.
Run Impacted Tests Automatically, Others Manually
When in this mode, NCrunch will only automatically execute tests that it believes have been impacted by changes made to the codebase. Only impacted tests will be shown with faded inline code coverage in the UI. Be aware that no form of impact detection is 100% accurate. Tests should always be run before committing code to a source control system, even if they are not considered to be impacted.
Custom Engine Modes
NCrunch allows you create custom modes of operation. An engine mode itself is a very powerful option that can override most settings within the engine. The 'Customise Engine Modes' option in the 'Set Engine Mode' drop down menu will open a modal form to make customisation possible.
Engine modes give very broad control over the engine. The settings underneath the 'Filters' group can declare filters as complex as they need to be. Filter options are widely ranged and can include many attributes specific to a test, such as its category, usage of resources, failure and impact status, etc.
Because engine modes can override almost all global and solution-level settings, they can be used to change NCrunch UI elements, performance settings, workflow options, etc. With the flick of a switch, it becomes possible to use NCrunch in an entirely different way.
Engine mode settings overrides are fit within the NCrunch configuration system.