Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Unit testing: why is the expected argument always first in equality tests?

Tags:

unit-testing

Why is it that every unit testing framework (that I know of) requires the expected value in equality tests to always be the first argument:

Assert.AreEqual(42, Util.GetAnswerToLifeTheUniverseAndEverything());  assertEquals(42, Util.GetAnswerToLifeTheUniverseAndEverything()); 

etc.

I'm quite used to it now, but every coder I try to teach unit testing makes the mistake of reversing the arguments, which I understand perfectly. Google didn't help, maybe one of the hard-core unit-testers here knows the answer?

like image 202
Sebastiaan M Avatar asked Feb 17 '12 15:02

Sebastiaan M


People also ask

Why is it recommended to have only one assert statement per test?

“One assertion per test” is a wise rule to keep in mind, because it helps you have tests that fail for a specific reason, and drives you to focus on a specific behavior at a time.

Why should you only test one thing at a time?

Testing only one variable at a time lets you analyze the results of your experiment to see how much a single change affected the result. If you're testing two variables at a time, you won't be able to tell which variable was responsible for the result.

Should unit tests only test one thing?

This guideline is much more aggressive and recommended if you work in a test driven manner rather than write the tests after the code has been written. The main goal here is better code coverage or test coverage.


1 Answers

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

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

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

instead of

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

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

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

Sounds about right. Now:

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

Hm..? You probably wouldn't be too surprised if somebody told you that roses are red. Other way around, red are roses, raises suspicious 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 your assertions are more complex:

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

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

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

like image 145
k.m Avatar answered Sep 23 '22 08:09

k.m