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

JUnit tests for Getters and Setters

You Gin
Ranch Hand

Joined: Jul 23, 2010
Posts: 52
Hi guys.

As it was highly recommended in one of the books I'm reading I've started to write tests for each of the class I'm creating. I'm not really sure what is a good practice to cover setters and getters or not. If yes I'm not sure how because to verify the setter method you need to call the getter for this variable and vice versa. So you will never know where the actual problem is.
Where I went is just similar tests for setters and getters. I don't really like it. Could you guys refer me to a right direction?
Thank you very much!

Here is my class and a corresponding test class.


Test:


Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

Moved to the testing category.

You should not compare Strings with == but with the equals method or use the assertEquals method provided by JUnit.


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30944
    
158

Normally I say not to test getters and setters because they get tested with other classes when they get used. You have logic in your setters though so it makes sense to test them. You asked how you know if the error is in the getter or setter. It turns out that it doesn't matter. If there is an error, you are going to need to look at it. And then you'll see what is wrong.

Test tips:
  • test the empty string case - you want to cover all the paths in your code by tests
  • assertTrue(card.getWeight() == 2); should be assertEquals("weight", 2, card.getWeight()); because it gives you a clearer error message when the test fails.
  • assertTrue(card.getForeignWord() == "test") should be assertEquals("foreign word", "test", card.getForeignWord());
  • you don't need to repeat the test in sepearate methods for the getter and setter. It is the same test
  • move instantiating Card to a @Before method to reduce duplicate code


  • And about the actual code:
  • if (foreignWord != "") is functionally incorrect - you should use equals() for comparisons
  • if the string isn't what you expect in a setter, you output a message. Do you want to throw an exception if the argument is invalid?



  • [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
    You Gin
    Ranch Hand

    Joined: Jul 23, 2010
    Posts: 52
    Hello Jeanne,

    Thank you very much for your useful comments, taking them all into account.

    Regarding exception for incorrect data in a setter, yeah, I thought about it also and added exception throwing over there, thanks a lot!
    You Gin
    Ranch Hand

    Joined: Jul 23, 2010
    Posts: 52
    Hello Jeanne,

    Can you tell me more about Strings comparing please?

    I just can't get a difference here. Why should I use equal if == works perfectly fine?


    Output:
    Not Equal
    Not Equal
    Not Equal
    Ernest Friedman-Hill
    author and iconoclast
    Marshal

    Joined: Jul 08, 2003
    Posts: 24187
        
      34

    "==" tests if two variables refer to the same physical object. equals() tests whether two objects are equivalent. For String, "equivalent" means they have the same characters in the same order. You can have two different String objects with the same characters in the same order, and they'll look identical when printed. equals() would return true, but "==" would return false. That's why you want to use equals() to compare Strings.

    Note, though, that the JVM keeps a pool of String literals. Every "test" that appears directly in your program refers to the same physical String object, so

    "test" == "test"

    is true. But, for example, if you read the String "test" from the console, and compare it to a literal "test" in your program, you'll see there's not the same object:



    [Jess in Action][AskingGoodQuestions]
    You Gin
    Ranch Hand

    Joined: Jul 23, 2010
    Posts: 52
    Thanks you for your explanation Ernest, but the question remains open. Why can' I use


    if it works just fine?
    Lester Burnham
    Rancher

    Joined: Oct 14, 2008
    Posts: 1337
    Because -for the reasons Ernest mentioned- it will not always work. And you do want your unit tests to work under all circumstances, don't you? :-)
    You Gin
    Ranch Hand

    Joined: Jul 23, 2010
    Posts: 52
    Ok, ok... please prove my guess. I have a feeling that on new object of String type is instantiated and because the "" is already on a string pool those two are actually the same object and thus is true? Because if I would use:


    I'll get "Not Equal"
    Lester Burnham
    Rancher

    Joined: Oct 14, 2008
    Posts: 1337
    Yes, it has to do with the string pool, and at what times new String objects are being created (or not being created).
    Jeanne Boyarsky
    author & internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30944
        
    158

    Overall, it is a good practice to not use == for String comparison because one day it will burn you and your co-workers will be mad.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: JUnit tests for Getters and Setters