Crafting Java with Test-Driven Development, Part 1: Getting Started
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Software development lies somewhere between science and art. Building quality software requires a careful, methodical approach. It’s very easy to introduce a costly error by not paying enough attention to code construction. It’s also very easy to code yourself into a corner with a rigid design—one that evokes a lot of pain when you try to get it to accommodate further changes.
I view programming as a craft. Learning how to construct high-quality, flexible code is not something that happens overnight or by osmosis. It takes a lot of care. It takes a lot of understanding about what is good design and what isn’t. Unfortunately, most would-be programmers learn little about how to properly craft code. Instead, they learn language syntax, because that’s concrete and easy to quantify. They might learn how to insert trace statements or step through a debugger in order to figure out whether they’re on the right track. They might even learn a bit about object-oriented design patterns. But that’s about all they’ll learn. What they won’t learn is how to get to that high-quality, flexible code ideal.
Test-driven development (TDD) is a technique that not only helps you build high-quality, flexible code; through high levels of feedback, TDD helps you learn how to write good code. You start by writing test code that specifies what you expect to build in your production system. You write these tests before you write the code.
That’s a dramatic difference from the way you first learned to code. Write tests before the code? How do you write tests if you haven’t built the system yet? But that’s exactly what you’ll learn to do with test-driven development: The tests drive the design of your system. Sounds insane!
Doing things this way has one immediate, obvious benefit. You write tests first, for everything, so you immediately have comprehensive test coverage by definition. This gives you the high-quality aspect of the craft.
The built-in learning part comes from the fact that you must think in different terms: "How do I specify this functionality in a test?" As you begin to learn how to answer that question, it leads to another question: "How do I design this system so that I can easily write tests for it?" I’ll uncover the answers to those questions in this series, and you’ll learn as you build the code along with me.
The Series
Over the next six months, I intend to walk you through building a significant chunk of an application, using TDD. We’ll get into some interesting topics, such as how to write tests for nondeterministic (random) code and for GUI code. I say we because I hope to use you as my virtual pair. I welcome feedback; please let me know if you think I could have coded something better, or if you think you know the direction I should head toward next.
I hope to impart one other very important lesson with TDD: You can learn how to design code as you go. You can learn how to program so that your system easily accommodates the addition of just about any new feature. This contention rankles most software developers who’ve heard of TDD but haven’t actually learned how to do it.
Right now, you probably have some preconceived notions about TDD. They might be based either on what you’ve read here so far, or what you’ve heard from other sources. There are literally dozens of perceived negatives about TDD. I’ve heard them all. People are good at coming up with excuses for not doing things. I could counter each of these negatives with data and examples based on actual experience. But that would be defensive and premature. Rather than try to dispel the myths now, I’ll discuss them as we step through building the application.
The application in question is a Java desktop app that supports playing the game of Texas Hold ’Em, a form of poker. The rules are simple, and I can uncover them as we go, much as we can uncover the design as we go.
While we won’t completely flesh out the details of the application, we will build a solid foundation for an application you can complete. You’ll need a Java 2 SE 5.0 development environment and JUnit 3.8.1. JUnit is a simple testing tool that you can download for free from JUnit.org. It also comes built into many development environments, including Eclipse.
Rather than detail the setup of JUnit here, please refer to the documentation that comes with JUnit. I’m not going to belabor a lot of JUnit details. You’ll also find a wealth of other articles at JUnit.org that will help you get started. If you’re still stuck on the setup, please email me.