Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

what is real meaning of unit testing?

 
Faisal Khan
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As can be seen from my previous post, I am new to unit testing. I have in the past thought testing to mean the ability to prove something works, be it in the form of demonstarting the application functioning, which is clearly incorrect or at least impartial. I now understand that unit testing is not about seeing program working, watching the debug statements etc. Rather, the process of unit testing entails producing boolean results to say whether the code fulfills a given test - bunch of assertXXXs. [ please correct if I am wrong on any of the above ]
Couple of questions:
My class CarBean has to do some price retrievals, apply discounts, get various fees to be applied to the price, residual value of the car, pull out lists of manufacturers, models and derviates of each model [using the CarDAO class]
I *think*, I should be able to test the prices by running our CAP system and then entering some valid and invalid prices into the CarTest class, is this right? - how do I test the retrieval of lists from the database.
Please kindly offer advise and direction on this.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Database related functionality can generally be tested in two ways:
1) Mocking the database access class (replacing the actual class with a dumb implementation always returning hardcoded values, for example)
2) With utilities such as dbUnit which set up the database tables into a known state, then run the test, and afterwards return the database again into a known state.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Writing testable code is tough, but writing tests first can give you very cool decoupled designs. You're thinking testing Car will be tricky because of dependencies on the database access. How about if you removed all those dependencies? What if your test looked like:

You could write car and test all of its functionality with no database at all.
Robert Martin's book Agile Software Development has a cool case study where he builds a whole payroll system with no user interface or database. All the guts are coded and tested and could be plugged into a variety of UI or database solutions. Now I was pretty stunned when I got to the end of the case study and realized what he had done. If you're having a hard time believing this can work, I don't blame you one bit. But do try it! Maybe on the next project - it may be hard to retrofit now.
 
Faisal Khan
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys for your help, once again.
What I have done now is to use inner classes and override the database functionaloty from the Car object and Mocked the corporate object too. I am now in a position to "unit" test my CarBean and have begun to realise the power of doing things in this manner.
I believe, I am still struggling little to appreciate what "sorts" of tests to run, my public methods for the CarBean are:
double getListPrice()
double getDiscounteddPrice()
double getMaintenanceCost()
double getResidualValue
etc, I have a few setters to set the capID, term, mileage etc for the given car.
One test I am doing is:
public void testInvalidCapID() throws CarBeanException {
car.setCapID(-200);
fail("should throw a CarBeanException");
}
I am not sure waht kind of tests to run on the other methods, again any help will certainly be most appreciated - I have learnt a lot about testing in last few days from you guys and further help will be highly apprreciated.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basically, you shouldn't test methods, but behaviour. That is, you should ask yourself "what do I want to do with objects of this class" and then test that your *are*.
A test could easily exercise the interplay of several methods (or even objects), and you will probably have more than one test per method.
Hope this helps...
 
Faisal Khan
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excellent Ilja, that *really* does clear things up for me as I was looking at the whole matter from a wrong perspectvive but you have cleared it up for me.
I'm sure I'll come back with more issues after having the next crack at it on Monday.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic