The Artima Developer Community
Sponsored Link

Weblogs Forum
One Assertion Per Test

22 replies on 2 pages. Most recent reply: Mar 1, 2004 10:37 AM by Dave Astels

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 22 replies on 2 pages [ « | 1 2 ]
Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: One Assertion Per Test Posted: Feb 24, 2004 1:42 PM
Reply to this message Reply
Advertisement
Whilst refactoring the example above may be easy, refactoring isn't an end in itself but a mechanism for reaching another end. At the moment there is no reason to modify this code other than because "it is crap" and that, in itself, just isn't enough. There are bigger fish to fry.

The seminar idea is good, worth some consideration for this summer.

As to the original author. He's currently showing me the ropes here and is very helpful. I'm not going to bite the hand that feeds me (yet). Besides, the code is old (in Java years) - note the asert rather than the assertTrue statements. He may have become more conventional in his old age!

Actually, I love all this "crap" code. It's just such a pleasurable change for me to have live code I can really improve rather than live code daunts me.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: One Assertion Per Test Posted: Feb 25, 2004 1:28 PM
Reply to this message Reply
Yikes! Could the cure be worse than the disease?

Seems like a heck of a lot of code to test the parsing of one simple line. Maybe it's just this example.

What is the prescribed ratio of unit test code to program code? 100 lines of unit test per line of code?

It seems to me that an arbitrary rule about number of assertions per test doesn't make as much sense as simply logically grouping related assertions into a well-named test. Also, each assertion can have a message that goes with, can it not? I want things to be as clean, concise and simple as possible.

Dave Astels

Posts: 32
Nickname: dastels
Registered: Mar, 2003

Re: One Assertion Per Test Posted: Feb 26, 2004 8:27 AM
Reply to this message Reply
> Yikes! Could the cure be worse than the disease?

As with medicine.. sometimes, yes ;-)

> Seems like a heck of a lot of code to test the parsing of
> one simple line. Maybe it's just this example.

Largely just the example.

> What is the prescribed ratio of unit test code to program
> code? 100 lines of unit test per line of code?

My rule of thumb is a 1.5:1 - 2:1 test:app code ratio.

> It seems to me that an arbitrary rule about number of
> assertions per test doesn't make as much sense as simply
> logically grouping related assertions into a well-named
> test.

Yes. To paraphrase... "It's not a rule so much... it's more like a guideline."

> Also, each assertion can have a message that goes
> with, can it not?

Yes. These aren't needed if you don't have multiple asserts. The value of these messages are minimized if you run the tests in a good IDE anyway... you can double click from failure to assert.

> I want things to be as clean, concise and simple as
> possible.

That is always the goal. This one way to sometimes reach that goal. Certainly not the only way.

Dave

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: One Assertion Per Test Posted: Feb 26, 2004 3:33 PM
Reply to this message Reply
This is something I'm going to have to try. Right now I'm finding it difficult to concieve of OAPT. I do agree that each test case should have one and only one goal. However, I think a goal can have several assertions.

I don't want each test function to be a script that walks through a complete thread through the lifecycle of the object under test. Rather I want the test to check one state transition; and to do that, I need more than one assertion.

Dave Astels

Posts: 32
Nickname: dastels
Registered: Mar, 2003

Re: One Assertion Per Test Posted: Feb 26, 2004 6:44 PM
Reply to this message Reply
> This is something I'm going to have to try. Right now I'm
> finding it difficult to concieve of OAPT.

Oh! A new acronym...

> I do
> agree that each test case should have one and only one
> goal. However, I think a goal can have several
> assertions.

Certainly. This article was about an idea taken to eXtremes ;-) The goal is to test one thing, in the extreme that means one assertion.

Also, it was in response to a "there's no way this could be done with simpler test methods" style statement.

> I don't want each test function to be a script that walks
> through a complete thread through the lifecycle of the
> object under test. Rather I want the test to check one
> state transition; and to do that, I need more than one
> assertion.

Quite often, yes. The goal is to make tests as focused as possible... surprizingly often I've found that by not being afraid (and it does seem like fear often) of having lots of test classes/methods you can get very close to (or reach) OAPT.

OAPT is a data point. How close can you get to it? How close does it make sense to get to it in a particular situation? The answers are not as interesting as being able to know or figure out the answers.

Dave

Tim Vernum

Posts: 58
Nickname: tpv
Registered: Dec, 2002

Re: One Assertion Per Test Posted: Mar 1, 2004 12:07 AM
Reply to this message Reply
> However, I think a goal can have several
> assertions.

I'm not sure whether this fit's Dave's philosophy but "One Assertion Per Test" doesn't mean it has to be one of JUnit's own assertions.

If your goal is not expressible in one "assert" it may be that you can write:
assertListIsReadOnly( list) ;

where assertListIsReadOnly tries to use each method on the List interface and checks it gets an exception.

I'd hate to see
  public void testAddThrowsExceptionWhenListShouldBeReadOnly()
  public void testClearThrowsExceptionWhenListShouldBeReadOnly()
  public void testAddAllThrowsExceptionWhenListShouldBeReadOnly()

etc...

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: One Assertion Per Test Posted: Mar 1, 2004 2:39 AM
Reply to this message Reply
> I'm not sure whether this fit's Dave's philosophy but "One
> Assertion Per Test" doesn't mean it has to be one of
> JUnit's own assertions.

This sounds like a sensible position. The only problem is that you now identified a point of confusion in that the verb "to assert" is being used within the same domain by different people to describe two subtly but importantly different things.

1) A JUnit assert identifies a single fact.
2) A more general assertion can (or should) relate to a single property of a system (and can consist of several facts) - (e.g. verifying a multi-parameter constructor with JUnit asserts on more than one of the created object's getters).

Clarity on the above definitions (if my reading is correct) would be helpful, to prevent people talking at cross-purposes.

I'm easy with the view that a test should make one general assertion but that it can use more than one JUnit assertion to do so. However, I don't think both should be called assertions. One of them should be referred to differently.

Vince.

Dave Astels

Posts: 32
Nickname: dastels
Registered: Mar, 2003

Re: One Assertion Per Test Posted: Mar 1, 2004 10:37 AM
Reply to this message Reply
Hi Tim,

> I'm not sure whether this fit's Dave's philosophy but "One
> Assertion Per Test" doesn't mean it has to be one of
> JUnit's own assertions.

That's completely true.

There's nothing to say you can't write custom assert methods that focus on some aspect of the behaviour. The key, as said above, is focus. If you can write an assert method that focuses on one aspect, and give it a good name, then your test is clear and concise.

> If your goal is not expressible in one "assert" it may be
> that you can write:
> assertListIsReadOnly(list);
>
> where assertListIsReadOnly tries to use each method on the
> List interface and checks it gets an exception.

I'd tend toward a more descriptive name.. maybe

assertReadOnlyListThrowsExpectedExceptions() ?


Dave

Flat View: This topic has 22 replies on 2 pages [ « | 1  2 ]
Topic: Thinking out loud, and in public... Previous Topic   Next Topic Topic: Yahoo groups are enormously popular. That's probably an understatement.

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use