 |
Home > Detail: Test-Driven Development Isn’t Testing
Viewing 3-12 of 5610 Collapse Descriptions
Sort by: Date Posted | Title | Content Type | Relevancy
 BOOK: Test-Driven Development
Author: David Astels
Pages: 562 Published: 2003
Description: (from the Back Cover)
Test-Driven Development: A Practical Guide enables developers to write software that's simpler, leaner, more reliable...just plain better. Now, there's a...More
BOOK: Test Driven Development: By Example
Author: Kent Beck
Pages: 240 Published: 2002
Description: From the Back Cover: When faced with a complex programming challenge, rare is the developer who can readily see how to begin or produce its solution. More often than not, such...More
COLUMN: Test-Driven Development Isn’t Testing
Author(s): Jeff Patton
Summary: There's a common misconception that test-driven development is a testing technique when in fact it's a design technique. In this week's column, Jeff Patton explains this and how you might use your unit tests to explicitly guide and describe the design of your software.
 CONFERENCE MATERIALS: Realistic Test-Driven Development: Paying and Preventing Technical Debt
Author(s): Rob Myers, Agile Institute
Summary: Are you considering implementing Test-Driven Development (TDD), or have you tried it and failed? If so, this class is for you. Rob Myers describes the basic mechanics and components of TDD. In addition, he explains the real long-term benefits to the individual, team, and organization of using this technique. Teams find that their defect rate is considerably lower (compared to no unit testing, or unit testing after coding). Even greater rewards are gained in future enhancements and releases. As developers build a “safety net” of automated tests around the growing product, the team can rapidly modify the design and add features required by changes in a dynamic market. The TDD tests guarantee that any defects introduced in those modifications are quickly detected. Rob shares first-person stories of how TDD provided astounding returns. Rob then explains what is required to implement TDD painlessly and professionally, and gives a brief demonstration to show the levels of detail, the emergent nature of the design, and the thought-processes that occur during TDD coding.
Conference: Agile Development Practices
CONFERENCE MATERIALS: Test-Driven Development Takes On Embedded Software
Author(s): James Grenning, Renaissance Software Consulting, Co.
Summary: Embedded software developers face the same challenges as other software developers—unpredictable schedules, poor quality, and the problems that follow. In addition, embedded software developers must overcome the realities of concurrent hardware/software development, scarce target hardware availability, long download times, high deployment costs, as well as the challenges of testing embedded C. Test-Driven Development (TDD), a key agile practice, helps software developers improve schedule predictability and product quality; but very few embedded software engineers apply TDD to their craft. James Grenning describes the problems addressed by TDD, as well as the additional challenges and benefits of applying TDD to embedded software. He provides valuable lessons for doing TDD in the hostile environment of C. After the class, get hands-on experience with James' independent study exercise, "TDD in C".
Conference: Agile Development Practices
CONFERENCE MATERIALS: Test Driven Development - It's Not Just for Unit Testing
Author(s): Peter Zimmerer, Siemens
Summary: Test-driven development (TDD) is a new approach for software construction in which developers write automated unit tests before writing the code. These automated tests are always rerun after any codes changes. Proponents assert that TDD delivers software that is easier to maintain and of higher quality than using traditional development approaches. Based on experiences gained from real-world projects employing TDD, Peter Zimmerer shares his view of TDD's advantages and disadvantages and how the TDD concept can be extended to all levels of testing. Learn how to use TDD practices that support preventive testing throughout development and result in new levels of cooperation between developers and testers. Take away practical approaches and hints for introducing and practicing test-driven development in your organization.
Conference: STARWEST 2005
CONFERENCE MATERIALS: Test Driven Development (TDD) for Secure Applications
Author(s): James Whittaker, Florida Institute of Technology
Summary: Test Driven Development (TDD) has emerged as a successful productivity technique for development teams. As a unit testing methodology, TDD prescribes a simple three-step process of (1) develop test, (2) write code, and (3) re-factor the code. In a question-and-answer tag-team
session, Herbert Thompson and Ed Adams discuss the value of TDD and drill down on the reasons to use TDD for writing secure applications. Among other useful security testing tips, you will find out ... What the heck is Test Driven Development anyhow? What are the benefits of using TDD? What are the drawbacks and limitations to TDD? Why is TDD so valuable for security? What are the payoffs for using TDD to write secure code? How can we find faults that show up outside unit testing? How do we correct faults that show up outside unit testing? Can you use TDD with other development and testing methodologies? What tools can be used for TDD as well as secure coding and testing practices?
Conference: STAREAST 2005
CONFERENCE MATERIALS: Introducing Test Driven Development
Author(s): Matthew Heusser, Priority-Health
Summary: You may ask, why would anyone write an automated unit test for code that has not yet been written? With Test-Driven Development (TDD), that's exactly what you do-write an automated test that fails; then write the code that makes the test pass; then write another automated test that fails; etc., until the system is completed. This provides an automated regression test suite up front, before the tests can be "skipped" because the project is "running late". Matthew Heusser introduces the concepts and benefits of TDD for the user, the developer, and the organization. Learn how TDD can create confidence that code is complete and works, catch integration defects when they are first created, and, most importantly, provide confidence that a maintenance change did not create regression error. Also, learn what TDD means for testers.
- Basics of test first development and Extreme/Agile Programming
- How to use TDD (with Perl as the example language)
- The problems and practical issues of using TDD for production applications
Conference: STAREAST 2004
MAGAZINE ARCHIVE: Taking Test-Driven Development for a Drive
Author(s): Joel Spolsky
Summary: Sometimes TDD (Test-Driven Development) doesn't get used because it can be cost prohibitive to a testing budget. Read on as Joel Spolsky laments the limited real-life usefulness of test-driven development and discusses some common roadblocks to using this testing technique.
Type of Article: Dept: The Last Word
STQE Issue: Mar/Apr 2003 (Vol. 5 Issue 2)| Date Posted: May 12, 2003 |
ARTICLE: Principle-Driven Development
Author(s): Chuck Allison
Summary: Challenges are inevitable in software development, and formal methodologies may obscure the simpler, basic rules that govern quality. When faced with an overwhelmingly complex challenge, look to proven principles.
|
Viewing Item 3 of 5610
| A StickyMinds.com Original |
|  | |
Test-Driven Development Isn’t Testing
By Jeff Patton
   
Summary: There's a common misconception that test-driven development is a testing technique when in fact it's a design technique. In this week's column, Jeff Patton explains this and how you might use your unit tests to explicitly guide and describe the design of your software. | | |
|
|
 |
For those already doing test-driven development, you probably know that test-driven development is not testing. So, go ahead and grab a cup of coffee, but you should keep reading to see if you agree or disagree.
For a few years I've been using unit testing frameworks and test-driven development and encouraging others to do the same. The common predictable objections are "Writing unit tests takes too much time," or "How could I write tests first if I don’t know what it does yet?" And then there's the popular excuse: "Unit tests won't catch all the bugs." The sad misconception is that test-driven development is testing, which is understandable given the unfortunate name of the technique.
Test driven development is actually a design technique.
If I were designing a bit of code the old-fashioned way, I'd think about the object I was about to create, what it would do, and maybe even write it down or draw a UML diagram. Then I'd write the code. But now I'd start by writing a unit test in my favorite unit-testing framework. (Here's where I get to have fun and pretend I've already written the code for my object.) So, while still imagining my object, I'd ask, "What would its class name be? What other objects would it collaborate with? What methods would I call on it? What would they return?" In my unit test, I instantiate the imaginary object and ask it to do a bit of work for me, which I would assert it did flawlessly. Afterwards, I'm left with a little bit of code that uses the object I have to build, and describes exactly how the object will be used. I've designed the object -- now I just need to write it.
If you're a java developer using a newer IDE, then you know the tests you write give your IDE the information it needs to write much of the code for you. For example, the IDE might offer to create the class and any methods you'd used in the test case, saving you lots of typing. After creating the class, I implement the methods I've described. Here is where it gets fun: I know I've implemented the code as designed by running the unit test!
Once you start looking at your test cases as a description of the software design, they start to look different. Pay attention to the names of your tests. Instead of writing tests named after a method on an object you're testing, try using the test name to capture the intended consequences.
Instead of a single test for the processFoo() method on your object:
testProcessFoo()
Consider:
• testProccesingFooProducesBar()
• testProcessingFooLogsTimingsToFooLog()
• testProcessFooWithBadinputThrowsExceptionContainingBadData()
If I convert those test names to sentences, I might end up with something like this:
• Processing a Foo produces a Bar.
• Processing a Foo logs timings to the Foo Log.
• Processing a Foo with bad input throws an Exception containing the bad data.
Now my names look more like design specifications! Folks who've been doing test-driven development for years see it this way. In Alistair Cockburn's book Crystal Clear, he specifically points out the importance of readability of the test case as a design document. Nifty open source tools like TestDox from Chris Stevenson actually let you browse and write test cases in your IDE as little bulleted design documents.
Now that we've established that test cases can describe design, let's talk about how they can morph into tests.
Following the rhythm described above:
• Describe design in the unit test.
• Write the code to make it work.
• Validate that it works by running the test.
If we repeat this enough times we'll have a lot of these little tests that describe the design. In Hunt & Thomas's book Pragmatic Unit Testing, they suggest asking some questions at this point:
• What else can go wrong?
• Could this same kind of problem happen anywhere else?
The answers to these kind of questions detail my design around edge cases that could cause problems. Thus I start to explicitly deal with designing for and validating the design of the code in a variety of tough conditions. Now this starts to feel more like testing.
At the end of the day, my fattened test case includes all the tests I wrote while I was imagining the design of my conceived of object, and all the tests I wrote while trying to put my newborn object through a workout. There's at least as much code in the test case as in the actual class being tested.
I guess this makes it sort of "design and test," but in the end we still haven't ensured our object is bug-free. We just know where the bugs aren't-–and where the design is. Unit tests have been compared with shining a flashlight into a dark room in search of a monster. Shine the light into the room and then into all the scary corners. It doesn't mean the room is monster free-–just that the monster isn't standing where you've shined your flashlight.
Looking back at the three common reasons for not writing unit tests, let's substitute design for test:
• Designing takes too much time.
• How could I design first if I don't know what it does yet?
• Designing won't catch all the bugs
Those statements sound a bit different now don't they? For those making these sorts of statements about unit testing, be aware that those proficient in test-driven development might be rolling their eyes because the above design statements are what they hear. For those already doing test driven development, put down that coffee and go help others understand your cool design technique.
Sources on the Web:
TestDox from Chris Stevenson
Pragmatic Unit Testing
Alistair Cockburn's Crystal Clear
Editor's Note: For more on this topic, look to the February issue of Better Software magazine, featuring "Double Duty: Using the Unit Tests You're Doing to Help with the Documentation You're Not," by Brian Button. Brian will also facilitate a StickyMinds RoundTable discussion on the topic from Feb 7 - Mar 18, 2005.
About the Author
Jeff Patton is a developer, and user centered designer. He's developed on and coached teams of Agile developers for the last several years. A regular contributor to Better Software magazine and StickyMinds.com, he proudly works for ThoughtWorks.
Back to Top
|
</nobr>.gif)
