What do you think?
Rate this book
Unit Test Frameworks
Unit test frameworks are a key element of popular development methodologies such as eXtreme Programming (XP) and Agile Development. But unit testing has moved far beyond eXtreme Programming; it is now common in many different types of application development. Unit tests help ensure low-level code correctness, reduce software development cycle time, improve developer productivity, and produce more robust software. Until now, there was little documentation available on unit testing, and most sources addressed specific frameworks and specific languages, rather than explaining the use of unit testing as a language-independent, standalone development methodology. This invaluable new book covers the theory and background of unit test frameworks, offers step-by-step instruction in basic unit test development, provides useful code examples in both Java and C++, and includes details on some of the most commonly used frameworks today from the XUnit family, including JUnit for Java, CppUnit for C++, and NUnit for .NET. Unit Test Frameworks includes clear, concise, and detailed descriptions It also includes the complete source code for CppUnit for C++, and NUnit for .NET.
- GenresProgrammingNonfiction
212 pages, Paperback
First published October 1, 2004
37 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 3 of 3 reviews
February 1, 2009
It's dry as a bone but it gets the job done.
Unit tests are a major buzzword in software engineering today, and like many trends in that field, there's a fundamental core of a good idea in place that is hyped beyond all reason, probably by publishers of technical books, and romanticized beyond recognition, probably by engineering managers who need to prove how with-it they are to their own bosses by herding their engineers onto the latest train.
Unit Test Frameworks does what an O'Reilly book is supposed to do; get the reader up to speed with the practical applications of a software system, with the authorial voice adopting a conversational, informal tone.
This book also preaches the gospel of test-driven development (TDD), which, in the ideal, means you write all of your tests for a program before you write even one line of the program itself. I find that ideal entirely typical of a Platonic specimen--unrealizable in practice. However, if TDD kicks your butt to write tests early, you will derive much benefit. Writing tests is often tedious, which is why they don't get written. TDD encourages you to eat your liver before you can have dessert. The problem is that, if you're a tool writer, or following an "Agile" approach to software development, you may not know in precise detail what behavior your program needs to exhibit until you've written it, at least in significant proportion. What I end up doing is bouncing back and forth between the tests and the "code" (it's all code).
Two things O'Reilly should correct in the next printing:
p. 167: "Public Methods" should be a heading, not rendered in the typeface meant for code examples.
p. 181, 185: ASCII is not an eight-bit code. This book says it is, and moreover says it is "also known as Latin-1, or ISO 8859-1". Wrong, wrong, wrong. ASCII is a seven-bit code, which is invariably stored in eight-bit bytes these days. ASCII was extended by everybody and his brother, including IBM (their famous "code pages" used by MS-DOS) and the ISO, into other, eight-bit, character encodings which were usually identical--or nearly so--to ASCII in their lower half. This includes ISO 8859-1 ("Latin-1"), which, unlike ASCII, is an eight-bit encoding. When ASCII was first standardized in 1963, the width of the byte itself was not yet standardized. O'Reilly really should have caught this, and no professional software writer should be unaware of it. Whatever his other merits, the author, Paul Hamill, deserves a reprimand for his ignorance on this subject. Consider it dispensed. :-P
Unit tests are a major buzzword in software engineering today, and like many trends in that field, there's a fundamental core of a good idea in place that is hyped beyond all reason, probably by publishers of technical books, and romanticized beyond recognition, probably by engineering managers who need to prove how with-it they are to their own bosses by herding their engineers onto the latest train.
Unit Test Frameworks does what an O'Reilly book is supposed to do; get the reader up to speed with the practical applications of a software system, with the authorial voice adopting a conversational, informal tone.
This book also preaches the gospel of test-driven development (TDD), which, in the ideal, means you write all of your tests for a program before you write even one line of the program itself. I find that ideal entirely typical of a Platonic specimen--unrealizable in practice. However, if TDD kicks your butt to write tests early, you will derive much benefit. Writing tests is often tedious, which is why they don't get written. TDD encourages you to eat your liver before you can have dessert. The problem is that, if you're a tool writer, or following an "Agile" approach to software development, you may not know in precise detail what behavior your program needs to exhibit until you've written it, at least in significant proportion. What I end up doing is bouncing back and forth between the tests and the "code" (it's all code).
Two things O'Reilly should correct in the next printing:
p. 167: "Public Methods" should be a heading, not rendered in the typeface meant for code examples.
p. 181, 185: ASCII is not an eight-bit code. This book says it is, and moreover says it is "also known as Latin-1, or ISO 8859-1". Wrong, wrong, wrong. ASCII is a seven-bit code, which is invariably stored in eight-bit bytes these days. ASCII was extended by everybody and his brother, including IBM (their famous "code pages" used by MS-DOS) and the ISO, into other, eight-bit, character encodings which were usually identical--or nearly so--to ASCII in their lower half. This includes ISO 8859-1 ("Latin-1"), which, unlike ASCII, is an eight-bit encoding. When ASCII was first standardized in 1963, the width of the byte itself was not yet standardized. O'Reilly really should have caught this, and no professional software writer should be unaware of it. Whatever his other merits, the author, Paul Hamill, deserves a reprimand for his ignorance on this subject. Consider it dispensed. :-P
August 2, 2007
A great resource in getting your feet wet in the world of XUnit frameworks. Descriptions of some are found within the book, which proved to be helpful in my work.
March 26, 2014
Thumbs up for using Carl Sagan in the example code!!! I'm new to unit testing and this was a good introductory book. Lots of examples and references for more info were provided.
Displaying 1 - 3 of 3 reviews