Let’s say I wanted to start an open source project that I hope/expect to have many people submit patches and whatnot. Is it viable to take a strict TDD approach? Can/should I expect/trust collaborators to write quality tests whenever they submit a patch?
One thing I’ve been thinking about is writing test suites for individual bug reports and feature requests and requiring that all patches/pull requests make the tests pass, but at that point it seems like it would be better just to write the feature/bugfix myself.
As far as I can tell, most of the major open source projects that use TDD (or at least write tests) seem to be mostly written purely by an individual or team, where it’s easy to enforce practices such as TDD.
5
You can’t really enforce a TDD (test first) approach on an open source project where patches can be submitted by the general public.
What you can enforce is that all patches must have a set of test cases for the fixes included in the patch and that those test cases, as well as all the existing test cases, must pass. You can enforce this by only giving commit rights to a few trusted developers who are known to use and agree to the policies of the project and by publicly stating that submissions/pull-requests will only be incorporated if they come with passing test cases (with sufficient coverage).
This doesn’t ensure that the test is written first, but it does ensure that the test is written.
4
You could ask people to submit test-only patches before they’re allowed to work on the code; this would provide an additional opportunity to review the planned design before the code itself is written.
In practice, this may kill any enthusiasm people have for contributing to the project–or it might kindle a fire in those who agree with your methodology.
Reviewers would have to be very good about turning around the design reviews quickly, however, so as not to stall out development.