Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
The Art of Writing Software
Subscribe
Monthly Archive
-
▼
2007
(27)
-
▼
July
(8)
- Exposing the stereo knobs
- Customer engagement
- Keep it Simple, Stupid
- Using interface hierarchies to enforce access prot...
- TestUtil: package for unit testing setters/getters
- Unit testing boolean setters and getters
- Unit testing setters and getters for Java base types
- Unit testing setters and getters
-
▼
July
(8)
All articles Copyright © 2007-2019 by Jon Moore. All rights reserved.
6 comments:
Yes, you did miss something - using your own judgment.
Testing getters and setters makes no sense if they do not have any functionality in them. They're just boilerplate.
Even if someone made a tool for that purpose, it still makes no sense.
This XP craze has really gotten out of hand ...
I was about to agree with you, except that I've actually been bitten by simple setters and getters that changed into something non-simple. This typically happens in a class where the population of the field value goes from injection to some kind of lazy-loading, as in:
public Foo getFoo() {
if (this.foo == null) {
this.foo = getFooFromFooDao();
}
return this.foo;
}
Simplified, obviously. However, as soon as you move to doing this, any internal references to this.foo probably need to change into getFoo() calls instead to avoid the NPEs. Unit tests would definitely help you catch this.
Furthermore, if my IDE, in the same command that I use to insert the automatically-generated setters/getters can also insert the automatically-generated test code for them, it seems like no real skin off my back.
Also, nothing in my post has anything to do with XP. If you prefer to ship your software without automated tests, please feel free to do so.
> that changed into something non-simple
Yes. This is when you start unit testing the method.
Getters & setters that do not have any kind of functionality should not be tested IMHO - even when the IDE supports some kind of generation.
It's easier to find the interesting (actual tests) when the test classes aren't full of auto-generated test skeletons that do nothing.
So, your main objection is that it makes the test cases harder to read? I guess I could see that argument, although I wonder if code organization would help you here--keep all the automatically-generated unit tests at the end of the test class, for example.
I do know that in the rush to get code to production, it's all too tempting to make a small tweak ("But it's wafer-thin!") to a simple getter method that doesn't have a unit test yet, and then let the unit test slide. So for me, I'd rather have a unit test in there that broke and reminded me I need to write a new one.
I agree that you're not really testing anything interesting by testing the setters and getters (particularly when the code for them is automatically generated and likely error-free). If you can always remember to add a unit test when you change them, then I see nothing wrong with that approach.
I'm just bad at remembering, so I like to have reminders. :)
By the way, Anonymous commenter, thanks for the comments. This is the kind of discussion I was hoping to get out of writing some of my ideas up. :)
But still we enjoyed reading of your post. There would be no doubt if I would say that Anonymous and Jon well interacted with each other and found out one solution of the discussion :)
Post a Comment