Don’t just test the happy path
By: Ben Hosking
Tags: Software Engineering, Software Development, Testing

The point of this article is grumpy developers can still skip and dance down the happy path when it comes to writing and testing their code.

Code Complete 2 has an interesting paragraph.

Avoid Failure

Petroski argues that many spectacular bridge failures have occurred because of focusing on previous successes and not adequately considering possible failure modes. He concludes that failures like the Tacoma Narrows bridge could have been avoided if the designers had carefully considered the ways the bridge might fail and not just copied the attributes of other successful designs

Developers are too happy

The process of development usually goes

Requirements gathered

Functional requirement specified

Technical requirements specified

Code written to deliver requirements

Test –> fix bugs cycle

Developers often focus on delivering the functionality, which is often known as following the happy path

Wiki describes as the Happy Path

In the context of software or information modeling, a happy path is a default scenario featuring no exceptional or error conditions, and comprises the sequence of activities executed if everything goes as expected.[1][2] For example, the happy path for a function validating credit card numbers would be where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response.

Focusing on the happy path and creating the required functionality leaves room for bugs, when end users stray from the happy path into the alternative path or the exception path.

Developers naturally gravitate towards the happy path, often focusing on happy path testing. Developer doesn’t see the functionality from the end users point of view, instead the functionality is viewed primarily from the code point of view.

It isn’t obvious to developer why users would use unexpected values, how the users will use the functionality or what they are trying to achieve using the functionality.

Happy path testing can leave gaps for nulls, incorrect values and a host of error checking/validating errors to slip into a production system because no one has tested these paths.

The other area bugs come in is, is developer under estimate the random actions of end users.

Developers are not good testers

Developers are poor at testing their own code it’s considered good practise to get other people to test the code.

One reason developers miss bugs in is they test everything using the System Administrator role which avoids many permission bugs.

The System Administrator role is a benefit and a curse to CRM developers

It’s difficult for developers to step back and test the functionality rather than test the code. Like writers editing their own writing, they feel attached to their creation to the extent they find it hard to evaluate it dispassionately.

How to avoid failure

An effective way of avoiding failure is writing unit tests for the code. The act of writing unit tests make the developer think

What should this functionality do e.g. what am I testing

What values (min, max) are allowed

What alternative values might be presented

What should happen when an error happens

Thinking before coding is beneficial, sometimes developers are eager to get coding they miss this step out.

Once the code is written is unappealing for developers to write unit tests, so the best method of unit testing is to write unit tests while you create the code and use those unit tests to make sure it’s working as expected.

Thinking about errors and failures is very beneficial. You will capture and avoid many errors. The developer will decide how to handle errors and its usually a choice

Fail fast, abort action

continue and warn the user

Errors are not good but code which has blundered on and changed half the values it was expecting can make a greater mess and take longer to clean up, so it’s better to have a plan up front.

Don’t let these often simple errors slip out of your development environment to the end user, make sure you harden your code.

If you don’t write unit tests you should consider doing it

Why CRM Developers should unit test their code

Experiences of Unit testing with Microsoft Dynamics CRM Projects

If you still are not persuaded to write unit tests make sure you go through you code and look for potential errors, validation checks. Make sure you have decided how you will handle errors in the code. It’s much better/quicker/easier to manage errors in a dev environment than having to add it in at a later date.

More reading for you

TEST YOUR SAD PATH FIRST

Happy Path Testing