Improving your Code with PHPUnit and Test Driven Development: Part 2

Recap: In an effort to change the coding world for the better, make new friends and drink so much amazing free Truth coffee that I could see through time, I presented a workshop on Improving Code with PHPUnit and TDD at WordCamp Cape Town 2018. As the caffeine hasn’t yet left my system, and because not everyone could be there, I am now attempting to document this momentous occasion. In part one we looked at getting set-up and ready for testing our code. Now its time to get to our teeth into the “How” and “Why” of testing.

How Do We Test
Everything worth knowing about in life follows one of these simple rules:

It rhymes.
It’s alliterative.
It has FACT! written after it in the internet forum you read it in.

Testing is too serious for amusing rhymes, but it does have a nice alliterative example for how we test. I can’t remember where I first encountered this, but I would imagine it was in a Chris Hartjes course. It definitely isn’t mine because I generally use four letter words when describing testing:

  1. Arrange dependencies
  2. Act on the code you are testing
  3. Assert that outcomes are as expected

Below is a real-life example of just that. This test is asserting that a method to filter out all exchange rates that aren’t tagged with the required “quote_code” is doing what it says on the tin. First we arrange all the dependencies required for the test. Then we act on the method “generate_feed” before asserting that it’s done what it was supposed to do. I can’t think of a word beginning with “A” to describe losing your temper and swearing a lot, so let’s hope that the test passes.

So now we know the theory of how to test. We could just move onto the practicalities of it, but I can hear cynical mutterings from the back so its time to address the elephant in the room…

At this point I could strap on my “The End is Nigh” sandwich board and start predicting horrendous things for everyone who doesn’t test. I could tell you that at some point you are going to add a new feature and break existing code. I could warn you about the perils of expanding to include more developers and a new hire unleashing buggy code into your codebase, or I could go all touchy-feely and mention that tests act as documentation for your code and will save you hours of trying to work out just what the “thing” is that the function called this_does_the_thing() does.

You might be coming round to my way of thinking at this point, but if you aren’t thinking “doesn’t this mean I have to write twice as much code?” then I can guarantee that whoever is paying for your time is.

For a well written argument as to why this simply isn’t true, read TDD & The Lump of Coding Fallacy by GeePaw.

For a gimmicky, shock and awe clickbait argument as to why you should test, read on…

Let’s imagine a developer is in charge of a team writing some incredibly complex software.
Now let’s imagine there are some simple bits of code required for this software, and there’s an intern who seems quite competent.
Let’s say that the intern is trusted to write these bits of code.
Let’s say that the intern isn’t great with conversion, but neglects to mention this to anyone.
You can refer to example one in the GIT repo for this (see part one for details), or see below:

At this point you can go to wordcamp-tdd/tests/class-example-one-tests.php and finish off the test there to establish whether the intern got it right, or, read on…

Now lets say that you have been recruited to the team.
Lets imagine that you went to a workshop recently.
Perhaps it was about testing code.
Maybe the host was rather a dashing chap who was overflowing with charisma and had the room in the palm of his…
Where was I
Ah yes,
you are a recent convert to the world of testing.
You suggest tests for all the code.
You write and run something like the below

You run the test, and it fails.

Now would be a good time to mention that the team is “NASA”, and the software is for the Climate Orbiter spacecraft. Your test means that the code bug is fixed and the Climate Orbiter spacecraft doesn’t drift off into outer space never to be seen again at a cost of $125 million dollars.

Someone may also mention that this happened in 1998 and PHPUnit wasn’t about then and that the intern stuff is all conjecture. They may also mention that it wasn’t a conversion to kilometres that caused the issue it was a conversion from Newtons to whatever the hell the metric version of Newtons is, but think of this as the Hollywood adaptation of what went down back in 98 and go with it.

Still not convinced?

“Gerald Weinberg reported ten years ago that the three most expensive programming errors of all time each cost hundreds of millions of dollars and that each was a one-line, coding-level mistake.”
(Steve McConnell, Code Complete)

So by now you are either won over by my dramatic examples from a galaxy far, far away (and Code Complete), or you raised your eyebrows at my sense of drama and wisely opted to read GeePaw’s thoughts instead. Either way, you should be convinced by now and prepared to tune in again next week to read up how to incorporate testing into your routine immediately. If you aren’t then you are clearly some kind of free-wheeling anarchist who won’t be happy until you’ve watched the world go up in flames and probably won’t make it to next Friday without doing something reckless and irresponsible anyway.

Until next time.


One thought on “Improving your Code with PHPUnit and Test Driven Development: Part 2

  1. Pingback: Improving your Code with PHPUnit and Test Driven Development: Part 1 | Pointy Brackets

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.