[Python-Dev] Cleaning-up the new unittest API

[Steven D'Aprano]

Raymond Hettinger wrote:
> The API for the unittest module has grown fat (the documentation
> is approaching 2,000 lines and 10,000 words like a small book). 
> I think we can improve learnability by focusing on the most 
> important parts of the API.
> 
> I would like to simplify and clean-up the API for the unittest module
> by de-documenting assertSetEqual(), assertDictEqual(),
> assertListEqual, and assertTupleEqual().

While you're at it, what do you think of assertAlmostEqual? Is there a 
use-case for it as it exists now?

As I see it, it suffers from a number of problems:

(1) Comparing floats for equality to some number of decimal places is 
rarely (never?) the right way to do it. Comparison to some number of 
significant figures would be better. Specifying an absolute or relative 
error would be better still.

(2) This leads people to write the wrong test, because assertAlmostEqual 
exists and is easy to use, while the right test is tricky and requires 
better understanding of floating point issues.

Example: I recently wrote tests using assertAlmostEqual where I 
specified places=12, because my code should have been accurate to 12 
significant figures. Worked fine for small floating point, but when I 
started testing values of the order of 10000, my tests started failing, 
because although it was correct to > 12 significant figures, five of 
those figures were not decimal places.

(3) In the rare case that mere rounding is the right way to compare for 
approximate equality, assertAlmostEqual doesn't save you much: a handful 
of characters, that's about all.

self.assertAlmostEqual(x, y, places=n)

vs.

self.assertEqual(round(x, n), round(y, n))

(Specifying the number of decimal places is keyword-only in 3.1. To me, 
that seems to be a gratuitous change from 2.x, where it could be 
specified as a positional argument.)



-- 
Steven