I am divided with how I should test ecrire...

Ok here's a monologue for you who reads commits:

I am torned between two method of testing ecrire. The first would be to
use unit::test for model, controllers, helpers. This requires to
carefully look at every layer and try to build a test that does not
overlap with underneath layers. This is hard because if you take the
Post model, there's test units covering things like callbacks &
validations. So I don't want to test those again. So I'm building
controller test to send params and introspect the Post variable to make
sure everything has changed. Want to make sure errors are propagated?
Then I check if the error are set. And there I go double
testing the model.

The second would be to use a headless browser and test from the
controller and higher through CSS/DOM/JS assertions. This is nice but
can become very painful to maintain as you have to adapt every test
everytime you change the DOM. Imagine a redesign...

I do believe that there's a middle ground though. I think stuff like
pagination & filters in controller could be tested with test units.

I actually think that anything the controller does besides
creating/updating the database could be tested via test units. Same goes
with helpers. I think it's very straightforward to test helpers &
decorators within the test unit enviromnent.

I think the place where headless browser really shine is where you use
forms. Forms are complex beast that are intertwined with models. This is
something that is never going to be trivial to test in the controller
and there's too many different behaviors possible to try to wrap it into
a test::Units. Headless browser can easily look for specific behaviors
and then you would end up only changing capybara's test when your form
are changing.

Long story short, this close #31