Unittest assertEqual argument names

Documentation
1

The signature of assertEqual is as follows:

def assertEqual(self,
                first: Any,
                second: Any,
                msg: Any | None = None) -> None

In the documentation nowhere does it mention that the first argument corresponds to the expected, while the second to the actual.
The arguments should clearly be renamed to expected and actual, as the first, second naming convention is confusing to the point where the Copilot is giving me the wrong order of the arguments. This naming style belongs to ICPC olympiad programming niche, please keep it out of proper code that is meant to do something useful and be used and read by others.

2

I always assumed that the first was the actual and the second was the expected because that’s the case in the examples and in code I’ve read.

However, assertRaises has the exception (expected) first and the expression (actual) second and some others also don’t have the expression (actual) first.

3

Welcome to the forum. I highly recommend treating everyone here with respect, and in particular show gratitude to people who have done an enormous amount of free work for you (that is, anyone who is maintaining an open source tool you use). Rather than this.

4 Likes
4

Oh, I mean it’s not that hard to figure out, but even as you said, you had to make this assumption, which would not have happened if the arguments were named properly.

5

My bad, I didn’t mean my message to be offensive.

1 Like
6

actual and expected would be better names you’re right. But it doesn’t merit a breaking change (even if most new test code will be using Pytest instead of unittest classes).

7

Historical context, reasoning to keep it as first/second
https://mail.python.org/pipermail/python-dev/2010-December/106954.html

4 Likes
8

As the message suggested, the differentaion between expected and actual has been removed and AFAICT does not exists anymore for assertEqual, so the naming and order is irrelevant.

However, pytest does assigns these labels to this - but this is a pytest issue, not something to be fixed in unittest.

2 Likes
9

When introducing Python testing to people, I generally tell them that unittest is first and foremost for testing cpython itself. It is available to third party users, but any changes need to be useful to cpython developers. Nobody is looking to attract more users to unittest, and everybody has better things to do with their time than bikeshed unittest.

(This is my strong impression, though I’m happy to be corrected.)

pytest is a mature framework, and is what I recommend to anybody starting out with testing in Python. The fixtures are idiosyncratic, but once you get used to them, it’s very ergonomic. And if you have proposals, it is under active development and intended for a broad audience.

1 Like
10

I see, thanks for the suggestion! I guess I will be using pytest for my next projects…

11

Thanks for the link!

12

unittest indeed is used to test CPython itself, as is test. However, while test is meant for internal development only (see the note in the docs), unittest very much is intended for third parties as well.

Personally I also much prefer pytest in other projects, and it is more popular, but unittest is nevertheless widely used. The Python Developers Survey 2023 reports 52% using pytest and 25% using unittest (with fairly similar numbers back to 2018).

And unittest continues to see improvements, such as new methods like assertStartsWith(), and coloured output in 3.14.

1 Like