Why I wrote a book about Test-Driven Development
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,onto 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 youve 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 or something.
Then came my first big project, and you can guess what happened - there 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 3 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 8 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 tests as well as unit tests? Come on, thats overdoing it! And this TDD test / minimalcode 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.
So, let me tell you all about it!
Aims of this book
My main aim is to impart a methodologya way of doing web development, whichI think makes for better web apps and happier developers. Theres not muchpoint in a book that just covers material you could find by googling, so thisbook isnt a guide to Python syntax, or a tutorial on web development per se .Instead, I hope to teach you how to use TDD to get more reliably to our shared,holy goal: clean code that works
With that said: I will constantly refer to a real practical example, bybuilding a web app from scratch using tools like Django, Selenium, jQuery,and Mock. Im not assuming any prior knowledge of any of these, so youshould come out of the other end of this book with a decent introduction tothose tools, as well as the discipline of TDD.
In Extreme Programming we always pair-program, so Ive imagined writing thisbook as if I was pairing with my previous self, and having to explain how thetools work, and answer questions about why we code in this particular way. So,if I ever take a bit of a patronising tone, its because Im not all thatsmart, and I have to be very patient with myself. And if I ever sounddefensive, its because Im the kind of annoying person that systematicallydisagrees with whatever anyone else says, so sometimes it took a lot ofjustifying to convince myself of anything.
Outline
Ive split this book into three parts.
Part 1 (Chaps 1-6): The basics Dives straight into building a simple web app using TDD. We start by writing a functional test (with Selenium), then we go through the basics of Django models, views, templateswith rigorous unit testing at every stage. I also introduce the Testing Goat. Part 2 (Chaps 7-14): Web development essentials Covers some of the trickier but unavoidable aspects of web development, and shows how testing can help us with them: static files, deployment to production, form data validation, database migrations, and the dreaded JavaScript. Part 3 (Chaps 15-20): More advanced topics Mocking, integrating a 3rd. party authentication system, Ajax, test fixtures, Outside-in TDD and Continuous Integration (CI).
Onto a little housekeeping
Conventions Used in This Book
The following typographical conventions are used in this book:
Italic Indicates new terms, URLs, email addresses, filenames, and fileextensions. Constant width
Used for program listings, as well as within paragraphs torefer to program elements such as variable or function names, databases, datatypes, environment variables, statements, and keywords.