The solutions I run have one C# project dedicated to unit testing. Each file in this project will contain unit tests for a specific file in other projects. All projects in the solution outside of the unit testing project are VB .NET. I keep a 1 to 1 ratio of .cs unit test files with .vb source code files for organization.
Would NCrunch be able to still do automatic concurrent testing and results by running C# unit tests across multiple files in one project while I am coding in a .vb file in a separate project? Everything is in the same solution.
The overview was a bit confusing being it says you need to write unit tests and then write code "under" the tests. I need to write tests in one project and still have the code coverage and automatic testing features work on code I write in a separate project.
I looked for documentation on this but couldn't find a similar scenario being described. Any feedback is appreciated.
Remco NCrunch Developer
#12459
19 Jul 2018 23:51 UTC
Hi, thanks for posting!
NCrunch doesn't prescribe a particular workflow. Instead, it's better to just look at it as a test runner that works continuously. You don't need to write the test first. You can actually write several test stubs and then choose to write the production code sometime later. NCrunch will do the following:
1. Build your projects every time they change. If they build successfully, go to 2.
2. Discover tests in your projects. If tests are discovered, go to 3.
3. Run all the tests in an intelligent sequence. Wait for more changes to be made, then go back to 1.
NCrunch internally actually doesn't know which code is test code and which code is production code. It just calls the test methods and marks coverage everywhere. It's assumed that you want to see code coverage over your tests as well as your production code.
I can see no reason why NCrunch would fail to work using tests written in C# that target a VB.NET codebase. NCrunch works at IL-level, so technically it doesn't matter which language you use (F# is also supported).
I recommend just installing the tool and having a play with it in a sandbox scenario. This will help you to understand how the tool works without needing to go through the process of using it on an existing solution with prior development history. If you're introducing it to an existing project you sometimes need to add extra configuration to have things work correctly, since NCrunch does introduce some constraints on your testing environment, which are well documented on this site.
NCrunch doesn't prescribe a particular workflow. Instead, it's better to just look at it as a test runner that works continuously. You don't need to write the test first. You can actually write several test stubs and then choose to write the production code sometime later. NCrunch will do the following:
1. Build your projects every time they change. If they build successfully, go to 2.
2. Discover tests in your projects. If tests are discovered, go to 3.
3. Run all the tests in an intelligent sequence. Wait for more changes to be made, then go back to 1.
NCrunch internally actually doesn't know which code is test code and which code is production code. It just calls the test methods and marks coverage everywhere. It's assumed that you want to see code coverage over your tests as well as your production code.
I can see no reason why NCrunch would fail to work using tests written in C# that target a VB.NET codebase. NCrunch works at IL-level, so technically it doesn't matter which language you use (F# is also supported).
I recommend just installing the tool and having a play with it in a sandbox scenario. This will help you to understand how the tool works without needing to go through the process of using it on an existing solution with prior development history. If you're introducing it to an existing project you sometimes need to add extra configuration to have things work correctly, since NCrunch does introduce some constraints on your testing environment, which are well documented on this site.
Post a reply
Log in to reply.