Software Development Cross Solution - Index of - Free

drive your code with TDD
In TDD, tests DRIVE your implementation
Now you’ve got a working and tested OrderInformation class. And, because of the
latest test, you’ve got getters and setters that all work, too. In fact, the things you put in
the class were completely driven by your tests.
Test-driven development is different from just test-first development in that it drives your
implementation all the way through development. By writing your tests before your
code, you have to focus on the functionality right away. What exactly is the code you’re
about to write actually supposed to do?
To help keep your tests manageable and effective, there are some good habits to get into:
1
2
3
286 Chapter 8
Each test should verify ONLY ONE THING
To keep your tests straightforward and focused on what you
need to implement, try to make each test only test one thing. In
the Starbuzz system, each test is a method on our test class. So
testCreateOrderInformation() is an example of a test that
only checks one thing: all it does is test creating a new order object.
The next test, which tests multiple methods, still tests only one piece of
functionality: that the order stores the right information within it.
AVOID DUPLICATE test code
You should try to avoid duplicated test code just like you’d try to avoid
duplicated production code. Some testing frameworks have setup and
teardown methods that let you consolidate code common to all your
tests, and you should use those liberally. You also may need to mock up
test objects—we’ll talk more about how to do that later in this chapter.
Keep your tests in a MIRROR DIRECTORY of
your source code
Once you start using TDD on your project, you’ll write tons of
tests. To help keep things organized, keep the tests in a separate
directory (usually called test/) at the same level as your source
directory, and with the same directory structure. This helps avoid
problems with languages that assume that directories map to
package names (like Java) while keeping your tests cases out of
the way of your production code. This also makes things easier
on your build files, too; all tests are in one place.
Download at WoweBook.Com
Suppose you need a
database connection: you
could set that up in your
setup() method, and
release the connection in
your teardown() method
of your test framework.