Clean up tests

[ingrinder]

As has been discussed previously, the Configuration singleton can cause some problems in our tests. Additionally, I've noticed that our tests aren't very... unit-test-y -- they're closer to integration tests than unit tests. Hopefully, these changes mean:

• No more issues from Configuration in tests.
• Possibility to rewrite future tests to use a new helper method so we can test their methods as individual units.

Description

• Move the default config to archey.constants
  • This is so we can access it from various modules.
  • It is also technically a constant 😛
• Moves entry tests to an entries subfolder.
  • This just seems tidier, especially since we get another __init__.py to define the entry-test-specific helpers in.
• Adds two helper methods for testing:
  • entry_mock -- This creates a mock which we can pretend is an instance of an entry, so we can test instance methods by passing it in as self. This makes it a lot easier to unit-test the instance methods without worrying about having to run an entry's __init__ to get an instance to use them.
  • patch_clean_configuration -- This method should be used as a decorator on entry test definitions, similar to unittest.mock.patch, and it simply means that if we have to instantiate an entry (e.g. like the current tests, and if we need to test __init__), its configuration is automatically mocked out with a mock specced to Configuration with the default Archey configuration in it.
  • The decorator can also be passed an argument configuration, which is a dict that is applied to the default configuration dict using the update_recursive method (akin to the way Configuration loads config files). This allows for way, wayyyy easier configuration setting in tests.
• The Disk entry test's setup has been rewritten to use entry_mock, since I was thinking about this back then and those tests were rewritten specifically to make this a lot easier -- so that one's pretty much my vision for where we can go from here.

Reason and / or context

In addition to the stuff described above, this is also a direct step to #57 where I have an implementation going that could be rebased onto this branch, which would help significantly with the number of broken tests it caused...

How has this been tested ?

There are some quite nice tests for the entry_mock helper method in its __init__.py. As for the decorator, I've yet to figure out exactly how to test that... Either way, all the other tests pass, of course. (The ones currently failing are ones I've added, none of the existing tests are broken).

Types of changes :

This is a bit hard to answer, these are really meta-changes being entirely about the tests.

• Bug fix (non-breaking change which fixes an issue)
• [X] Typo / style fix (non-breaking change which improves readability)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist :

• [IF NEEDED] I have updated the README.md file accordingly ;
• [X] [IF NEEDED] I have updated the test cases which pass accordingly ;
• [X] My changes looks good ;
• [X] I agree that my code may be modified in the future ;
• [X] My code follows the code style of this project (PEP8).

[ingrinder]

Nice! I like that solution, it's very clean.

While having a look through I've noticed that our Configuration._config's sub-dictionaries are mutable when we get them with .get() or using dict() on the instance (ie with your new __iter__ method)...:

Mutating sub-dicts with `.get`

```python >>> class Gettable: ... def __init__(self): ... self._dictionary = {'subdict': {'somekey': 'somevalue'}} ... def get(self, key, default=None): ... return self._dictionary.get(key, default) ... >>> instance = Gettable() >>> instance._dictionary {'subdict': {'somekey': 'somevalue'}} >>> sub_dict_from_get = instance.get('subdict') >>> sub_dict_from_get {'somekey': 'somevalue'} >>> sub_dict_from_get['somekey'] = 'newvalue' >>> sub_dict_from_get {'somekey': 'newvalue'} >>> instance <__main__.Gettable object at 0x7ffa14a53dc0> >>> instance._dictionary {'subdict': {'somekey': 'newvalue'}} ```

Mutating sub-dicts with `__iter__`

```python >>> class Dictable: ... def __init__(self): ... self._dictionary = {'subdict': {'somekey': 'somevalue'}} ... def __iter__(self): ... return iter(self._dictionary.items()) ... >>> instance = Dictable() >>> instance._dictionary {'subdict': {'somekey': 'somevalue'}} >>> dict_from_iter = dict(instance) >>> dict_from_iter {'subdict': {'somekey': 'somevalue'}} >>> dict_from_iter['subdict']['somekey'] = 'newvalue' >>> dict_from_iter {'subdict': {'somekey': 'newvalue'}} >>> instance._dictionary {'subdict': {'somekey': 'newvalue'}} ```

Not ideal, since entries could unintentionally modify it, right? I might have a play about in a new branch changing our behaviour so that only Configuration itself can modify any configuration using its own internal methods.

Anyway, this PR looks good now, I'll go ahead and squash-rebase 👍

Edit: Oh, okay, GH only does squash + merge. That works too 😆