I love @clarete's idea too.
@dowski now about whether [pinning dependencies](http://nvie.com/posts/pin-your-packages/) or not my proposal here is very simple:

By adding full (or at least reasonably high) test coverage to diesel, there will be no more concerns about whether diesel might break or not. The whole point about having test coverage is to increase the overall quality of the codebase, mainly by making it 100% flexible to any level of modification without worrying about bugs.

One of the things that attracted me to contribute to diesel is that you guys did a pretty good job at separating the tests into different categories: unit, protocol and integration.

In my projects I usually do a similar approach, being:

### unit tests

* Test small methods and functions, preferrably has one [single assertion per unit test](http://www.artima.com/weblogs/viewpost.jsp?thread=35578)

* Unit tests have to run as fast as possible, and therefore I/O is forbidden, components that perform I/O must be isolated and mocked.

### Functional tests

* Test an entire flow in the codebase, for example, a test for diesel's as=synchronous http client method get.
* Allowed to make I/O, as long as doesn't need any 3rd party services that are out of your control. (i.e.: the protocol tests)

### Integration tests

* Usually the slowest ones, involve spinning up a dummy subprocess running diesel just to make actual calls against it and test its behaviour very closely to a production environment

### Acceptance tests

I usually only use acceptance tests when testing a product, but lately I've been writing the documentation of my software adding some "runnable" snippets through out its extent. So I use [steadymark](http://falcao.it/steadymark) to execute this code and make sure it works.

### concluding

Let's get down in this codebase and make it robust and bold like its name, I'm really excited about it!

I once gave a little keynote about unit testing in python, maybe I have illustrated my ideas better in [this deck here](https://speakerdeck.com/gabrielfalcao/unit-testing-in-python).

Cheers