Extend matchers and refactor

[bdsoha]

I would like to propose a few additions and refactors (with your approval, I can begin working on them):

• Allow assertion method chaining #11
• Use the expected and actual terminology in assertion messages and method signatures. #18
• Refactor Tests #15
• Support Path objects in folder expectations #19
• Use dynamic assertion calls instead of manually invoking internal method #9

[petereon]

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!

[bdsoha]

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.

[petereon]

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

[bdsoha]

@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

[petereon]

@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.