Django test documentation example not respecting xUnit convention

[James Pic]

Hello everybody,

Sorry if this topic has already been brought, I asked about it on IRC but nobody answered.

Being a old user of xUnit patterns in several languages, i just figured that there might be a mistake in django testing documentation example.

The example is: self.assertEqual(self.lion.speak(), 'The lion says "roar"')

Which corresponds to: assertEqual(actual, expected)

Wheras the xUnit convention is: assertEqual(expected, actual)

For poeple who are not already aware of this decade old convention: "By convention, the expected value is specified first and the actual value follows it". Source: http://xunitpatterns.com/Assertion%20Method.html#Equality Assertion

Apparently, Python's unittest assertEqual documentation does not mention this convention: http://docs.python.org/library/unittest.html#unittest.TestCase.assertEqual

Why do you think Python took such a position against a decade old convention in every language i had the chance to test in ?

What's your position ?

Regards

[Florian Apolloner]

Hi,

a) Does this matter at all? I mean what's the difference? You ask if they are equal and if not you get an error ;)
b) I think it's the wrong mailing list for design decisions python took…

Cheers,
Florian

[Calvin Spealman]

It wasn't a decade old convention when python 2.1 added the unittest package a decade ago, to be fair.

>
> What's your position ?
>
> Regards
>

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Daniel Moisset]

On Tue, Sep 20, 2011 at 8:23 AM, Florian Apolloner <f.apo...@gmail.com> wrote:

Hi,

a) Does this matter at all? I mean what's the difference? You ask if they are equal and if not you get an error ;)

Other xUnit framework actually show an error message explicit about it, saying "expected 'foo', actual 'bar'". Python's unittest just says "foo != bar".

The difference is slightly more understandable error message when an equality test fails: you know what the actual result was supposed to be
 

b) I think it's the wrong mailing list for design decisions python took…

Or perhaps lack of design decision in this case? (I'm not sure it was intentional)

Regards,
    D.

[Russell Keith-Magee]

It certainly wasn't intentionally reversed from the "convention"; it's
an artefact of Python's documentation not making the ordering
distinction, reinforced by the foo != bar output format that was
referred to.

Should the examples be changed? For my money, I don't think it makes a
whole lot of sense to adopt a convention that isn't reinforced by
Python at a language level.

For what it's worth, I also think the "convention" is bass ackwards...
you write "if variable == value", but you write "assertEqual(value,
variable)"? Where's the consistency in that?

Yours,
Russ Magee %-)

[Alex Gaynor]

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

FWIW there was a thread either on python-dev, or maybe python-idea, or it might have been the Python ticket tracker, about officially stating a convention for (expected, actual) vs (actual, expected), the conclusion (IIRC) was that they weren't documenting a preference, but if there was one, it was (actual, expected).

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

[schinckel]

It isn't 'enforced' by Python at a language level, but as dmoisset stated, it makes the failure messages actually make sense:

    "Expected 'foo', got 'bar'".

(paraphrasing failure message: don't have any failing tests to look at right now. YAY! :)

Matt.

[Łukasz Rekucki]

On 21 September 2011 02:01, Russell Keith-Magee <rus...@keith-magee.com> wrote:
>
> For what it's worth, I also think the "convention" is bass ackwards...
> you write "if variable == value", but you write "assertEqual(value,
> variable)"? Where's the consistency in that?
>

My guess is that the choice is somehow connected to Yoda conditions,
where you actually write:

if(5 == x) { ... }

to avoid assigning 5 to x by mistake. If you write all your conditions
like that, then the assert order makes sense.

But Python thankfully doesn't need any of that Jedi stuff.

--
Łukasz Rekucki

[Łukasz Rekucki]

My Python 2.7 says:

self.assertEqual(result['active'], 2)
AssertionError: 1 != 2

So, no. The message in Python is order agnostic.

--
Łukasz Rekucki

[Daniel Moisset]

On Wed, Sep 21, 2011 at 2:13 AM, schinckel <ma...@schinckel.net> wrote:

It isn't 'enforced' by Python at a language level, but as dmoisset stated, it makes the failure messages actually make sense:

    "Expected 'foo', got 'bar'".

Actually that's not the message in Python's unittest (but I've seen messages with that formatting in other xUnit frameworks for other languages)

D.

[schinckel]

Yeah, I saw that later when I wrote some tests.

I'm sure I saw the style of failure message with some django app tests I wrote ages ago: maybe my brain has failed that test and it was a ruby unit test.

Matt.