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.
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.
> 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.
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.
> 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.
> 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.
> 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
[
«
|
12
]