• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

JUnit tests for Getters and Setters

 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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:


 
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author & internet detective
Posts: 42074
933
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
     
    author and iconoclast
    Posts: 24207
    46
    Mac OS X Eclipse IDE Chrome
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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?
     
    Rancher
    Posts: 1337
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
    Posts: 42074
    933
    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
    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.
     
    Do not set lab on fire. Or this tiny ad:
    Smokeless wood heat with a rocket mass heater
    https://woodheat.net
    reply
      Bookmark Topic Watch Topic
    • New Topic