Basic JUnit questions
in [Java Programming]
|
From: Patricia Shanahan on 19 Mar 2010 12:25 Graham Cox wrote: > Patricia Shanahan <pats(a)acm.org> writes: > >> I use different criteria. The Eclipse "Source" code generation seems to >> be well tested. If I merely told Eclipse to generate a setter or getter, >> or the equals/hashCode pair, I don't write a test. If I wrote a getter >> or setter myself, it needs testing. I'm fully capable of making a >> mistake in a single line of code. > > Fair point, but I was more getting at the fact that I *do* unit test > generated functions like equals and hashCode, simply because the class > often changes after they were generated and they are no longer > valid. Just because the code was correct at the time of writing > doesn't mean it will always remain so... > If I need to change the equality-relevant fields, and I'm using Eclipse generation, I regenerate equals and hashCode with the new field selection. If, for any reason, I had to edit either of them rather than regenerating, I would add a unit test. Patricia
From: Graham Cox on 19 Mar 2010 12:51 Patricia Shanahan <pats(a)acm.org> writes: > If I need to change the equality-relevant fields, and I'm using Eclipse > generation, I regenerate equals and hashCode with the new field > selection. If, for any reason, I had to edit either of them rather than > regenerating, I would add a unit test. All very reasonable and correct, but can you guarantee that you *always* regenerate the equals and hashcode methods when you change the class? And do you update the equals and hashcode of all subclasses as well? And all wrapper classes? (Admittadly, those last two *should* use the equals/hashCode of the super/inner class in question, but that doesn't always happen...) I find that the few minutes to write a unit test to cover my equals/hashcode implementations are cheap enough to be worth it for the - admittadly very few - times it's actually found something, and is always nice for a little bit extra peace of mind... :) -- Graham Cox
From: Eric Sosman on 19 Mar 2010 13:41 On 3/19/2010 11:49 AM, Graham Cox wrote: > Patricia Shanahan<pats(a)acm.org> writes: > >> I use different criteria. The Eclipse "Source" code generation seems to >> be well tested. If I merely told Eclipse to generate a setter or getter, >> or the equals/hashCode pair, I don't write a test. If I wrote a getter >> or setter myself, it needs testing. I'm fully capable of making a >> mistake in a single line of code. > > Fair point, but I was more getting at the fact that I *do* unit test > generated functions like equals and hashCode, simply because the class > often changes after they were generated and they are no longer > valid. Just because the code was correct at the time of writing > doesn't mean it will always remain so... This is true: Sometimes "maintenance" and "enhancement" are synonyms for "bit rot." But I'm curious: What sort of a test do you write to ensure that equals() and hashCode() play nicely together? For example, if you were writing unit tests for java.lang.String, what would they look like? -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Eric Sosman on 19 Mar 2010 14:01 On 3/19/2010 12:17 PM, Tom Anderson wrote: > On Fri, 19 Mar 2010, Eric Sosman wrote: > >> "How do you know when you've tested enough?" is, of course, a question >> that besets all testing. But with respect to the equals/hashCode pair, >> I suggest that code inspection is a superior approach, because it can >> lead to complete confidence instead of to "Well, I've never seen it >> misbehave." > > How often do you propose to do this inspection, and how you propose to > ensure that it is done? I suggest re-inspection any time either of the methods changes, or if there's a substantive change to any of the fields that affect them (making a non-final field non-private, for example). How to ensure that it's done? The same way (I suppose) you would ensure that a unit test was carefully written, not just checking "x".equals("x") and declaring victory. I'd do the work myself, or I'd tell others to do it, and I'd trust them to act like responsible grown-ups. If they didn't, I'd get angry -- and although I'm generally an easy-going sort of guy, "you wouldn't like me when I'm angry." The procedures and disciplines that get code reviews done can get other things done, too. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Rhino on 19 Mar 2010 14:37
Thank you all VERY much for your confirmation that I was on the right track! And sorry about losing that extra parameter in my example. I lost my train of thought in there somewhere ;-) -- Rhino |