From the question in thread http://forum.ncrunch.net/yaf_postst2379_Is-it-possible-to-ignore-filter-tests-by-execution-time.aspx:
Remco wrote:If you have a unit test that has a single execution run over 100ms, NCrunch then won't run this unit test again until it's targeted manually and reruns with a lower execution time.
Does this kind of filter work with console tool in some way? (i.e. can it be utilized on CI server to skip those tests with high durations).
If so, can I reuse these (via some NCRunch cache folder I presume) settings to ensure these are executed at a later stage, without having to re-execute all tests?
(This would be extremely cool in CI scenarios, where I then could have 1 "only quick tests" build on each commit, and for those tests not being executed, I fire off another build after a grace period has passed for instance, so I avoid holding up CI time with long running tests).
Absolutely. The console tool is just a headless client, so it has access to all the same settings. The console tool works via automatic execution only, so as long as you set the 'Tests to run automatically' filter accordingly in the console tool's configuration, it will only run the tests that pass this filter.
Be warned that there is no real intelligence behind a time-factored filter. Variations in test running times can cause unexpected things to happen. It might work quite well as long as you have some kind of fallback to ensure all the test are eventually run.
So, given I have the settings below, is it the "NCrunchCacheStoragePath " folder I need to "keep" between sessions in order for NCrunch to remember the previous test states? I guess this also will work with "when impacted" filter then?
GreenMoose wrote:So, given I have the settings below, is it the "NCrunchCacheStoragePath " folder I need to "keep" between sessions in order for NCrunch to remember the previous test states? I guess this also will work with "when impacted" filter then?
Yes, as long as you have the cache storage path pointing to a known directory that will be the same across every build run. You may also need to take steps to prevent multiple builds running in parallel, as this could create some confusing results around the cache data access.