• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JUnit test void methods?

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

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.

Im a bit stuck...
 
Rancher
Posts: 377
Android Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey,

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
 
N.S. James
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...

 
Sean Clark
Rancher
Posts: 377
Android Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

Thanks!
 
Sean Clark
Rancher
Posts: 377
Android Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have to say I have never really found any need for abstract/interfaces for tests, since usually the tests are class specific.

But if anyone has other opinions I'd be interested in this too.

Sean
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic