File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes unit testing lock and unlock Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "unit testing lock and unlock" Watch "unit testing lock and unlock" New topic

unit testing lock and unlock

Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
I'd like to share something that has helped me discover and eliminate some bugs from my thread-handling code.
This applies to my solution of having implemented locking in Data itself, and to my use of JUnit, but perhaps the same sort of thing could find application in your ongoing development.
JUnit test cases have been great with regard to locating points at which my implementation deviated from the published interface. Testing the threaded code was something I initially thought could be done only in a functional test.
I'm no Doug Lea, so if you find this solution to be flawed or kludgy, cut a little slack and let me know where it's wrong.
It came down to my creating two extensions of java.util.TimerTask. These private classes take an instance of Data and a record number at construction.
The current time in milliseconds is recorded. A timer task is scheduled with java.util.Timer with a known delay. Then the blocking call is made. When the blocking call returns, the time it took to run is calculated and compared to the known delay. The run time must be greater than/equal to the delay for the test to succeed.
For example, one cannot lock record number 1 if all records are locked. A timer task is set to unlock all records after a delay. The test case goes to lock record 1. The call blocks as expected. The timer task removes the lock on all records after the delay is expired, and the call to lock record 1 proceeds. The time it took for the call to lock record 1 to return is then compared to the delay time.
This helped me to find some errors and also to question if my implementation was true to Sun's requirements.
Here's a clip from a unit test...

And here's one of the timer tasks
Ying Ren
Ranch Hand

Joined: May 24, 2002
Posts: 35
I used to create a timer. But now I agree with someone else, you needn't use the timer. Because the instruction said "no time out in lock." So, I delete them.
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
The timers are being used to test the threaded code. There are no timeouts in the implementation itself. A blocking condition is set first, then the timer task is scheduled to remove that blocking condition after a delay. The implementation is expected to block for the duration and then proceed once the timer task has done its thing.
I agree. Here's the link:
subject: unit testing lock and unlock
It's not a secret anymore!