• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

44/80 Revisited; and Advice on Testing and JUnit

 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Now that I have my JUnit tests up and almost running (I made
a change, and so some of them are broken), I now feel more
comfortable speculating as to why 44/80 scores in locking
have haunted quite a few: in my opinion, it is not the ten
or twenty or more lines of the LockManager, but it is the entire server
that could, in pockets of missed or misguided logic or miscoded
code that could potentially go wrong that results in the 44/80
scores.
For instance, as I devise tests for my server using JUnit, I continually
run into instance after instance of some technicality in the
implementation which fails (of course, in a certain sense, that is
exactly what JUnit is for; if your tests aren't finding bugs, then
your formulated tests may not be probing enough). Without JUnit,
I would have submitted, and clearly would have received 44/80 in
locking (or worse), even though the core locking facility works like
a charm (that is, that core which everyone always posts).
In short, the server software in its entirity, which is always dealing
with locking on many fronts, is a mine field; and, I am no longer
so surprised that people walk away with a 44/80 score.
I have seen a post recently were someone is asking advice. Here
is my simple advice:
1. Use Junit
2. Think about different scenarios and translate them into JUnit
tests.
In short, if it involves data.lock(), data.doThis(), and data.unLock(),
use JUnit. (I'm not saying use JUnit on everything, but instead focus
using JUnit on Data).
If you do the above, you will, with the great assistance and advice
of the people in this group, maximize your score.
Thanks,
Javini Javono
[ March 17, 2004: Message edited by: Javini Javono ]
 
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Javini,
Thank you very much for such a helpful post. May I request you to give short description for the kinds of test cases you ran with JUnit against critical sections in Data.java and how you caught the problem (in locking code)?
Thank you very much in advance!
Seid
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I've caught many problems. Some due to recent changes, but others that were
lurking in the background even after running George's great, super software
exerciser with success a while back.
There are four broad testing approaches I've applied:
1. Manual testing.
2. George's super, software exerciser (which I have expanded into a major
system testing application which runs numerous tests over and over and
then automatically checks the final result in the file, and which also attempts
to do illegal operations over and over again).
3. A hacked version of JUnit I mungered together so that JUnit would allow
concurrent system testing, but at this time, most of my major, heavy duty
concurrent testing is done via item 2 above.
4. JUnit testing at the data.unlock(), data.doThis(), and data.unlock()
level; this has been the richest sources of surprising, subtle bugs, which,
thank goodness, are gradually evaporatin as I think about new tests and
place them into JUnit code. There is lots of on-line advice about JUnit
at www.junit.org, and in addition, this book: Unit Testing In Java by
Johannes Link.
In short, the Data class portion of the exam is a landmine field. You can have
extremely harmful errors that you have never exercised, only to have the
erros surface and blow-up on the exmainer's computer. I would now speculate
that Sun's examiner's definitely test Data using JUnit or some other unit-testing
platform; they would, I suspect, not be able to spot so many potential bugs by
their eyes alone.
Note by the way, that even though JUnit tests I do are predominately non-concurrent
runs, there is still a landmine of bugs.
Thanks,
Javini Javono
[ March 17, 2004: Message edited by: Javini Javono ]
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do you use to compare your asserts with? For a method like update, do you write the record, then use JUnit to compare the record in the database with what you sent to the method, and how do you compare them?
Thanks
 
Good night. Drive safely. Here's a tiny ad for the road:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic