Software news – February 2012

No comments

Wednesday, February 29, 2012

It’s been a while since last I’ve written about new releases and features in software I like so I’ve decided to shine a light on three software development tools I love, two exiting beta releases and one hidden feature brought into the light:

SharpDevelop 4.2 Beta

The open source, light free .NET IDE has just announced another beta release. I’ve been following #Develop since it was created in the midst of .NET 1 and it just keeps on getting better. This release has a few cool features such as ASP.NET MVC 3 support and MSpec support – with an integrated test runner.

MSpec behaviours in Unit Tests window

The good people of #Develop have added an additional static analysis tool - the dependency metrix.

It always amaze me on how this tool finds new way to innovate and I hope that the Visual Studio team look at this tool from time to time to see what is still missing from Visual Studio.

PostSharp Toolkits

If you don’t know what PostSharp or AOP is – it’s not too late to learn. In a nutshell PostSharp utilize attributes to add cross cutting concerns into existing .NET code. But for those of you that don’t like to see additional attributes on their code there is a new tool on the block. Using NuGet you can add logging to every function on the code with a click of a button. And the great thing is that it’s open source, I plan to dig into the code and find out if I can use the power of the PostSharp SDK…


If you want to know more about it - Igal has written all about it on the SharpCrafters blog.

Isolator 7 Beta

Disclaimer – I used to work at Typemock, regardless I believe that the next Isolator release is going to make some waves. In the next version (V7) Typemock Isolator becomes more than a “mocking tool”. The new Autorunner feature that runs all of the unit tests in the background while checking code coverage is just what I need in my team with the 3000+ tests we have. But that’s not all – Typemock has taken the idea of auto-mocking containers to the next level with the ability to create a fake instance and change the behavior of its dependencies after creation – it’s quite a lot to explain here, I’ll have to write a post just for this feature.

So if it’s sounds interesting – check out this webcast or better yet head to the beta sign-up page and see for yourself.

Why you need to make your tests fail

1 comment

Wednesday, February 15, 2012

Test Driven Development (TDD) have many benefits. For start it’s a design methodology that help avoiding “Analysis paralysis” and make sure that you only have the needed code to solve a problem.
Yesterday I found another benefit of writing the tests before the code – you get to see them fail!
A while back I wrote about another shortcoming of MSTest – how it does not have any built in facility to test against expected exception message.

Unknown to me at the time there was a bug hidden in the code I’ve published – see if you can spot it:
public static class MyAssert
    public static void BadThrows<T>(Action action) where T : Exception

            Assert.Fail("Exception of type {0} should be thrown.", typeof(T));
        catch (T exception)
     // All is well!
BTW this example was simplified for your viewing pleasure - I want to make a point here, not stick to the facts. have you found the bug yet?

Consider the following test:
public void ThisTestWouldNeverFail()
    MyAssert.BadThrows<System.Exception>(() => Dummy.SomeMethod());
Have you guessed it? (hint: its in the test name)

This test would never fail. If we take a closer look at BadThrows we’ll see the problem.

The problem is that the unit testing frameworks throws an exception when assertions fails. And since we’re expecting an exception of type Exception it means that all exceptions thrown (including the AssertFailedException) would be caught – causing the test to pass even if it actually "failed".

That’s right – the test is completely useless – if you want to see the working code just head to this post.

I did not find this bug mainly because I usually don’t throw System.Exception in my code.

The guy that did find this bug found it because he wrote a test and wanted to see it fail. It wasn't enough for him to know that his code made the test pass – he had to make sure that it failed first.
A quick search in our code found multiple tests that did exactly that which means two things:
  1. These test were not written using TDD
  2. The authors did not even bother to see if their tests actually work by making the tests fail
After fixing the bug, one test that started failing – which means that not only was the test wrong – there was a bug in the code as well.

After fixing the bug the whole team has a talk about why throwing “Exception” is not a good idea and how tests need to be “tested” by seeing them fail. Following a quick bug & exception hunt in which we've fixed the tests and the code.
I think I learnt quite a lot from this experience, I know now who does TDD and who doesn't and now I know another issue to look for when developers write their tests after the code.

Happy coding…
Related Posts Plugin for WordPress, Blogger...