This component makes use of MS Test private method accessors, which require referenced assemblies to be copied to the component build output directory. This will have an impact on the performance of NCrunch, as extra work must be done to rebuild this component every time one of its dependencies changes.
I can see some discussions which discuss setting 'copy assemblies' at project level to true, so that some kind of assembly MSTest creates on the fly to support these accessors can be brought across and allow it to work. Currently that is set to FALSE in my project, though the concurrent testing is still working fine (though I imagine it can be sped up by fixing this).
What I couldn't find is what these accessors actually are. Is it baked into MSTest so that this will always be a problem and I'd need to consider NUnit or something? Or is it something I'm doing in the tests themselves that I can choose to do or not do? At first I thought it was about accessing private members in the class under test, but I figure that's not the case.
Many thanks
Mark
PS. If the answer is 'MSTest is just like this' - any tips on which testing framework works most nicely with NCrunch will be appreciated
MSTest private method accessors are a feature that requires an extra msbuild step when projects using them are built. They are identified by the use of the 'Shadow' project item inside test project files, for example:
NCrunch detects them by searching specifically for declarations like the one above.
The build step enabling private method accessors assumes that the assemblies referenced by the test assembly are co-located. This breaks NCrunch's build optimisations. To allow your solution to build correctly, NCrunch will automatically disable these optimisations and provide you with the warning message you've described. The 'Copy referenced assemblies to workspace' setting is completely disregarded by NCrunch in this scenario, as the only way your project will build is if the engine behaves as though this setting were enabled.
I suggest searching through your test projects for the 'Shadow' items and removing them if at all possible. When you remove them, you'll likely be made aware of build or test failures that will alert you to any tests that required them in order to operate. You can then decide if it's worth leaving them in, or redesigning the tests to improve your NCrunch experience.
glinkot wrote:PS. If the answer is 'MSTest is just like this' - any tips on which testing framework works most nicely with NCrunch will be appreciated
It's possible to use MSTest without the accessors, and then it should work fine :)
NCrunch doesn't integrate with MSTest - it instead runs the tests by emulating MSTest's behaviour. This gives it some opportunities for optimisation over the standard MSTest framework. Although I haven't tested enough to be certain, I would assume that NCrunch's MSTest adapter would perform better than NCrunch's NUnit adapter, due to its simplicity and the lighter use of reflection.