Help coderanch get a
new server
by contributing to the fundraiser
  • 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
  • Paul Clapham
  • Devaka Cooray
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:
  • Lou Hamers
  • Piet Souris
  • Frits Walraven

can we write junit testcase for any java class?

 
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
is it possible to write junit class for any type of java file?
 
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Basically yes... Of course some things are harder to test than others without additional test libraries etc.

What is your problem?

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



is it possible to write unit test junit for these kind of classes?

i know to write simple junits for small classes.

 
J radolf
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
how do i write a junit for these kind of classes?
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

Unfortunately this class you're trying to get under test has even multiple problems which makes it very tricky to test. I doubt that it's even possible to reasonably test it if you don't have the chance to refactor it.

The main problems I see from a quick look are:

- It's an EJB class which may need a JUnit add-on like ejb3unit depending on what you want to test.
- It's designed to be used with multi-threading which is a challenge on its own if you want to create useful concurrency tests.
- You have dependencies for file/database I/O hard-coded into the code.
- The overall design is not really OO and not very well-suited for testing.

That said I'd recommend you to restructure and refactor this code and try to put in test cases in parallel as good as possible. Try to break dependencies so that you can substitute database and file access with fake or mock objects etc. Refactor this big methods into smaller units/methods so that you are able to test one piece of specific functionality within each test method. Unfortunately it's hard to give you more concrete advices because there may be many different way to get this piece of code into a structure which is easier to test.

If it's likely that you will have to deal more often with code of that kind in the near future I would recommend reading "Working Effectively with Legacy Code" ;-) Michael Feathers shows lots of tricks how to get such code into better shape and make it testable.

Good Luck

Marco
 
author & internet detective
Posts: 41964
911
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

J radolf wrote:how do i write a junit for these kind of classes?


You start small. What methods can you test? The loadProperties method jumps out at me as being easily testable.

The database code could be refactored into separate methods (or better yet classes) and be unit (using mocks) or integration (using a database) tested there.

You really should refactor regardless of testing. That run method does too much. Suppose you had never seen this class before. How long would it take to figure out what the run method does? What if you compare it to the below method? (I could make it more readable if I was the author and knew exactly the purpose - this attempt was based on the original implementation.)

The refactoring helps with both readability and testing. Readability should be obvious - you don't have to deal with the low level details when reading the run methods. On the testing side, each of the methods can be tested independently. Making it much easier to test error handling. How else would you easily simulate a database failure on a call near the middle?

 
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
there is a fantastic book on this problem (evil-cycle: no tests->no safe refactoring, no testable code -> difficult test setup):
work effectively on legacy code

it discusses how you face bad testable code, and how you make it testable with more conservative refactorings.
 
J radolf
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
so in case if we want to unit test loadProperties() method should i put a dummy property file to read it?

is it a correct coding style in a real world scenario?
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
or even better. add a Reader abstraction on it to load properties.

There is a Properties.load

Then you can pass different reader variants (like FileReader for production and StringReader for tests).

 
J radolf
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
suppose a class has four methods in it. so we need to write 4 different junit classes to test those four methods or do we need to test those four methods in a single junit class?
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are different testing strategies, personal taste and different opinions on how you should group test methods into test clases. But basically I'd start with one test class per tested class. This make usually most sense and you have all tests for each method of the same production class in one test class.

One more point: It may be necessary to have more than one test method for each tested method ;-)

Marco
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) You don't test methods, you test behavior of a class. A test method should test one micro-scenario. As such, you can have test methods that test the interplay of several methods, and methods tested by several test methods.

2) A common good practice is to have one test class per fixture. That is, group test methods with common set up code into a class, and move that set up code into one or more @Before methods.
 
J radolf
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the reply.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic