Extend matchers and refactor about expycted HOT 5 CLOSED

All, 1., 2. and 4. sound great, I have nothing to add there.
On 3rd point I have just few clarifying questions:

• to_have_attributes() is going to take a list of names of expected attributes as arguments?
• What is to_almost_equal() meaning to match? Numeric similarity with some sort of acceptable delta?

Your changes are very welcome!

from expycted.

Regarding to_have_attributes, I imaging the following overloaded signatures:

def to_have_attribute(self, key: str):
    ...

def to_have_attribute(self, key: str, value: Any):
    ...

def to_have_attributes(self, *keys: str):
    ...

An explanation of to_almost_equal from the Python's built-in unittest package.

from expycted.

Both sound great! Looking forward to the PR(s)!

from expycted.

@petereon Before I get started, one more question, is there a reason why you split alias and negated test into separate methods?

Example:

• test_to_contain_subfolder
• test_to_contain_subfolder_failing
• test_to_not_contain_subfolder
• test_to_not_contain_subfolder_failing

from expycted.

@bdsoha Yes, it's for legacy reasons, there have previously been separate implementations for negated matchers. Aliases don't necessarily make sense, I agree. As it is it would presumably make more sense to test just the __init__ method that it negates correctly.

from expycted.