- 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
Test Categories
As a cross-platform test runner, NCrunch is able to identify the categories of tests as defined by the framework they are expressed in. These categories can be very useful when controlling the behaviour of the continuous test runner through custom engine modes.
Identification of categories is mostly specific to the individual test frameworks. As not all frameworks support categorisation of tests at both fixture and method level, NCrunch introduces a custom attribute, NCrunch.Framework.Category, which can be used to apply categories at both fixture and method level for any test framework.
Category identification for supported test frameworks is as follows:
NUnit
NCrunch will respect any declaration of NUnit's 'Category' attribute, along with any rules around inheritance and context. NUnit's Category attribute is just as powerful as NCrunch.Framework.Category and as such there is no need to use NCrunch.Framework.Category.
MbUnit
NCrunch makes use of MbUnit's Category attribute in the same manner as NCrunch.Framework.Category and it can be applied at both fixture and method level. As such, NCrunch.Framework.Category is not necessary for MbUnit.
MSTest
NCrunch recognises MSTest's TestCategory attribute at method level.
NCrunch also makes use of MSTest's 'TestProperty' attribute in order to establish categories.
As a test property has both a name and a value, NCrunch will put both of these together to form the category of the test. For example, the attribute 'TestProperty("MyName", "MyValue")' will place the test under the category 'MyName=MyValue'.
Where the name of the property is 'Category', NCrunch will use only the value of the property to form the category. For example, the attribute 'TestProperty("Category", "MyCategory")' will place the test under the category 'MyCategory'.
MSTest's TestProperty and TestCategory attributes cannot be applied at fixture level, so fixture level categories can only be declared using NCrunch.Framework.Category.
Xunit
NCrunch makes use of Xunit's 'Trait' attribute in order to establish categories.
As the trait attribute has both a name and a value, NCrunch will apply the same categorisation rules to this attribute as is applied to MSTest's TestProperty attribute (above).
Because the trait attribute can be applied at both fixture level and method level, there is no need to make use of NCrunch.Framework.Category.
MSpec
NCrunch makes use of MSpec's 'Tags' attribute in order to establish categories.
The 'Tags' attribute can only be applied at fixture level, so categorisation at specification level is only possible through the use of NCrunch.Framework.Category. However, it is worth noting that the runtime behaviour of MSpec requires all specifications for a context/fixture to be run together, so trying to categorise specifications separately may not be very useful.