دانلود کتاب توسعه مبتنی بر آزمون با پایتون، از بز آزمایش اطاعت کن، ویرایش سوم

This book has been my attempt to share with the world the journey I took from “hacking” to “software engineering”. It’s mainly about testing, but there’s a lot more to it, as you’ll soon see. I want to thank you for reading it. If you bought a copy, then I’m very grateful. If you’re reading the free online version, then I’m still grateful that you’ve decided it’s worth spending your time on. Who knows; perhaps once you get to the end, you’ll decide it’s good enough to buy a physical copy for yourself or a friend. If you have any comments, questions, or suggestions, I’d love to hear from you. You can reach me directly via obeythetestinggoat@gmail.com, or on Mastodon @hjwp. You can also check out the website and my blog. I hope you’ll enjoy reading this book as much as I enjoyed writing it. Why I Wrote a Book About Test-Driven Development “Who are you, why have you written this book, and why should I read it?” I hear you ask. I was lucky enough early on in my career to fall in with a bunch of test-driven development (TDD) fanatics, and it made such a big impact on my programming that I was burning to share it with everyone. You might say I had the enthusiasm of a recent convert, and the learning experience was still a recent memory for me, so that’s what led to the first edition, back in 2014. When I first learned Python (from Mark Pilgrim’s excellent Dive Into Python), I came across the concept of TDD, and thought, “Yes. I can definitely see the sense in that”. Perhaps you had a similar reaction when you first heard about TDD? It seemed like a really sensible approach, a really good habit to get into—like regularly flossing your teeth. Then came my first big project, and you can guess what happened—there was a client, there were deadlines, there was lots to do, and any good intentions about TDD went straight out of the window. And, actually, it was fine. I was fine. At first. At first I thought I didn’t really need TDD because the website was small, and I could easily test whether things worked by just manually checking it out. Click this 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 adult coding 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 my experience. The project grew. Parts of the system started to depend on other parts. I did my best to follow good principles like DRY (don’t repeat yourself), but that just led to some pretty dangerous territory. Soon, I was playing with multiple inheritance. Class hierarchies eight levels deep. eval statements. I became scared of making changes to my code. I was no longer sure what depended on what, and what might happen if I changed this code over here…oh gosh, I think that bit over there inherits from it…no, it doesn’t; it’s overridden. Oh, but it depends on that class variable. Right, well, as long as I override the override it should be fine. I’ll just check—but checking was getting much harder. There were lots of sections for the site now, and clicking through them all manually was starting to get impractical. Better to leave well 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 called Resolver Systems (now PythonAnywhere), where extreme programming (XP) was the norm. The people there introduced me to rigorous TDD. Although my previous experience had certainly opened my mind to the possible benefits of automated testing, I still dragged my feet at every stage. “I mean, 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, that’s overdoing it! And this TDD test/minimal-code-change/test cycle? This is just silly! We don’t need all these baby steps! Come on—we can see what the right answer is; why don’t we just skip to the end?”