Originally posted by liqun chang:
Another question is test-first design term,Whehter test-before code,could you give me some general suggestion?
Hi,
The following book will answer your above question and your questions dealing with
concurrency testing:
Author: Johannes Link with contributions by Peter Frohlich
Title: Unit Testing in
Java: How Tests Drive the Code
I am new to
JUnit. I decided that I would use this Sun exam as an opportunity to
use JUnit. Like you, prior to this point, I had played around with JUnit, but I had
not--presumably like you--applied it to a project I was actually working on.
Concerning concurrency: assuming my memory of my first read of the book is
correct: there is no JUnit test or add-on to prove your code is designed and implemented
in a thread-safe manner. For a good, beginning tutorial on threads see the
free on-line book: Thinking in Java.
Having said the above, however, it does no mean that some concurrency testing can't
be done. I'll let others answer this part of the question because I am currently working
on Data using JUnit, and have not yet gotten to lock, unlock, isLocked, and the
concurrency issues (though I've studied concurrency issues and know how the design
will unfold: i.e., which classes will and will not be made for concurrency).
Concerning how JUnit drives design. In a nutshell, and based upon the book,
Unit Testing in Java, and assuming I'm remembering correctly given that I've
only read the book once, you have this: in general: as things becomes more
difficult to test, you refactor, and in this way, very generally speaking, you
decouple the code, and in this way, some aspects of the design are driven
by the testing.
Also in general, I'm starting off by testing against the interface: DBMain
(or, to be more accurate as described in this post:
Topic: NX: Modifying DBMain (but slightly)
https://coderanch.com/t/185283/java-developer-SCJD/certification/NX-Modifying-DBMain-but-slightly I'm testing against the SuperDBMain interface against three different
possible instantiations of "data".
That is, black-box testing. Simply jump in, and as you start testing,
although the interface is already given, you will find ways to enhance
the design. For instance, in trying to test the data.delete() method,
I wanted to undelete the file after deleting it; so, this led to a new design
idea: DBMainExtras extends DBMain, and Data implements DBMainExtras.
In this way, I can call new, more powerful methods instead of sticking with
the relatively low-level ones offered by DBMain. And, this was brought
about because I followed the general beginners rule: use JUnit to test
the interface.
All in all, as you may already know, I think that you are definitely on the
right track in using JUnit. I already feel very comfortable having a beginning
test-bed that I can rely on if, and when, I do further refactoring. By building
the tests as I refine the already written software (that is, I designed and
wrote the basics prior to using JUnit, but that was just how things happened
since I'm new to JUnit), I no longer have to worry or feel fear about making
any future software changes and enhancements, because the tests run
very quickly and accurately.
Also, as an aside, I'm currently using JUnit to test only Data. In my design,
Data is exposed to the client. And, Data has additional functionality (such
as possible primary keys) that the client will never use; so, it makes even
more sense to use JUnit, otherwise there is no software to test all the
functionality of Data.
Because DBMain is poorly designed, this is another reason to use JUnit,
so you "don't get lost" in the complexity of Sun's apriori design.
Finally, JUnit forces you to think about scenarios that you may have missed
during your detailed design steps.
Good luck with JUnit, and I hope others can fill in some of the blanks I may
have left out.
Thanks,
Javini Javono
[ March 06, 2004: Message edited by: Javini Javono ]