aspose file tools*
The moose likes Testing and the fly likes Running junit Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Running junit" Watch "Running junit" New topic
Author

Running junit

satya bhat
Greenhorn

Joined: Jul 10, 2008
Posts: 2
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

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30309
    
150

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?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Red Smith
Ranch Hand

Joined: Aug 05, 2007
Posts: 136
    
    1
Originally posted by satya bhat:
[QBWhile running RAD is throwing error as no tests found

[/QB]


What is RAD?
Red Smith
Ranch Hand

Joined: Aug 05, 2007
Posts: 136
    
    1
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

Joined: Jul 11, 2001
Posts: 14112
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.


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
Jan Cumps
Bartender

Joined: Dec 20, 2006
Posts: 2495
    
    8

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?).


OCUP UML fundamental and ITIL foundation
youtube channel
Red Smith
Ranch Hand

Joined: Aug 05, 2007
Posts: 136
    
    1
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Aug 05, 2007
Posts: 136
    
    1
[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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Aug 05, 2007
Posts: 136
    
    1
"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

Joined: Jan 23, 2002
Posts: 11962
    
    5
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

    Joined: Jul 11, 2001
    Posts: 14112
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Running junit