Erik I

Filed under #testing and #softwareengineering

In a discussion about Kent Becks post Test Desiderata someone asked when they are inexperienced in software testing but still the only one on the team that care about writing tests. I answered it briefly on my way to work yesterday but I'll try to clean it up a bit and add it below as it seemed useful.

But first: if you are at all interested in testing and haven't read Test Desiderata yet, read it. Kent Beck is famous in the field of software development and for good reason!

That said, here is what I wrote, expanded and edited somewhat. The context is still someone who tries to write tests while nobody else cares:

Testing is primarily a tool

Always remember, and particularly if you are alone fighting a good fight to improve quality: if nobody has told you to test and what tests to write then they are just a tool to help you.

I think I was lucky when I was introduced to testing as the guy who introduced our team to it presented it as a tool to reduce boredoom and busywork instead of as a “best practice” that should ideally be followed to be nice.

In his words (as best as I can recall them, and with apologies if it turns out he quoted someone else):

Only software developers launch the entire space shuttle every time they want to test a small change they've made.

Every other engineering discipline uses a test bench or text fixture.

• Glenn Richard Bech, sometime in 2007 or 2008

He then went to prove how we could often save time by testing our new features automatically in 15 seconds flat or something like that instead of having to wait forma full server restart that could easily take 2 minutes just to get to the point where we could start manually verifying our changes.

Start small

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. John Gall

This law holds true for testing as well.

(And if you can keep things simple while expanding it to cover all needs – all the better!)

When planning, look for tests that will speed up your work right now

I often find that adding a minimal test suite will speed up my work significantly.

By starting with those tests you will be building confidence for yourself and goodwill for your work. After all no reasonable boss will get angry with someone who is successfully working to do their work faster and more effectively.

Getting upset if they feel someone is spending time on unnecessary busywork however would be understandable.

Don't care about overall coverage, only that what you are working on now is reasonably tested

Stay with your work. Don't switch context just to improve some statistics.

In addition to the context switches, it also creates noise.

Observe and make at least a mental note when the tests are help you

Your tests can work as both a

• lab bench, keeping your code in place while you work on it
  • how? write a simple test that feeds the code the inputs that are currently working to make sure nothing breaks.
• fall protection
  • how? check in the code, run everything at least every time you are about to push new code, and – especially if nobody else cares – after you check i n code from others: to verify old important code still works.
• a colleague that does pair programming with you, pointing out when you are about to forget something important
  • how? it is hard to explain but you'll hopefully experience it.

If some advice you get doesn't make sense and you can ignore it, do that after trying to understand what it should help for

Don't waste time just because someone says something is a good idea. In keeping with the ideas above keep your tests lean and focused on value add and removal of tedious work instead of focusing on doing it “right”.

So much time is wasted every day in discussions both in teams – but also inside peoples minds – about the correct way to do things. Just don't be so open minded your brain falls out.

(And for anyone working in a team: most of the time, stick with the rules.)

Michael Feathers book “Working Effectively with Legacy Code” might come in handy at some point

If you work late with legacy code this book might help you. If you don't have time can however probably manage without as well 😏:

A couple of months in the laboratory can frequently save a couple of hours in the library.

Frank Westheimer