I like Gustavo's division - slow tests and fast tests, not unit tests and integration tests. Certainly, integration tests are often also slow tests, but that's not the division that really matters.
*I want* go test github.com/juju/juju/... *to finish in 5 seconds or less. I want the landing bot to reject commits that cause this to no longer be true.* This is totally doable even on a codebase the size of juju's. Most tests that don't bring up a server or start mongo finish in milliseconds. There are many strategies we can use deal with slower tests. One of those may be "don't run slow tests unless you ask for them". Another is refactoring code and tests so they don't have to bring up a server/mongo. Both are good and valid. This would make developers more productive. You can run the fast tests trivially whenever you make a change. When you're ready to commit, run the long tests to pick up anything the short tests don't cover. Right now, I cringe before starting to run the tests because they take so long. I don't personally care if it's a test flag or an environment variable, hell, why not both? It's trivial either way. Let's just do it. -Nate
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
