Use "Faker" package in tests

[simon-liebehenschel]

https://faker.readthedocs.io/en/master/

It is not a good idea to hard-code manually some specific values for every test. The first problem is that it is a manual redundant work. The second problem is that your test works for "foobar" input, but you do not know whether it will work a "spameggs" or "abcdef" string.

Bad

def test_do_something():
    do_something("foo bar")  # Poor test coverage

Good

def test_do_something(faker: Faker):
    do_something(faker.str())

Good too

def test_do_something(faker: Faker):
    do_something("foo bar")  # It is critical to check exactly this input 
    do_something(faker.str())

A general rule is to hard-code input values only when these specific values must be tested. E.g. it is fine to hard-code "foo bar" input for your test if you have a feeling that the test may fail for the value and it is critical to cover it.

I am using Faker somewhere for 1-2 years and I am fine with it.
There is also another package https://hypothesis.readthedocs.io/en/latest/ which looks very promising, but I have no experience with it.

@Krukov What is your opinion on this?

[Krukov]

Hello, yes you absolutely right. No doubts that tests not so perfect in this project.
I also had been using faker long time ago ( then something goes wrong with me ), and yes it a great tool to gen random data for tests. About hypothesis - I think that is more complicated solution and more about testing boundary values( that is my point of view).

[Krukov]

I have added hypothesis - because there was a good case for it https://github.com/Krukov/cashews/pull/76/files