I have a class called CommandFilter, that takes an input command (string), and via a series of case statements (on chars of the string) determines the actual command to parse. Ie server_param or player_param.
Once it has matched a case, it calls a method in another class...never returning anything, or changing any variable to test.
Once it has matched a case, it calls a method in another class...never returning anything, or changing any variable to test.
When you say you call a method in another class, how are these classes created?
Do you initialise the class using "new" and then call the method?
Or
Are the classes that you call the methods on set using setters?
If the latter and if you are using interfaces then you can use something like EasyMock to check that the correct class/method is being used for the String input that you have entered.
Sean
I love this place!
N.S. James
Greenhorn
Joined: Jan 31, 2010
Posts: 4
posted
0
Ah...well the class that the method is called from is actually also passed into the method im trying to test.
So the method signature looks something like this...
ok, well that's good then, that makes it easier to test... but are you passing it in as an object rather than some kind of common interface?
I'm not saying you should change your design for testing purposes, but I think it is just a general good principle to follow to use intefaces (where sensible).
If you are using an interface then perfect, you might want to take a look at EasyMock and check out some examples.
N.S. James
Greenhorn
Joined: Jan 31, 2010
Posts: 4
posted
0
Yeah I am using an interface = D I shall have a look at that link then!
Another quick question...
Should I JUnit test interfaces? If so how? And similarly, how do I JUnit abstract classes?
How could you test an interface?! Interfaces have no functionality on their own.
To your original question: if the method you're testing has no return, and no side-effects, then testing it is meaningless. Likely so is the method.
It must have *some* testable side-effect, otherwise it wouldn't need to exist. Identify the side-effect. Test it. Things are easier to test if the side-effect is made more explicit (like a return value) rather than having a deeply embedded side-effect (modifying an instance value, writing to stdout, etc.), but sometimes it's unavoidable. The trick is to make it as avoidable as possible, without convolution.
This is one reason why functional programming, or programming as functionally as possible, can be a big win.
0
