Re: [Junit-devel] why not assertEquals(actual, expected)?

[Dossy <do...@pa...>]

On 2003.01.31, Janto Dreijer <jf...@jf...> wrote:
> | On 2003.01.31, Janto Dreijer <jf...@jf...> wrote:
> | > Is there a reason why the order of the parameters to assertEquals are
> | > (expected, actual) and not (actual, expected)?
> | [...]
> | > It doesn't have the kind of dataflow I think in: left to right.
> |
> | When you do Test-First Programming, it does follow the flow in which you
> | think: test, then code.  Expected, then actual.
> 
> Ehhh, I find it difficult to think that way when it comes to a single line
> of code. If it's easier for you to scale the TestFirst methodology (even to
> writing the tests themselves) then I guess I can't argue with you.
> 
> ...except if you're lying and actually *do* find it hard :-)

I found it hard at first, but the more I do it, the easier it becomes.
Funny how that works ... ;-)

> The problem I have is I can only expect something if there is a
> context to expect it in: I need to refer to the function before I can
> talk about the returned value.

I used to do that as well.  These days, I think about "what should the
working code do -- what should its output look like given some inputs?"
and then I actually go and do by hand what the program should do.  Then,
I just code until it does what I thought it should.

If I only think about what the code should ultimately do once the code
is written, I lose the advantage of foresight (knowing what the desired
end result looks like) as well as possibly having to throw out code that
cannot possibly produce the desired end result, or would require
significant effort to transform it into a form that can.  That's
wasteful, and waste means additional cost which means less profit.

Some people call it "cheating" ... it almost feels like cheating.  But,
I'd rather write code that does exactly what I want it to do, rather
than try to make myself want what the code I've written does.  :-)
 
> I guess I'm still in the paradigm of "tests are there to exercise
> functions" instead of them being a design guide.

I agree with you.  Sometimes it's a big leap of faith but I think once
you make it (thinking of tests first and letting them guide the design)
you find that really elegant designs from fairly simple (and few) tests
... it's really impressive when you get it right.  And, when you don't
get it right, you have at least really excellent test coverage ... ;-)

> Thanks for disagreeing.

Thanks for listening to what I said.  I hope I've at least given you a
different way of seeing things so that the assert*(expected, actual)
doesn't seem so much a mistake as it probably seemed earlier.

-- Dossy

-- 
Dossy Shiobara                       mail: do...@pa... 
Panoptic Computer Network             web: http://www.panoptic.com/ 
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)