Achieving Software Testing Nirvana in a CI/CD environment with a sprinkling of Agile – Part II

Part II – What is Software Testing, Why does it Matter And How Do We Approach It?

Software testing is an enabler. An enabler that allows us to think outside the story we are intending on implementing. We need testing because we can’t think of everything, and testing enables us to cover all aspects and gets us into the mindset of “Ok I have implemented a feature, but what if I…”. Requirements and acceptance criteria are but aids, they may not cover all scenarios, testing creates the mindset and allows the approach to cover all the what-ifs. When we work with other people’s software that we integrate with, we can’t be guaranteed that it works, even if they claim so, having integration tests will give us the confidence that they indeed do work to what the third party indicated.

You can think of software testing like a chef tastes his/her own food while cooking it. We taste our own code.


Test Driven Development

What’s it all about?

Test Driven Development or TDD as its most commonly known is an approach used whereby we create the tests first before we write a single line of potential production code. There are 3 main stages to writing a test. We start with arrange, whereby we setup our initializers and/or any instances we need of System-Under Test (SUT). We then act, which invokes the method or unit that will give us our outcome or result that we can finally in the assert phase verify if it is the expected result. We should only write the minimal amount to get our test passing, focusing on a MVP approach. Once our test passes, we can refactor, and with each refactoring our test should continue to pass, this is more commonly known as Red-Green-Refactor. Tests should be aimed at covering both happy and sad path scenarios. TDD is a discipline, similar to double entry book keeping, which is the discipline accountant’s use. This is where an entry for say £50 for a user would be entered into one table for income, and one table for debit, that way it’s an assurance that amount entered will match up on both sides, the sum of credits must match the sum of debits.

Another approach used for testing your software is known as BDD or Behaviour Driven Development, which is essentially the same thing as TDD, just a different mindset approach. It was created as an aid to help developers focus their minds on testing behaviours of the SUT rather than testing the How, which developers originally focused on testing to confirm the SUT did what they expected it to do. It is a feature driven approach to TDD.


The core principles of TDD

You are not allowed to write any production code unless it is to make a failing unit test pass.

You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Red green refactor

Red green refactor is another principle of TDD, whereby a developer will initially write a failing test, and write the minimal amount to then get that to pass, followed by refactoring, which if the test has been written correctly and the resulting production code changes to accommodate refactoring, then it should pass once refactored, a test shouldn’t have to be changed to get it to pass if a change has been made to production code. The other principles that are used with TDD are KISS and YAGNI.


Setting Goals

In a lot of software projects you will see a goal of 80% test coverage is ok. This is not ok, this is like saying its ok to miss 20% of the project, which could be some critical functionality. Setting a goal of 100% should be the default, its ok if you don’t get to 100%, because it’s like when you try to lose weight, you set yourself a goal, but you may never achieve that goal, but at least you may have got close.

Transformation Priority Premise

Transformation Priority Premise (TPP) is an approach to make transformations in TDD easier and more effective. When refactoring, we change the structure of the code, but do not change the behaviour. With transformations, this is the sole means whereby we transform the code to make a test on the red/green/refactor cycle pass. Transformations have a priority or ordering of the tests, where if they are maintained, will prevent impasses. Using this approach we can focus on the simplest transformations in creating passing tests as we implement our production code.

Thanks for reading and keep building awesome.

Until next time!

Ian B

P.S. You can also find me on Twitter: @ianaldo21

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s