• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

how to test the setter methods

 
Cali Kim
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've gotten the class done, and the driver is getting close. Any pointers in the right direction would help. I don't want you to do it for me, but perhaps a hint or two?

Here is the class with the setter methods(I needed to make it mutable):



and here is the test driver as it sits:

 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In your test, examine the attribute before calling the setter. Then call the setter with a new value. Examine the attribute again and compare the value to what you saw before.
 
Cali Kim
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis Deems wrote:In your test, examine the attribute before calling the setter. Then call the setter with a new value. Examine the attribute again and compare the value to what you saw before.


This is French to me. I understand creating a new value, but I'm having a problem deciding what values to use. The initial values (day, month, year) are all locked as private and will not transfer over into a test driver. Should I create new ones within the test driver? If so, how then will I be sure that it is calling the setter methods for testing?
 
Paul Clapham
Sheriff
Posts: 21322
32
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cali Kim wrote:I understand creating a new value, but I'm having a problem deciding what values to use. The initial values (day, month, year) are all locked as private and will not transfer over into a test driver. Should I create new ones within the test driver? If so, how then will I be sure that it is calling the setter methods for testing?


That's all Greek to me. Like Dennis said, if you want to test a setter method, then here's what you do:

(1) Get the value of the variable which the setter affects. Store it in a local variable. (If that counts as "creating a new one", then yes, create a new one.) If you're concerned that the variable in question is private, then use some public method of getting that value.

(2) Call the setter method to assign a different value than what you just got. (Why would you not be sure that the test driver would be calling the setter method?)

(3) Get the value of the variable again. Check that it is the value that the setter method assigned in step 2 and not the value originally acquired in step 1.
 
Cali Kim
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
Cali Kim wrote:I understand creating a new value, but I'm having a problem deciding what values to use. The initial values (day, month, year) are all locked as private and will not transfer over into a test driver. Should I create new ones within the test driver? If so, how then will I be sure that it is calling the setter methods for testing?


That's all Greek to me. Like Dennis said, if you want to test a setter method, then here's what you do:

(1) Get the value of the variable which the setter affects. Store it in a local variable. (If that counts as "creating a new one", then yes, create a new one.) If you're concerned that the variable in question is private, then use some public method of getting that value.

(2) Call the setter method to assign a different value than what you just got. (Why would you not be sure that the test driver would be calling the setter method?)

(3) Get the value of the variable again. Check that it is the value that the setter method assigned in step 2 and not the value originally acquired in step 1.


Thank you...the way you put it made it a bit easier to understand. I've had a bit of a rough week so my head just isn't functioning as it normally would.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic