File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Testing and the fly likes state of art Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "state of art" Watch "state of art" New topic
Author

state of art

miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
As i stated elsewhere i'm no pro.

i like learning and working with java and i like to include my latest toys in every new program i craft - it also serves me as a reference to what i've learned so far.

Actually i'm building a stand alone desktop app and i'm using hibernate + MySql (for tests i'm using Hsql)

At this point i've domain objects that i need to persist to database; so i created Dao objects;

In separated tests i'm testing method behaviour: if a can add an obj to other's Set, object's interaction and so on; so far so good.

But when it comes to testing db persistence i'm at the crossroads:
before i saw the light i'd create a UI, introduce some data, check database or even retrieve those data from the UI to check if everything was ok.

Now that i discovered testing (the more i know the less i know ) i want to use it properly.

This means testing my persistence methods; i created an interface with trivial methods:
SaveOrUpdate()
delete()
retrieveById()
sortAll()
etc

I've several Daos implementing this interface.

My first Q is the following:
should i test (with database conn and all) every Dao?

Another Q:
where can i integrate mock testing? (in this very forum someone told me mocking hibernate session wouldnt be that easy)
On the other hand, testing db persistence makes tests longer

hope i made myself clear enough

thanks in advance


java amateur
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by miguel lisboa:
should i test (with database conn and all) every Dao?

Yes, you should have some sort of automated tests that exercise each of your DAO's against the real database. These would probably be part of a test suite that you run not every 5 minutes but maybe every hour or so (better yet, every 10 minutes on a build server;).

This kind of tests will let you know within minutes when the database code, the mapping files, and/or the database schema become out of synch.

Originally posted by miguel lisboa:
where can i integrate mock testing? (in this very forum someone told me mocking hibernate session wouldnt be that easy)
On the other hand, testing db persistence makes tests longer

Hibernate's Session is indeed not the best interface to mock. I'd recommend mocking your DAO's instead.

For example, if you're using a ServiceFactory to locate the DAO implementation:

Obviously this becomes a lot easier if you have some sort of dependency injection framework in place:


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281

[ March 18, 2005: Message edited by: miguel lisboa ]
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
Lasse Koskela:
in first place thanks a lot for this complete answer

this said, i'm quite sorry (and puzzled too), because i guess you think i'm much advanced than actually i do...

Yes, you should have some sort of automated tests that exercise each of your DAO's against the real database. These would probably be part of a test suite that you run not every 5 minutes but maybe every hour or so (better yet, every 10 minutes on a build server .

i know zero, nothing at all about servers
For example, if you're using a ServiceFactory to locate the DAO implementation

i googled ServiceFactory but what i found about was allways related with internet
Obviously this becomes a lot easier if you have some sort of dependency injection framework in place



Well, please be patient and let me try a way around all this:
i'me my domain objects
i've my persistence interface
i've my Daos

now my idea:
every domain class would have those methods too, but would delegate the persistence itself to respective Dao
example: (class Convencao is one of domain objs)



now, if i were inside some business obj and wanted to test saving a certain Convencao obj, how would i use mocks?
context:

then, is now that i could mock my ConvencaoDao in order to test the previous method call inside MyFa´┐Żade?

thanks in advance again
 
wood burning stoves
 
subject: state of art