10

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.

Improve this question
5
  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    Dec 19, 2013 at 7:10
  • @gnat I've searched StackExchange, and there have been a few questions where people ask of examples of open source projects with unit tests, which isn't the same as my question. As per your request, I've added some more information.
    – DormoTheNord
    Dec 19, 2013 at 7:16
  • 1
    DormoTheNord I believe @gnat meant specific, cited examples.
    – haneefmubarak
    Dec 19, 2013 at 7:26
  • "it would be better just to write the feature/bugfix myself." With or without tests? Are you a TDD proponent or just checking to see if it is viable in this context?
    – JeffO
    Dec 19, 2013 at 10:34
  • Of course you can/should expect collaborators to write quality tests whenever they submit a patch. That's not only beneficial - it's extremely common in large open source projects today (I can give examples if you'd like).
    – Benjamin Gruenbaum
    Dec 19, 2013 at 17:45

2 Answers 2

Reset to default
29

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.

Improve this answer
4
  • 1
    Surely the repository owner can decline to pull any changes that don't conform to the project's quality standards? Perhaps the quality and quantity of contributions would suffer if contributors dislike this, but that;s not to say you can't enforce it. Surely?
    – Tom W
    Dec 19, 2013 at 14:41
  • 2
    @TomW: How would you check that my submission is created according to TDD practices and not, for example, with the tests written after the implementation was done?
    – Bart van Ingen Schenau
    Dec 19, 2013 at 15:13
  • Ah, I see what you mean. I suppose some loss of rigour is inevitable, but you can still verify that code comes with tests, that the tests are sufficiently granular and they cover everything they're supposed to. I'm not that familiar with git, but for a given pull request, is it possible to inspect the sequence of commits for that changeset to see that the developer followed a suitable process to produce it?
    – Tom W
    Dec 19, 2013 at 15:43
  • In other words, you can't confirm one's internal process, but you can ensure the output of that meets a certain standard. Requiring tests, and making sure the design is logical is within the owner's power.
    – Adrian Schneider
    Dec 19, 2013 at 17:21
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.