#ncrunch

It’s important to realise that there are lot of factors at play when using a continuous testing tool like NCrunch. Add to that running Visual Studio inside a VM on a Macbook Pro which doesn’t have 4 cores, and you’ll need to be pretty careful to not saturate the CPU and make life harder.

I've done the hard work for you! So if you're using a 13" Macbook Pro with Visual Studio running in Windows under Parallels then this might apply and help you (a lot!):

13" MBPs only have 2 physical cores even though it looks like there are 4 - two of them are HyperThreaded. Make sure Parallels only gets two and not the default 4. Giving the VM 4 will allow Windows to address the HyperThreaded vCPUs as though they are physical ones. This is bad and will cause contention making your performance actually worse.

Limit NCrunch to only 2 threads max. The VM has two (the physical two - Parallels will make sure it's 0, and 2 rather than 1 and 3 which are the HT ones) so NCrunch can have two also, provided that:

You allow NCrunch to use the same core as Visual Studio. This can't be done in the wizard. You need to give NCrunch core 1 and VS cores 0,1 (which are actually the host cores 0 and 2; the physical ones).

It might seem counter-intuitive to make VS share a core but in my experience VS doesn't mind too much and the performance hit is minimal. The fact is, if you don't give NCrunch access to both cores, the two threads you've said it can use will share a core and you won't get the concurrency you want anyway. So thanks to my benchmarking and results, its my way or the highway I'm afraid.

I love NCrunch so when I realised that it wasn’t yet supporting DNX projects, I had to figure out how to get xunit with dnx-watch working easily from Visual Studio (VS).

I already use git-bash but I can’t start dnx test or dnx-watch test from that command line to give me continuously running tests.

So here's an easy way to get a shortcut key in VS to launch cmder (so I can use git too) such that the next command I fire is dnx-watch test:

Install cmder

Set up a ALT+SPACE shortcut in VS but use the $(ProjectDir) in the Arguments field

Change the cmder startup profile to {cmd} rather than {PowerShell} as PS doesn't like the $(ProjectDir) from VS

Launch cmder from VS using ALT+SPACE

Bang out dnvm list and make sure it shows an Active version in your cmder command line (* int the Active column). If it doesn't you'll need to select one using dnvm use 1.0.0-rc1-update1 -runtime clr -architecture x86 -p or similar and then remember to restart VS for the PATH changes to take effect.

Lastly, make sure you have dnx-watch installed, open up your solution and navigate to your test project: bang out ALT+SPACE to open the CLI and pump in dnx-watch test to enjoy continuously running xunit tests.

Ok, nCrunch is no-longer free. It is becoming an obstruction to my IDE. As it would frequently not build due to so-called "configuration" issues. It was far from perfect, as it would error while trying to load and build project file. Here are a couple of nonsense messages that it would spout:

The OutputPath property is not set for project 'nCrunchTemp_5e6263c7-de10-4506-ac9f-d6de768f4f9e'.  Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='Debug'  Platform='AnyCPU'.  You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. NCrunch: This error is commonly caused by projects that are relying on the selected build configuration provided by Visual Studio in order to set the $(Platform) and $(Configuration) MSBuild  properties during a build.  Unless configured otherwise, NCrunch will normally use the default $(Configuration) and $(Platform) properties that are specified in a .proj file - thus in order for your project to  build with NCrunch it must be possible to build the project using command line MSBuild without needing to manually inject build properties.  You will most likely need to edit your .proj file to align its default  $(Configuration) and $(Platform) properties with the property groups provided in the file.

So, in each case, I would unload and edit each of the offending assemblies and replace:

<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>

with:

<Configuration Condition=" '$(Configuration)' == '' ">{Name of assembly configuration in Build > Configuration Manager}</Configuration>

Continuous Testing

Anatoliy 'TLK' Kolesnick (профіль)

NancyFX

Alexander Beletsky (профіль)

І більше.

FubuMVC -- нафига оно мне?!

Serhiy Kalinets (профіль)

Як завжди фотоки. Відмічайте там себе. Завжди цікаво хто є хто ;).

Нагадую про книгy "Дизайн-патерни — просто, як двері" і "Русскоязычный подкаст о дотнете. А также о точке нет, цэ решетке и эф диезе".

Наступна зустріч 16 березня. Event Store та ZeroMQ.

Every time I have to drive my car somewhere far I use a GPS device to navigate to my destination. I can see what's going on with my route and adjust to new conditions instantly without too much attention. In the old days I would have to stop and check the map. Probably very often. Car navigation gives me many advantages, for example:

I see if I'm going in the right direction

I can verify my route

I see if I am making any progress

And this all happens instantly, without having to stop, no time lost, no unnecessary kilometers made.

I like to imagine the good old paper maps verification as a kind of tests. Tests to our progress on the road. They take time and extra effort but are crucial to reaching the destination. I also like to think about the car navigation as an continuous testing framework to our journey. Am I crazy?

I believe I haven't lost my sanity yet. I'm only a geek. Geek that's just found his new favourite toy. It's called The NCrunch.

It's sole purpose is continuous testing with code coverage. These two kinds of tools are already existing, so why bother? I believe it's the way that NCrunch is architected. It works so nice that it instantly makes you wanna sit down and write some awesome code. It's giving you an immediate feedback about the results of tests and the coverage of code. You don't have to fire tests. You don't have run code coverage. You don't have to navigate to find out what lines are failing. No IDE hangs. No blocking. The programming never stops.

It basically works like this - a normal class with test cases will show up as:

That's it. Notice the little green dots. These guys signal that the line they're at is correctly passing tests. If a part of code doesn't have a test case for it then it will look like this:

Now the programmer immediately sees that we don't know what to do with this result. We don't have a test for it. If we don't have a test then how are we going to be sure that the code is executing correctly? How do we know it's working according to the spec? One thing has to be done. It's clear that a developer should add a test to this case.

But what if he by mistake breaks a test? How does he know that? Well usually he would press "run all tests", wait few years and then BAM! a test has failed. Well NCrunch does it for you, noticing what you change. You will instantly see:

Pretty darn useful, isn't it? You should use NCrunch or at least something that does these tricks.

Its biggest advantage is that it works seamlessly in the background and runs tests immediately you make any changes.