Friday, November 02, 2012

Test Clean-Up

I've recently had a massive clean up of dependencies between our Core solution, tests & everything else that comes to mind.

During this time I noticed a number of tests which fell in to the following categories:

WTF?  Are they testing!
They've been in our test suite & build server for a long time in there current guise.  The first set are similar to:
[Test]
public void BuildMeAPanda()
{
     var panda = new Panda("Chi Chi");
     Assert.That("Chi Chi", panda.Name);
}

As you can see we are simply testing the logic of a constructor.  Not too much value in this.  Although it looks good on our code coverage stats!!!  

[Ignored]
The second are ignored tests which seem to have been written with a future intend - i.e:

[Test, Ignore("Really need to work out how to test this!")]
public void InteractWithDb()
{
    var panda = new Panda();
    var repo = new PandaRepository();
    repo.Save(panda);
    // work out what to do here!
}

Broken & [Ignored]
The third are the they broke the build, I must get the build in, quickly ignore the test ones:
[Test, Ignore("This breaks the build I'll re-instate it later")]
public void Bug52358()
{
    // Arrange 
    ... Lots of code
   // Act
   ... Some more code
   // Assert
   ... Some assertion
}

My view on these tests is to eradicate them.  If they've not been in your build cycle for some time then they are not adding any value.  They are simply adding overhead to your build time, your thoughts and general clunk within your solution.

I would also try to re-instate the Broken but ignored tests, however, if they fail and you can't understand them within a time boxed amount of time delete them...

The only occurrence that I've not done this - is on those integration tests where you use them occasionally - a prime example of this is testing email & sms sends.  However, these should appear in a different project called:
  • .IntegrationTests
They should be clearly labelled with:
  • [Ignore("Integration tests!")]

And over time you probably want to delete these too!?!

Tuesday, February 07, 2012

Why is Agile/Lean so tough?

I watched an excellent video by Ken Schwaber the other day regarding SCRUM.  Like all these things certain stuff just resonated with me…

One of the key points was how tough SCRUM was to implement and the relative poor success rate in implementing SCRUM.  The reason behind this is due to the tough questions that SCRUM highlights, my firm belief is that “Agile methodologies” like SCRUM, Kanban, etc do exactly this on the tin.  Highlight your problems – I recall a quote, “It’s like developing software in a room with all the lights full blast, compared to the dark room you’ve been sat in for last 5 years!”

People often see “Agile methodologies” as silver bullets – follow some simple rules and this will change your software development process for the better.  I mean what else could be simpler?  It will make you able to accept changing requirements late in the build process, build better quality and deliver faster.  The honest truth is that just following these simple rules won’t help your process.  The reason you’re looking for a change is usually because of the three reasons highlighted.  
  • You’ve got to accept that there are going to be some really tough questions that are highlighted.  
  • You’ve got to accept that you have to answer these questions to be successful.  
  • Only you can answer these questions, not anybody else.  
  • If you’re scared of answering tough questions and having tough conversations then do not engage with these “methodologies”.  Or if you do then be prepared to fail.  
  • So who is “you” – it’s everyone from the top to the bottom.
The answers to these questions will inevitably lead to change, and once again this change has to be done in the correct manner.  Embracing change, and ensuring that everyone is happy with the change is extremely hard to do – it needs time and effort from people.  It needs people to address people’s concerns, discuss why the change is better than the status quo.   

There are better articles about managing change at the following locations: