Suggested autotest scope policy

[jwhitley]

This is a late-breaking reply to this golang-nuts thread. Autotest tools in Ruby, namely Ryan Davis' autotest (part of the ZenTest ruby gem), have sorted out an effective policy for continually running tests. Here's an autotest introduction article that covers its behavior. Other similar tools, esp. in the Ruby world, have also adopted this approach, which I'll summarize as:

1. At start, run all tests.
2. Watch the filesystem for changed files.
3. Run tests relevant to changed files.
4. If at any point there are failures, those tests are re-run on file change events until everything passes.
5. Once all tests are fixed, return to step 1 and run all tests.

The goal is not "efficiency" per se, but rather a workflow that keeps the focus on in-flight changes. For example, a change to existing code might well (temporarily) break functionality and tests across an entire project. The policy above allows the developer some breathing room to first get a change's "local" tests under control before unleashing the whole project's test suite.

[nathany]

@jwhitley Thanks for the post. I think a similar policy could be applied in Go, but probably at a higher level of granularity.

In Go a package is a unit of compilation. The current version of GAT only compiles changed files, but that can result in compilation failures. It really needs to build an entire package. Packages are also a boundary for privacy, so a given project is likely to have a number of packages. So it could focus on a package and then run all much like autotest.

It might be possible to compile everything but only run the relevant tests, though I'm not sure how easily that can be done with the existing Go test runner. Other test runners (like prettytest) might provide more opportunity.

[nathany]

@jwhitley The more I think of it, the less I'm convinced that any autotest like policy makes sense for Go. I'm closing this ticket, but thanks for the suggestion.

[jwhitley]

No problem, thanks for considering it.