| | How does one go about implementing a test-driven development (TDD) process? What do you need to practice TDD? The key to TDD is automating the code-compile-test process with the right set of tools! We've all heard the expression, "Use the right tool for the job." This expression definitely holds true for TDD. Without the right tools, implementing and maintaining a TDD process can be time consuming and painful. It's a standard practice for development teams to use common build scripts or make files for compiling source code. A good TDD process takes this practice a step further by implementing common scripts that combine the compile and test steps into a standard development process. So, what are the right tools? | Test-driven development has received much attention in the last few years. Many books have been written on the subject, including books by Kent Beck (Test Driven Development), Johannes Link (Unit Testing in Java), and David Astels (Test Driven Development: A Practical Guide). We found test-driven development (TDD) to be an extremely valuable development strategy. However, TDD takes some getting used to before it can be employed effectively. In this article, we share some best practices we discovered that helped facilitate our application of TDD. We'll begin with a background on mock objects, an essential component for our application of TDD, and a topic we refer to throughout the article. | StrutsTestCase is a powerful and easy-to-use testing framework for Struts actions. Using Struts and then StrutsTestCase, in combination with traditional JUnit tests, will give you a very high level of test coverage and increase your product reliability accordingly. | This article detailed a case study using Mock objects in Test Driven Development. It included a full implementation, in a test-first style, of a cache component and its test case. You leveraged how Mock objects are able to stub dependent components in a test code.. Furthermore, you observed the creation of a fully-tested, loosely coupled system with well defined interfaces as a result of following a staged TDD in conjunction with Mock objects. The case study in this article uses Java, JUnit and JMock, but you can employ the same concepts and steps with other programming languages, unit tests and Mock object frameworks. | Stay tuned for the next article in the test-driven development series. The next article, entitled ?Test-driven Development for the Business Tier,? will go into implementation details of how you test server-side components, both EJBs and regular Java classes. | Test-driven development can help to build software better and faster. It offers more than just simple validation of correctness; it can also drive the design of a program. In object-oriented programming, good use of encapsulation can make observing and testing some design features difficult. Further, the developer has to define classes and methods before compiling tests that use those classes and methods. Using the Java Management Extensions -- JMX -- to observe internal state provides an elegant alternative to reflection and compiler hacks. As a byproduct it provides a JMX interface for the completed system. This talk will cover how to benefit from unit testing with JMX, and the code and overhead required to use the technique. | We’ve made some progress in developing our poker game. In part 3, we got sidetracked with building and writing a test for a hash code. As valuable as that exercise was, I’m getting anxious to deal a poker hand—aren’t you? But we can’t do that until we shuffle the cards. The cards are in a specific order in the deck, due to the way we’ve built it. We could ask for a random card from the deck each time we need to deal a card, but I think that violates the spirit of the requirement. Decks should be shuffled, and we should be dealing the topmost card from the deck each time. | | In the last installment, we built a view class that shows a list of players and their positions around the table. It also shows a button labeled Deal that does nothing. It’s not a pretty interface, but it’ll suffice for now. Later we can hire a Swing layout expert to make things look nice. | I met Jerry Jackson while working at a now-defunct dotcom called ChannelPoint; I was there from 1998 through 2000. ChannelPoint, which had been founded by a number of former Sun developers (including Jerry), had a higher-than-average population of Java authors. I believe there were five, including Jerry and me. | As my TDD teacher said, "Practice makes perfect." I needed to do more programming, but in a strict TDD way, so I dabbled here and there as I programmed doing test automation with Ruby. I grew comfortable with the Ruby Test::Unit automated unit test framework, and practiced writing a test and enough code to make that test pass. I was ready to take my TDD practice to the next level, so when I had an opportunity to do more test automation work, I jumped at the chance. After all, test automation is software development, so, as a software tester who does test automation work, this seemed like a great place to try applying TDD so I could learn more. | Most developers don’t worry about exceptions until all the "happy path" coding is done. When forced to deal with the fact that an exception might get thrown, a typical reaction is for the programmer to simply log it and move on: | In the last installment, we added a good chunk of code to the Texas Hold ’Em application. Our application now supports the following features: | One way in which we can strive to improve our own testing is by learning about other testing ideas. Test-driven development (TDD) is one area from which software testers of all kinds of backgrounds and skill sets can learn. I’ve seen some programmers make enormous improvements by using TDD in the work that they deliver. But I’ve also seen programmers place too much trust in TDD alone for testing, and be shocked when their software fails when run through basic, manual functional tests. Testers and developers can learn a lot from each other. | We’ll tackle creating the equality method in two parts. In the first part, we’ll build the equality method incrementally by virtue of simple, sensible assertions. In the second part, we’ll ensure that it adheres to the contract for equality, as laid out in the Javadoc for the Object method equals. | What isn’t premature, however, is our need to eliminate duplication. We must stomp out all duplication; otherwise, our application will slowly but surely die. Given a number of options for eliminating duplication, we can choose any one of them, as long as the one we choose doesn’t introduce unnecessary complexity. Using resource bundles is a simple solution to this problem, and also one that fits into an established standard. The cost is roughly the same either way, so we choose the solution that results in a more flexible design. | In our last installment, we started building support into the Texas Hold ’Em application for the actual game. We got to the point of proving that we could deal hole cards to players. | If you’re a professional software tester, or you work in quality assurance, I consider you to be (like me) a "conventional software tester." Conventional software testers are often asked for opinions and expertise on a myriad of testing-related questions. One new area of thought in software development is test-driven development (TDD). Because it contains the word test, TDD is a topic on which conventional software testers are increasingly asked to weigh in. But since TDD is a programmer-testing activity, conventional software testers often find that they’re inadequately prepared to deal with TDD. | Unfortunately, all that additional up-front design time produces rapidly diminishing returns. It’s simply impossible to create a perfect design for any real-sized system. Can I back up this statement? Consider the article "Engineer Notebook: An Extreme Programming Episode." This piece is a record of two talented developers, Bob Martin and Bob Koss, pairing and using TDD to produce an application that scores a bowling game. | In this installment, I was thinking that we should work on adding betting support to the Hand and Game classes. But our customer—who, after all, is driving the requirements for the application—wants to see something "real." Real feedback to a customer means seeing a user interface of some sort. Showing customers green bars in JUnit isn’t enough to make them happy. The betting code is important, sure, but they’d rather start getting visual feedback first. | Let’s move on and build a Game class—test-first, of course (see Listing 1). We can play Texas Hold ’Em with up to 10 players. We’ll drive out some simple support for creating a game and for adding a single player to the game. | Martin Fowler: That may well be true. It could well be that there are personality differences. However, I think it is hard to tell at the moment because not enough people have tried the test-driven development approach. Test-driven development is common in the extreme programming community, but that's still a very small slice of the programming population. | This article shows you how to bring clarity to your class designs using Unitils, an efficient open source testing framework for Java. Unitils dramatically reduces boilerplate test code through its integration of packages such as JUnit, EasyMock, and DBUnit, which happen to be especially useful for test-driven design. It also provides some tools of its own, which this article also introduces. | XP talks about two kinds of tests: programmer tests and customer tests. Test-driven programming (also called test-first programming) most commonly refers to the first variety, at least when I use the term. Test-driven programming is letting programmer tests (or unit tests -- again, just a choice of terms) drive the code you write. That means you have to have the test before you write the code. The test drives the code you write by dictating what code you need to write. You write only the code necessary to make your test pass -- no more, no less. The XP rule is simple: If you don't have a programmer test, you don't know what code to write, so you don't write any code. | Of course, I have some reasons why I think it's worth the effort. You can read those at the end of the article. In the meantime, I think your reason to bother is that you're doing test-driven development (TDD). You want to drive the existence of all lines of code in your production application by virtue of a failing bit of unit test code. | The FAQ on testdriven.com, written by Jim Dixon, mentions that there are practitioners who say that TDD can't be used in developing multi-threaded code. Jeff Langr, author of several books on Java development, including Agile Java(TM): Crafting Code with Test-Driven Development, explains why multi-threaded code is a consideration. |
|