File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Running junit

 
satya bhat
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have a properties file which has initialised many variables as constants there.It has no method.Now since this file is huge i want to split this file according to the functionalities in which they are used.am trying to create junit test for this file..But since there is no method in my source file..I have wrote test cases in main method..While running RAD is throwing error as no tests found

public class PropsTest extends TestCase {
private final Props uut = new Props();
private static String fldName = null;
private static String fldVal = null;
public static void main(String args[]) {

// get all fields from props
Field fieldlist[] = Props.class.getDeclaredFields();

}
}


Thanks,
Satya
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Satya, your JUnit tests need not map one-to-one with methods on the class you're testing. In fact, I consider such a mapping to be an anti-pattern. What you should test is behavior of objects, not methods.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33674
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Satya,
Welcome to JavaRanch!

RAD is complaining that you have no methods of the form:
public void test_XXX() {}

From your code snippet, it seems to be correct. You do have a main method which is a testing anti-pattern. Maybe you mean for that method to be a test?
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by satya bhat:
[QBWhile running RAD is throwing error as no tests found

[/QB]


What is RAD?
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
Satya, your JUnit tests need not map one-to-one with methods on the class you're testing. In fact, I consider such a mapping to be an anti-pattern. What you should test is behavior of objects, not methods.


Is this opinion (don't have a test for each method) held by most people advocating JUnit style testing?
[ August 13, 2008: Message edited by: Red Smith ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Red Smith:

Is this opinion (don't have a test for each method) held by most people advocating JUnit style testing?


Yes.

You should test the behavior of a class, not methods. That could mean having tests that test several methods in interplay with each other, and it could mean that you have more than one test that tests a method - often both at the same time.

This comes quite naturally when you are doing test driven design.
 
Jan Cumps
Bartender
Posts: 2576
11
C++ Linux Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This comes quite naturally when you are doing test driven design.
I agree. But creating a test for each method is what most IDE JUnit wizards/plugins do. In some way, these wizards only assist you if you write code first, and then the tests (does the term Code Driven Testing already exist?).
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:


Yes.

You should test the behavior of a class, not methods. That could mean having tests that test several methods in interplay with each other, and it could mean that you have more than one test that tests a method - often both at the same time.

This comes quite naturally when you are doing test driven design.


It seems like you can and should do both - if you have a test for each method that doesn't preclude other tests that test multiple method execution sequences. Just like Unit Testing doesn't preclude System Testing. And if you have one test for each method you can be more certain that each method has been tested fully. If you are working out scenarios of using multiple method calls, your scenarios might not involve all possibilities of each method.
[ August 14, 2008: Message edited by: Red Smith ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jan Cumps:
I agree. But creating a test for each method is what most IDE JUnit wizards/plugins do. In some way, these wizards only assist you if you write code first, and then the tests


Yes. They very nicely support a very flawed way of working. Seriously.


(does the term Code Driven Testing already exist?).


I hope it doesn't...
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[post deleted - clicked on reply when I meant to edit an existing post]
[ August 14, 2008: Message edited by: Red Smith ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Red Smith:
It seems like you can and should do both - if you have a test for each method that doesn't preclude other tests that test multiple method execution sequences. Just like Unit Testing doesn't preclude System Testing.


True.

And if you have one test for each method you can be more certain that each method has been tested fully.


I don't see how it would do that.

Anyway, the question is one of focus. What counts is that all the functionality of a class that you care about is tested. It seems obvious to me that therefore you should focus on testing functionality, not methods.

Surely, if you have a method that isn't tested by a direct test, it makes sense to ask yourself whether you are missing one. Unless you are doing strict TDD, in which case the question is moot.


If you are working out scenarios of using multiple method calls, your scenarios might not involve all possibilities of each method.


Neither if you have a test method for every method, as far as I can tell. Unless you are doing TDD, again.
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Anyway, the question is one of focus. What counts is that all the functionality of a class that you care about is tested. It seems obvious to me that therefore you should focus on testing functionality, not methods."

You can't test a method without giving the object a variety of states and then seeing how it responds when that method is called. It would seem that in most cases a single method call is a test of an object's functionality. Or put another way, part of an object's functionality is usually demonstrated by a single method call.

If a hypothetical class has turn right forward,turn left forward, go forward straight ahead methods, and similar methods going backwards. I think you are saying don't test each method individually, just come up with a test that has a route that tests them all. But if that scenario test fails, I would also want tests for each of the individual methods so I can more easily pinpoint why my scenario is failing. In addition, when I code each method, I want to test it as I code it and verify that it works before I do any similar or complementary methods. In addition, I don't see how I can determine why my scenario test failed if I don't have a test for each method that is involved in the scenario. Without an automated test of the method I am left in the debugger doing manual calculations for each step of the scenario to see if it worked correctly.
[ August 14, 2008: Message edited by: Red Smith ]
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Red, in your turn-left, turn-right, etc. example each of those actions are functionality, not just methods, and it makes sense (to me at least) to write tests for each method individually.

Now, let's say you implement such an object in this (horrible) way:

In this case, you wouldn't want to write direct tests just for "setDirection()" and just for "getDirection()" because that's not the behavior of MovingObject. That's the implementation details. Instead, you'd simply write tests for the different turnXXX() methods and a couple for stepping forward.

(That must be the stupidest example ever - I had a hard time coming up with anything sensible.)

In any case, when we say you should test the behavior or scenarios and not the methods, it's mostly about the mindset - how you think about what you're doing - and not that much about how you do it. Having said that, looking at your test names often reveals a lot about how you think about your tests:
  • Programmers who are interested in behavior frequently have more verbose test names that almost read like full sentences, including verbs and all that.
  • Programmers who are thinking about covering all of the implementation frequently name their tests with patterns such as "public void test[NameOfImplementationMethod]()".

  • [ August 14, 2008: Message edited by: Lasse Koskela ]
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Red Smith:
    It would seem that in most cases a single method call is a test of an object's functionality. Or put another way, part of an object's functionality is usually demonstrated by a single method call.


    That might or might not be true. My point is that I wouldn't focus on it.

    If a hypothetical class has turn right forward,turn left forward, go forward straight ahead methods, and similar methods going backwards. I think you are saying don't test each method individually, just come up with a test that has a route that tests them all.


    No, that's not what I'm saying.

    What I'm saying is that I want to have a test for each functionality. Turning right seems to be an atomic behavior of the class, so I wanted to have an explicit test for it. If that involves one method call, fine. If it involves more than one, just as fine.

    To take a different example, a stack typically is defined by the *interplay* of the push and pop methods. To me, it makes much more sense to write (several) tests for that interplay than to write tests that test the methods separately.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic