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.