Harry J. W. Percival - Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript

• 2017-08-02: First Release

Who are you, why are you writing this book, and why should Iread it? I hear you ask.

Im still quite early on in my programming career. They say that in anydiscipline, you go from apprentice, to journeyman, and eventually, sometimes,on to master. Id say that Imat besta journeyman programmer. But Iwas lucky enough, early on in my career, to fall in with a bunch of TDDfanatics, and it made such a big impact on my programming that Im burning toshare it with everyone. You might say I have the enthusiasm of a recentconvert, and the learning experience is still a recent memory for me, so I hopeI can still empathise with beginners.

When I first learned Python (from Mark Pilgrims excellent), I came across the concept of TDD, and thought Yes.I can definitely see the sense in that. Perhaps you had a similarreaction when you first heard about TDD? It sounds like a really sensibleapproach, a really good habit to get intolike regularly flossing yourteeth.

Then came my first big project, and you can guess what happenedthere was aclient, there were deadlines, there was lots to do, and any good intentionsabout TDD went straight out of the window.

And, actually, it was fine. I was fine.

At first.

At first I knew I didnt really need TDD because it was a small website, and Icould easily test whether things worked by just manually checking it out. Clickthis link here, choose that drop-down item there, and this should happen.Easy. This whole writing tests thing sounded like it would have taken ages,and besides, I fancied myself, from the full height of my three weeks of adultcoding experience, as being a pretty good programmer. I could handle it. Easy.

Then came the fearful goddess Complexity. She soon showed me the limits of myexperience.

The project grew. Parts of the system started to depend on other parts. I didmy best to follow good principles like DRY (Dont Repeat Yourself), but thatjust led to some pretty dangerous territory. Soon I was playing with multipleinheritance. Class hierarchies eight levels deep. eval statements.

I became scared of making changes to my code. I was no longer sure whatdepended on what, and what might happen if I changed this code over here, ohgosh, I think that bit over there inherits from itno, it doesnt, itsoverriden. Oh, but it depends on that class variable. Right, well, as long asI override the override it should be fine. Ill just checkbut checking wasgetting much harder. There were lots of sections to the site now, and clickingthrough them all manually was starting to get impractical. Better to leavewell enough alone, forget refactoring, just make do.

Soon I had a hideous, ugly mess of code. New development became painful.

Not too long after this, I was lucky enough to get a job with a company calledResolver Systems (now PythonAnywhere), whereExtreme Programming (XP) was the norm. They introduced me to rigorous TDD.

Although my previous experience had certainly opened my mind to the possiblebenefits of automated testing, I still dragged my feet at every stage. Imean, testing in general might be a good idea, but really? All these tests?Some of them seem like a total waste of time What? Functional testsas well as unit tests? Come on, thats overdoing it! And this TDD test/minimal-code-change/test cycle? This is just silly! We dont need all these babysteps! Come on, we can see what the right answer is, why dont we just skip tothe end?

Believe me, I second-guessed every rule, I suggested every shortcut, I demandedjustifications for every seemingly pointless aspect of TDD, and I came outseeing the wisdom of it all. Ive lost count of the number of times Ivethought Thanks, tests, as a functional test uncovers a regression we wouldnever have predicted, or a unit test saves me from making a really silly logicerror. Psychologically, its made development a much less stressfulprocess. It produces code thats a pleasure to work with.