Your Test Suite Sucks… do it again

A pretty smart dude I worked with once told this story of a team he was on.  They spent a few days, maybe even a week, deploying their app.  It was painful, obviously.  They’re response: “That sucked.  Let’s do it again tomorrow.”

Most people try to avoid hard things or at least delay them until they have a good reason, but some things, important things… we should do those more often.  We need to practice the hard things.  They in turn become less risky and less scary bookends to our prideful efforts.

Testing is one of those things.

A few months back there was a thread going on the Scrum.org Professional Scrum Developer Trainers list about topics to include in the future.  Specifically this was in regards to the .Net flavor of the course, because we were getting updates about what was coming down the pipe in the tooling.  My excitement in that course has always focused on testing and with Jason Zander announcing continuous testing for all the major test runners in Visual Studio vNext that was my suggestion.

Adam Cogan, a smart dude in his own right, followed up asking me to describe why I thought that was such a big deal.  I sent a rather long reply that I found useful today while describing the testing pyramid to coworker Steve Gentile.  I thought I’d provide that reply here and get everyone’s thoughts:

We give passing credence to the idea of fast tests that run often versus slow tests that we expand to include before checkin/commit or during automated build (gated).  Unfortunately, the later becomes a catch all for the oops, just got lazy scenario. 

I remember when I first got the automated testing bug.  I wrote some tests (calling them unit tests) that integrated with a 3rd party tool, gave great coverage and awesome feedback.  We knew within 5-10 minutes if a new 3rd party version could be released.  Giant leap.  The next step, though, was hidden.  I would code for 20, 30, 90 minutes or more and then run my tests while I grabbed a cappuccino.

My current passer-by, rock your world tip/tool is NCrunch for .Net or Guard for everyone else (we need this).  Autotest.Net was the first try from James Avery, but it didn’t have any traction and was unstable at best.  Most teams have tests, but they aren’t using them effectively.   (Ok, Nuget and the no-commit pattern is a very close second!)

I run a group call Cincy Clean Coders.  We do katas, often as a whole group.  The first Randori kata we did was eye opening for the audience.  Someone started refactoring to solve a red test and another person threw a fit.  “What are you doing?!  You’re red!  You can’t refactor when your red.”  The driver didn’t intend to be refactoring, they were just solving the current red test in their mind.  They didn’t realize they were mixing many steps into one.  There is a mental burden to doing the simplest thing, running the tests, and only then refactoring.

Teams make a great jump when they automate their important tests.  Nightly feedback from QTP, Test Pro, or Coded UI is a big step.  Consciously mixing unit, integration and acceptance tests is amazing.  Our current tools mandate the start of the feedback loop be a conscious decision.  “So all those changes, wonder if things are still working?  Let’s find out.”  We don’t say it, but that’s how we act.

When your tests run every time you pause (NCrunch) or save a file (Guard) you come to expect feedback NOW.  You skip even CTRL+R,Y until your “finished”, only to find you just did 3,5, 10 refactorings.  Which one caused the problem?  Or you write a test that calls a web service, taking .65 seconds.  Pretty soon “fast” tests take 30-60 seconds (or more!) and your CI build takes 20 minutes.

Continuous testing is (IMO) the next step in shortening the feedback loop.  You start organizing your tests more effectively (or at all).  In good environments, I even use this as a chance to commit.  I now have the luxury of completely ignoring the path I took to my current source situation.  Get into a tizzy, reset/undo checkout.  Committing 10-20 times in an hour isn’t uncommon here.  Neither is branching half a dozen times.

In the PSD I can demo and talk to the importance of running tests often and having confidence, but a blaring red failure on the screen for that last edit really hits home.

I want your test suite to be an invaluable tool.  Continuous testing is one of those pit of success kind of things.  We need more of those.  But when signals pop up solve the real problem.  Don’t delay the pain.

Cincy Clean Coders – Code You Can Show Your Friends

What would a Monday following an Agile conference be without the announcement of a new group focused on quality practices!

 

I’m happy to announce that Cincy Clean Coders is really going to happen.  Details can be found at http://cincycleancoders.com, but suffice it to say the inaugural meeting will be held April 7th at 6pm in the Max Train facilities in Mason, Ohio.

Mark Haskamp was strong armed brave enough to offer to go first with me.  I’ll update the site with the topics for the first meeting soon.

Big Thanks to Ernie Stormann and Parag Joshi who helped push this through.  And a big kudos to the rest of Twitter for being excited about a topic like this.  It says a lot about where our industry wants to be.

Help! You might notice I’m not a designer.  If you want to help, we could use a site design that doesn’t compare to notepad in a browser.  Nothing special, just, you know, some other than black on white text.

Expanding Quality Dev Practices: Clean Coders

I recently blogged and Tweeted this idea for Cincinnati Clean Coders.  It came out of some work I’m doing with a team that was struggling with TDD adoption and steps we are taking to resolve the underlying causes.

This team had been trying really hard for about 2 sprints, and to a lesser degree in sprints prior, to add TDD to their Definition of Done.  During the second retrospective the team made it quite clear there were roadblocks.  We spent quite a bit of time during that retrospective trying to diagnose and come up with a root cause.

The conclusion was that complicated setup in the tests was the blame.  This isn’t uncommon and is certainly a signal that the underlying system under test is doing too much.  What the team decided was that maybe it needed to focus on patterns for small, flexible, clean code.  So the team came up with…

The Clean Code Plan

At the beginning of each week team members each choose a design pattern, development practice, or tool to learn and practice.  At the end of that week each team member would lead a session with the team.  The general agenda of each session would be:

  • Define and Describe the Pattern, Practice, or Tool.  Bring in others thoughts, comments, and interpretations that you’ve found.
  • Demonstrate the pattern in action.  Since we are working on a project the team decided it was best that this *not* be done in the context of that project, but instead be done with a different background.  We wanted to get out of of the confines of the project and clear away any baggage or pressure.  We had one demonstration that was done in alternative languages to the project language which received kudos.
  • Discuss ways that this could be applied to problems in the past or problems that are foreseen.  This part was hard, but I think will be the most fruitful as we move forward.

Fortunately for this team it can take a few hours (3-5) to do something of this nature.  A public group, not so much.  At least not regularly.

So here are my initial thoughts on a more condensed format.  Post your thoughts, ‘cause I’m all ears.  Maybe I’m being too structured here, but that’s my nature.

Duration: 1hour and half: Two 30 minute sessions on two patterns, practices, or tools.

Follow the same agenda of:

  • Define and Describe the Pattern, practice or tool.
  • Demonstrate the pattern, practice or tool.  Must be done in at least two languages or platforms.  I think this is key to getting people outside their comfort zone.
  • Discuss ways to apply in past or upcoming problems.  This is a bit harder, because we don’t have a common project context around our discussions, but I think it’s important to keep this from becoming a rotation of talking heads.  It would hopefully remove some of the intimidation factor of speaking as well.

So what do you think?  Could it work?  We have an industry problem with quality practices, but no plan of attack.  I’m not saying this is one, but maybe it can help.

Cincinnati Clean Coders

I tweeted today that a team I’m working with has started a weekly patterns and techniques learning cycle to expand the team’s toolbox for creating clean, testable, and flexible code.  This came out of some reflection that I’ll dive into in another post.

This tweet sparked some interest and I’m happy to follow the rabbit hole.  So I threw up a twtpoll to find out who is interested in a similar concept, but open to all comers.  It would be entirely language and platform agnostic.  I have some initial ideas on how to make it work in a reasonable amount of time, but we’ll roll with the mood.

So let me know what you think:

Please retweet, email a link, whatever.  Just find people who would benefit (everyone) and convince them it’s a good idea. 

 

Do remember there is bound to be someone willing to sponsor food.  Might not even be pizza.

Greatest Overeager Design Decision: Assignment

In a getting back to basics moment of mine, I started through the TDD Problems.  I found myself on the Console Interaction problem and decided to take a step back from after refactoring.  This is what I saw:

var shape = _console.AskForShape();

var rectange = GetRectange();

_console.PrintArea(rectange.ComputeArea());
_console.PrintCircumference(rectange.ComputeCircumference());

ReSharper was hinting at it, but it should have screamed.  Why do I need to hang on to shape?  I can imagine my mindset at the time.  I was worried about the inevitable decision I would have to make about 20 tests down the road.  That little assignment was the beginning of my overeager, premature design.

Question your code.