Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JUnit tests for Getters and Setters

 
You Gin
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moved to the testing category.

You should not compare Strings with == but with the equals method or use the assertEquals method provided by JUnit.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34178
340
Eclipse IDE Java VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?


  •  
    You Gin
    Ranch Hand
    Posts: 52
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 52
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Pie
    Posts: 24208
    35
    Chrome Eclipse IDE Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    "==" 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:

     
    You Gin
    Ranch Hand
    Posts: 52
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks you for your explanation Ernest, but the question remains open. Why can' I use


    if it works just fine?
     
    Lester Burnham
    Rancher
    Posts: 1337
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 52
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 1337
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 34178
    340
    Eclipse IDE Java VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic