Pytest: Extend pytest.approx to handle strings.

Created on 16 May 2018 · 12Comments · Source: pytest-dev/pytest

This issue is a developer and community discussion on how strings should be handled in pytest.approx()

Two of the easiest ways to do text matching in pytest are:

Regex Matching
assert "abc" in "abcdef"

I enjoy the benefits that using assert gives me because of its strength in pytest, but It's not as flexible as Regex could possibly be.

A handy use case I could see is checking to see if an expected string is close to a "template"

psudo-code

template = "You have saved {%} record"
returned_string = "You have saved 10 records"
approx(returned_string, template) -> true

perhaps there is a bounds of some sort

template = "You have saved {%} record"
returned_string = "You have saved 7 records"
bounds = [0, 10]
approx(returned_string, template, bounds) -> true

bounds = [0,5]
approx(returned_string, template, bounds) -> false

It seems that a template/bounds combo seems to be a good way to extend string comparison beyond the substring in string model.

I am very eager to think about other ideas or use cases people have 😄

approx proposal

Source

Drew-Ack

Most helpful comment

i propose using a new name for comp arables that support string matching, as its strictly a different topic

RonnyPfannschmidt on 16 May 2018

👍3

All 12 comments

GitMate.io thinks possibly related issues are https://github.com/pytest-dev/pytest/issues/3085 (Remove support for strings to pytest.main), https://github.com/pytest-dev/pytest/issues/719 (pytest.mark.parametrize string-based parameter list doesn't handle single element tuples), https://github.com/pytest-dev/pytest/issues/109 (Unable to extend reports when using pytest-xdist), https://github.com/pytest-dev/pytest/issues/1411 (Pytest stops), and https://github.com/pytest-dev/pytest/issues/544 (pytest 2.6 remove some strings in pathname).

pytestbot on 16 May 2018

i propose using a new name for comp arables that support string matching, as its strictly a different topic

RonnyPfannschmidt on 16 May 2018

👍3

If I understand correctly, we make a new class that is for comparing objects. Leaving approx alone so it can focus on numbers.

Should this new comparable class focus strictly on strings or be constructed in such a way that it can expand to other types?

Drew-Ack on 16 May 2018

this should be a plugin as a starting point as its not clear how to name things and how it should work

RonnyPfannschmidt on 16 May 2018

I agree on using a different name than approx for this, besides the potential for confusion I see the "text matching" class using different configuration options on how to do the matching.

One pattern that I've used in the past is something like this:

assert text == pytest.text_diff(expected, diff_lines=[25, 26, 78])

Where diff_lines would specify lines where the texts could differ: this is common for generated text which includes check sums or date of generation.

OTOH I've not used the approach anymore because it is hard to maintain the text along the code (specially large texts) so lately I have been using an approach similar to pytest-regtest.