• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Confused about junit tests

 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I'm trying to learn unit testing (In Eclipse), but I'm getting a little confused by the tutorials I'm reading.

This is what I know so far:
Suppose I have a project Proj, with package pack, containing class SomeClass.



And now I have created a class SomeClassTest (extends TestCase) in same package as shown:


When I run this it works fine, and there are no errors.
But am I going about it right?
Should I put the assertEquals calls inside any random method, or is there a special method for them?

And how does ordering work with methods, I don't think they necessarily run in order, but I'm not sure.

Any general guidelines and advice is much appreciated, Thanks
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34863
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Colin,
There's not a right and wrong - just some things are more common than others.

My thoughts:
1) You are correct that tests are not guaranteed to run in a particular order.
2) Usually the test case name is descriptive. So I would favor test_initializedValues() rather than test1().
3) Typically classes have private fields and you test through the methods.
4) It's good to test different concepts in different test methods. For example, the assertion(s) related to x would go in a different method than those relating to v.
 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks,

In the TestCase class, there is a runTest() method.
So I tried to override this, and put my assertions in there,
and it seemed to work the same as when I had test1(),
I don't see what the point of it is?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You typically have more than one test method in a test case class. The framework automatically generates an instance for each method, and the runTest method will determine which test method to actually execute. (Beware: I'm not sure whether that's still true in JUnit 4.)

Overwriting the runTest method will work, but if you want to have more than one test in a testcase class, you will have to reimplement that behaviour. That's something you normally don't want to do.

Your best option when you are new to JUnit is probably to ignore it.
 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, are there any basic examples of simple classes, that are tested, along with the class that extends TestCase.

All the stuff I've looked at seems complicated, and doesn't really give examples.

Any ideas, thanks.
 
M Easter
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following article is about Emma, which is typically used _after_ JUnit.

However, in order to illustrate Emma, it has examples of a simple Java class with JUnit test classes.

http://ociweb.com/jnb/jnbFeb2007.html
 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, I think I found what I was looking for..
There is a class Card (implements Comparable)
and a test class PokerHandTestCase (extends TestCase)

I think thats what you meant I should look at.
Thanks
 
M Easter
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes... though PokerHand is the primary class for the example. Card is just a utility class

Mike

ps. I am the author of the article. If you find it interesting or useful, i would appreciate it if you "digg" it on Digg. (if not, then no worries)
 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi again, I found it very interesting, but also confusing...

In the PokerHandTestCase class, the first method is..



We can see this isn't called (except from inside the other methods),
but when we look at the next method...


Then this is automatically called, because I have a '1' printed out.
Now, when I change the argument list so it has at least one argument, eg int x, then this method is no longer called.

This is what I have established:
If method is private and has no arguments, it creates an error.
If the method is private and has arguments, it will only be called when you explicitly call it, as with the first method.
If the method is public and has no arguments, it is called automatically.
If the method is public and has arguments, it will only be called when you explicitly call it.

Thats probably wrong, but please can someone clarify whats going on in this unit test.
Also, when the methods are automatically called, are they called in the order of which they are written (this seems to be the case from my output).

Thanks very much for any help!.
 
colin shuker
Ranch Hand
Posts: 750
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, seems I have been a bit dumb, but I see the methods beginning with 'test' are automatically called, and ones that aren't aren't.

Please add any necessary information that you think I will benefit from regarding these methods.

Thanks
 
Ulf Dittmer
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are a couple of good introductury articles on the JUnit web site, A Cook's Tour and Test Infected. Those contain a good overview of how to name and organize methods, what to override and what not, and how to generally get started with JUnit.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by colin shuker:
Ok, seems I have been a bit dumb, but I see the methods beginning with 'test' are automatically called, and ones that aren't aren't.


In short, the JUnit framework will execute all public, void, no-argument methods as tests. That is, methods that look like this:



If the method throws any kind of an exception, that test is considered to fail. That's how the assertXxx() methods work--they throw an unchecked exception if the assertion doesn't pass.

Before JUnit invokes the test* method, it first invokes the test class instance's setUp() method. Overriding this method lets you do common "pre" stuff such as create objects for the test methods to operate with.

After JUnit has invoked the test* method, it invokes the tearDown() method (regardless of whether the test method passed or failed). Overriding this method lets you perform any common cleanup after your test methods, such as releasing any shared resources your test may have used.

That's the gist of it. However, I strongly suggest reading the links posted above by Ulf.
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think to appreciate how much (or how little) JUnit does for you, it might be worth reading my lecture notes on automated testing, where my students learned how to write their own, admittedly trivial, test framework. They're fairly short, and there's no ads, this isn't a commercial plug.

http://cime.net/~ricky/netsim/oldham/automated_testing.html

Some of them did go off and write something more like JUnit after that. You always get people who overdesign..
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic