Section 13.3. Design Then Test Then Code


13.3. Design Then Test Then Code

This is the slogan of the test-oriented crowd, and if it sounds a bit impossible, it is. It's hypeit got your attention, and there is a bit of truth to it, but don't take it too literally.

The approach espoused by the "Testing First" crowd is to start, like all good software development efforts, with design. But once you have pieces designed, move directly into testing. Now you don't have any code that can be tested yet, but you can start writing your tests. Thenalthough the tests will fail, as there is no code to run yetyou can begin keeping score on your progress by running these tests as code gets implemented.

Note

Some people like to tout the use of JUnit as an automated tool to track progress, but that's a little hard to do when you can't compile your tests because the classes they need don't yet exist. However, if you document your design of a class by (among other things) creating an empty version of the source, with Javadoc comments for the class and whatever methods you have come up with so far, well, then you've got something that will compile, and thus can be used for tracking progress. It also makes great, tangible documentation. Our point here, though, is that you are doing some coding before you begin testing. It's really more of a back-and-forth between coding and testing.


Let's apply that approach to our previous design discussion. We've described an Account class in our design discussion. It needs a name, an owner, and an amount of money when created. It should have a method to create subaccounts, ones that are connected to this account and get allocated some or all of the main account's money.

Example 13.1 is the basic structure of our Account class.

That's enough to begin writing a test. We have described the constructor, with the three parameters that it will need. We've also described a method on the Account object, one that will create subaccounts. That gives us enough information to write a test that will create an account and then create subaccounts of that account. We can test to see if the accounts are created properly (i.e., are not null) and if the subaccounts use up all the money of the parent account.

When you "test then code," you begin to use the objects that you have designed without getting bogged down in their implementation. You are, in effect, describing their external interfaces without implementing them. You are also beginning to use the classes as a user might, though a tester's use is a bit different than the way an application might use them. However, as a user of these classes you are beginning to test the design, by testing the results of the use casesare these classes really usable?

You may discover that you need some additional functionality. In our example, we can see from the description of our test that we will need a getter method on the account to return the amount of money that remains unallocated to subaccounts. Then we can test to see if it gets used up properly.

There are many more test cases that we could develop for the Account class, but let's use just these for now, so that the size of our test case is manageable.

Our next step is to get JUnit installed before we get too deep into developing our test cases. That will give us something to run these tests.



    Java Application Development with Linux
    Java Application Development on Linux
    ISBN: 013143697X
    EAN: 2147483647
    Year: 2004
    Pages: 292

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net