• 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
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

JUnit, doing it the right way, setUp & tearDown ...???

 
Ranch Hand
Posts: 755
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi there,

say I have a new class (domain Empl) and I would like to test:

class Empl
{
private String name;
private long id;
private int role;

private getName()...
}


now....I would like to test the following:

insert
update
delete
select
selectAll

since I don't wish to poputlate the db with bogus info, what is the right why to do that using setUp and tearDown?

I thought on:

Empl empl=null
setUp()
{
empl = new Empl();
}

public testInsert()
{
empl.setId...
empl.setName..
}

public testDelete()
{
//now to do delete, I'll need to add a new empl BUT in the
//tearDown I'v deleting it?!!
}

tearDown()
{
//get last insert?
//delete newly insert empl empl?
}

I'm quite confused here as per the RIGHT way to test.

thanks in advance
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My preferred why to do this is to use an in memory database (such as HSQLDB) for the tests. The database gets created at the start of the testrun and destroyed at the end. That way I don't have to care about bogus content at all. It's also relatively fast.
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure that was what the OP was asking.

To me it seemed as if the point was what to do with tests which require different setUp/tearDown requirements.

The "purist" approach is to say that a "test case" is defined by the setUp and tearDown menthods - so if two tests need different set ups then they should be in different test classes. In the case above this might look
something like:

test class 1:







That was a bit wordy, but I hope it shows my point. Tests which assume a freshly created Empl go in one class. Tests which assume a container populated with some example Empl instances go in one class. Tests which assume no set up conditions because they are testing creation go in yet another class.

The important thing is to avoid assuming that all tests for one domain class should always go in one test case class.

Does that make sense?
 
Peter Primrose
Ranch Hand
Posts: 755
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sheriff Frank,
Thanks for your 'wordy' reply. I tried to paraphrase your test and wonder if I'm on the right track.

Thanks.

 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
test class 1:


Hi,

I do not want to be picky Frank - just to point out something which relates to the original question. In the code above before each test is run the setUp() method adds records for 1 and 2. Therefore when testAddNew() is run, 1 and 2 exist, the test adds 3 and does its stuff. tearDown() then deletes everything (1 and 2 added by setUp() and 3 added by testAddNew()).

Before testAddDuplicate() runs, setUp() is run again and adds 1 and 2. Then testAddDuplicate() adds 3 once. IMHO in order to test whether duplicates are added you should have an extra line for add(3);. Then if duplicates are not allowed the assertEquals(3, whatever.count()) will validate that only three records were added when you attempted to add 4.

Hope this helps the original poster,

Fintan
 
Life just hasn't been the same since the volcano erupted and now the air is full of tiny ads.
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic