uber/charlatan — pull request #15 by JordanB (2014-01-06 18:35:37+00:00)
Title: Uninstall fixture

This feature adds the capability to uninstall fixtures using one or a set of fixture keys.

We know that the `FixturesManager` class has a `save_instance` method and several `install_fixture` related methods. In a similar way and for parity sake we add a `delete_instance` as well as several `uninstall_fixture` methods.

### Why is that useful?

This is how things were before:

```python
class TestToaster(unittest.TestCase, charlatan.FixturesManagerMixin):

def setUp(self):
self.install_fixture('toast') # this feels magical

def tearDown(self):
toast_fixture = self.get_fixture('toast')
toast = Toast.get(Toast.id == toast_fixture.id)
self.session.delete(toast)
self.session.commit() # why not the same magical pattern?
```

And now you'll be able to do:

```python
class TestToaster(unittest.TestCase, charlatan.FixturesManagerMixin):

def setUp(self):
self.install_fixture('toast') # this feels magical

def tearDown(self):
self.uninstall_fixture('toast') # this also feels magical
```

### How the magic works?

When calling `delete_instance` on the `FixturesManager`, the logic expects (and hopes) that your `Model` instance will have a `delete_instance()` method or a `delete()` method. If it has both, only `delete_instance` will be called. This works for peewee and other standard orm. It is very similar to how the `save_instance` method relies on the `save()` method being defined by your orm.

### Limitations
- deleting is trivial and not recursive (not even an option because too orm-specific)
- make sure your fixtures are set in a additive order in terms of relationships: objects with dependencies set after in the yaml, in an additive manner