TL;DR
Pushing for test coverage is a bad incentive. It favors quantity over quality. You should prioritize your code with regard to test-worthiness. I discuss three such categories. First there is code that processes unmanaged and possibly malicious (user)input. You should test this for robustness. Secondly there is complex business logic with possible implementation errors. Test this for correctness. Thirdly there are quirks with trusted frameworks running code that doesn’t perform at scale. Run performance tests under realistic production loads to capture these.

If you like to get serious with test automation there are lots of great tools to pack…

Story point estimations get much of their bad reputation from poker sessions where team members are either ill prepared or the variety of skillsets is too great to say anything meaningful. The extraverts then bully the rest into reaching a consensus, or worse, split the difference.

This rings very true. We are tempted to just dig into the code far too quickly at a new job. But then again the question "where can I find your documentation?" is all too often followed by an embarrassed silence from the team..

I love reviews. When it comes to consumer equipment and whether it’s worth your money, it’s a blessing to have so much free advice to choose from. Last year I bought a new 3000-euro Casio Celviano digital piano online during the pandemic, purely based on internet reviews. Not my choice, but retail was locked down and I couldn’t try it out anywhere. Most reviews were favourable to raving, so I found safety in numbers there. Now you have to accept that reviews by retailers of their own wares are biased, but then again nobody would go to the trouble of…

Table Mountain in Crickhowell

In agile development we don’t like to specify to the tiniest detail before we begin coding or estimate the cost down to the last euro. It is a pointless exercise because building complex software is like travelling uncharted territory on foot: you cannot tell how hard the journey will be from a reconnaissance flight. Until you get your feet wet you cannot predict how hard it will be or how long it will take. That’s the definition of a complex, adaptive domain. Like the time I decided to climb Table Mountain in Crickhowell (Wales). …

You don’t need Orthodox TDD to code well

Orthodox TDD: start with a skeleton and slowly dress it up with functionality.

There is plenty of opinions on how to do Test-Driven Development well. Today I want to discuss the drawbacks of the orthodox TDD school, let’s call it OTDD. Although as a development method it lacks a how-to bible like the Scrum Guide, some proponents defend their take with a religious level of conviction. To my understanding OTDD has the following characteristics:

  • You start by writing a failing test against a skeleton implementation. Then you dress it up by implementing the scenario, making the test pass. …
Knole Park, Sevenoaks, Kent, UK

Roy Braam wrote an interesting article in the latest Java Magazine 1/2021 that I wholeheartedly agree with about the dubious usefulness of en-to-end testing. Sorry, no link: it’s a Dutch print magazine, but take my word for it. Just to make it clear: an end-to-end test is not to ensure the integrity of your own software components, but to make sure that they cooperate well with everything that is outside your sphere of influence. As these concerns are opaque and fickle by nature you would think they merit very thorough testing. In practice however you will benefit more from building…

I have always been an advocate of proper unit testing. I believe it is a necessary attribute of building maintainable software. I also thought myself pretty experienced in writing sensible (unit) tests, but reading Unit Testing Principles, Practices and Patterns was an eye-opener in several ways. Vladimir Khorikov spends his 300+ pages teaching us what distinguishes high-quality tests from the time wasters. He assumes you know your way around the tooling already. It’s not a hard book and if you have testing experience you should get through it quickly. The examples are in C# but translate easily to Java. …

I’ve been in IT for 20 years, without a CS degree (MA in English and former teacher). What I lack in mathematical prowess I make up for in analytical insight and people skills, I like to think. I really despise having to re-invent a linked list on a whiteboard, indeed, and suck at it.

Never split the difference is a fascinating book by Chris Voss, nothing to do with software. Voss was once a hostage negotiator for the FBI. The stuff of high-octane Hollywood movies, only for real. He has since switched to the less stressful career of corporate advice and writing said best seller.

Splitting the difference seems a legitimate compromise when the parties can’t agree on their final offer, but in fact everybody gets a bad deal, albeit equally bad. The buyer overpays while the seller is underpaid. The better option would be to walk away. Here’s a mildly amusing footwear example. If you really can’t decide on the black or bron pair, choose the grey pair. Don’t wear one of each. There’s a 50% chance it might rain on our hike. So let’s wear one waterproof boot to be on the safe side.

These are silly examples, but whenever in story point…

Jasper Sprengers

I have been working in software since 1999, writing on whatever fascinates me about the craft, usually with a focus on testing and sensible agile practice.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store