[ACCEPTED]-Unit testing: why is the expected argument always first in equality tests?-unit-testing

Accepted answer
Score: 55

It seems that most early frameworks used 25 expected before actual (for some unknown reason though, dice 24 roll perhaps?). Yet with programming languages 23 development, and increased fluency of the code, that 22 order got reversed. Most fluent interfaces 21 usually try to mimic natural language and unit testing frameworks 20 are no different.

In the assertion, we want 19 to assure that some object matches some conditions. This is the natural language 18 form, as if you were to explain your test 17 code you'd probably say

"In this test, I 16 make sure that computed value is equal to 15 5"

instead of

"In this test, I 14 make sure that 5 is equal to computed value".

Difference 13 may not be huge, but let's push it further. Consider 12 this:

Assert.That(Roses, Are(Red));

Sounds about right. Now:

Assert.That(Red, Are(Roses));

Hm..? You probably 11 wouldn't be too surprised if somebody told 10 you that roses are red. Other way around, red are roses, raises suspicious 9 questions. Yoda, anybody?

That doesn't sound natural at all

Yoda's making an important point - reversed order forces you to think.

It gets even more unnatural when 8 your assertions are more complex:

Assert.That(Forest, Has.MoreThan(15, Trees));

How would 7 you reverse that one? More than 15 trees are being had by forest?

This claim (fluency 6 as a driving factor for modification) is 5 somehow reflected in the change that NUnit 4 has gone through - originally (Assert.AreEqual) it used 3 expected before actual (old style). Fluent extensions 2 (or to use NUnit's terminology, constraint based - Assert.That) reversed 1 that order.

Score: 15

I think it is just a convention now and 15 as you said it is adopted by "every unit 14 testing framework (I know of)". If you 13 are using a framework it would be annoying 12 to switch to another framework that uses 11 the opposite convention. So (if you are 10 writing a new unit testing framework for 9 example) it would be preferable for you 8 as well to follow the existing convention. I 7 believe this comes from the way some developers 6 prefer to write their equality tests:

if (4 == myVar)

To 5 avoid any unwanted assignment, by mistake, writing 4 one "=" instead of "==". In this case the 3 compiler will catch this error and you will 2 avoid a lot of troubles trying to fix a 1 weird runtime bug.

Score: 6

Nobody knows and it is the source of never 3 ending confusions. However not all frameworks 2 follow this pattern (to a greater confusion):

  1. FEST-Assert uses 1 normal order:

    assertThat(Util.GetAnswerToLifeTheUniverseAndEverything()).isEqualTo(42);
    
  2. Hamcrest:

    assertThat(Util.GetAnswerToLifeTheUniverseAndEverything(), equalTo(42))
    
  3. ScalaTest doesn't really make a distinction:

    Util.GetAnswerToLifeTheUniverseAndEverything() should equal (42)
    
Score: 6

I don't know but I've been part of several 13 animated discussions about the order of 12 arguments to equality tests in general.

There 11 are a lot of people who think

if (42 == answer) {
  doSomething();
}

is preferable 10 to

if (answer == 42) {
  doSomething();
}

in C-based languages. The reason for 9 this is that if you accidentally put a single 8 equals sign:

if (42 = answer) {
  doSomething();
}

will give you a compiler error, but

if (answer = 42) {
  doSomething();
}

might 7 not, and would definitely introduce a bug 6 that might be hard to track down. So who 5 knows, maybe the person/people who set up 4 the unit testing framework were used to 3 thinking of equality tests in this way -- or 2 they were copying other unit testing frameworks 1 that were already set up this way.

Score: 1

I think it's because JUnit was the precursor 7 of most unit testing frameworks (not that 6 it was the first unit testing framework, but 5 it kicked off an explosion in unit testing). Since 4 JUnit did it that way, all the subsequent 3 frameworks copied this form and it became 2 a convention.

why did JUnit do it that way? I 1 don't know, ask Kent Beck!

Score: 0

My view for this would be to avoid any exceptions 2 eg: 42.equals(null) vs null.equals(42)

where 1 42 is expected null is actual

More Related questions