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.
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?
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.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Apr 11, 2005
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.
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
Joined: Feb 11, 2007
Yes... though PokerHand is the primary class for the example. Card is just a utility class
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)
Joined: Apr 11, 2005
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!.
Joined: Apr 11, 2005
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.
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.
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.
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.