[issue35656] More matchers in unittest.mock

[Yash Aggarwal]

Yash Aggarwal  added the comment:

> due to floating-point inexactness
+1 Its not easy to predict when calculated value will not be equal to expected 
theoretical value. for example math.cos(radians(90)) is something like 6e-17 
rather than 0.
Testing for this exact value would be just awkward.
assertAlmostEqual() is already there in unittest for such comparisons so it 
wouldn't be completely nonsensical to have something like APPROX

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35656] More matchers in unittest.mock

[Petter S]

Petter S  added the comment:

I am of the opposite opinion. :-) 

> if I know roughly what the float should be why would I not want to test it 
> for exactness?

When testing algorithms, it is often the case that the answer should be 
mathematically exactly 2, but due to floating-point inexactness it becomes, 
say, 1.97 in practice. If I then test for exactly 1.97 the test 
becomes very brittle and sensitive for e.g. order of multiplications.

Testing floating point numbers with a relative error is essential in many 
application.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35656] More matchers in unittest.mock

[Lisa Roach]

Lisa Roach  added the comment:

APPROXIMATE feels like it might lead to code smell to me, if I know roughly 
what the float should be why would I not want to test it for exactness? It 
could end up hiding inconsistencies the tests should be catching.

--
nosy: +lisroach

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35656] More matchers in unittest.mock

[Petter S]

Petter S  added the comment:

Agreed! The code above was a quick example. There are also functions in the 
standard library for approximate float matching that the "real" code would use.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35656] More matchers in unittest.mock

[Yash Aggarwal]

Yash Aggarwal  added the comment:

I feel it would be better to have tolerance as an argument.

--
nosy: +FR4NKESTI3N

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35656] More matchers in unittest.mock

[Petter S]

Petter S  added the comment:

Yes, something like this:

class APPROXIMATE:
"""Takes a floating point number and implements approximate equality."""

def __init__(self, value):
self.value = value

def __eq__(self, other):
return abs(self.value - other) / (abs(self.value) + abs(other)) < 
1e-6

def __repr__(self):
return f"APPROXIMATE({self.value})"


Then the following would hold:

got = {
"name": "Petter",
"length": 1.91
}

expected = {
"name": "Petter",
"length": APPROXIMATE(1.9)
}

assert got == expected

But not

got["length"] = 1.8
assert got == expected

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35656] More matchers in unittest.mock

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Looking at the code ANY is simply implemented with __eq__ always returning True 
at 
https://github.com/python/cpython/blob/e61cc481e02b758c8d8289163102c236d0658a55/Lib/unittest/mock.py#L1957
 . I am not sure how APPROXIMATE can be implemented in terms of floating point 
like rounding up or down? Do you have any examples in mind over a sample 
implementation or example of how they should behave in various scenarios?

--
nosy: +xtreak
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35656] More matchers in unittest.mock

[Petter S]

New submission from Petter S :

The ``ANY`` object in ``unittest.mock`` is also pretty useful when verifying 
dicts in tests:

self.assertEqual(result, {
"message": "Hi!",
"code": 0,
"id": mock.ANY
})

Then it does not matter what the (presumably randomly generated) id is. For the 
same use cases, objects like ``APPROXIMATE`` (for approximate floating-point 
matching) and ``MATCHES`` (taking a boolean lambda) would be pretty useful, I 
think.

--
components: Library (Lib)
messages: 332968
nosy: Petter S
priority: normal
severity: normal
status: open
title: More matchers in unittest.mock
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com