junit-devel

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

[Janto D. <jf...@jf...>]

Is there a reason why the order of the parameters to assertEquals are
(expected, actual) and not (actual, expected)?

Say f() returns the string "invalid data".
Then calling
    assertEquals( f(), "correct ouput" )
will print:
    expected "invalid data" but found "correct output"
    (or something like that)

Now maybe it's just me, but the result doesn't look very natural. Neither
does the order of the parameters if I were to swap them around:
    assertEquals( "correct ouput", f() )
It doesn't have the kind of dataflow I think in: left to right.

I hope you guys don't think it's too late to change the works :-)

I'm relatively new to jUnit, so if there's something obvious I'm missing...

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

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

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.

-- 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)

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

[Janto D. <jf...@jf...>]

| 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.
|
| -- Dossy

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 :-)

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 guess I'm still in the paradigm of "tests are there to exercise functions"
instead of them being a design guide.

Thanks for disagreeing.

Janto

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)

[Junit-devel] Why Bill Venners Refactored JUnit

[Alan C F. <li...@tw...>]

http://www.artima.com/suiterunner/why.html

"Just some friendly advice: if you ever find yourself saying it would be
easier to rewrite something rather than figure it out, slap yourself.
Chances are you are wrong. I certainly was. Creating SuiteRunner was a huge
amount of work. Despite my frustrations with JUnit, it would have been
orders of magnitude easier to decipher JUnit's source code than to create a
brand new testing toolkit."

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

[Kent B. <ke...@th...>]

Line a bunch of assertEquals in a row. Having expected first makes them
read better. And yes, it's too late to change it.

Kent

> -----Original Message-----
> From: jun...@li... 
> [mailto:jun...@li...] On Behalf Of 
> Janto Dreijer
> Sent: Thursday, January 30, 2003 2:42 PM
> To: jun...@li...
> Subject: [Junit-devel] why not assertEquals(actual, expected)?
> 
> 
>  
> Is there a reason why the order of the parameters to 
> assertEquals are (expected, actual) and not (actual, expected)?
> 
> Say f() returns the string "invalid data".
> Then calling
>     assertEquals( f(), "correct ouput" )
> will print:
>     expected "invalid data" but found "correct output"
>     (or something like that)
> 
> Now maybe it's just me, but the result doesn't look very 
> natural. Neither does the order of the parameters if I were 
> to swap them around:
>     assertEquals( "correct ouput", f() )
> It doesn't have the kind of dataflow I think in: left to right.
> 
> I hope you guys don't think it's too late to change the works :-)
> 
> I'm relatively new to jUnit, so if there's something obvious 
> I'm missing...
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 
> 2 See! http://www.vasoftware.com 
> _______________________________________________
> Junit-devel mailing list
> Jun...@li... 
> https://lists.sourceforge.net/lists/listinfo/j> unit-devel
>