9

Stack Exchange is my role-model for application development. I've tried to learn as much as possible from the blog and podcasts, from thought process to design, architecture, convention, etc etc.

I'm just about to wrap my head around TDD and am curious about how the SE team approaches it.

Is there a methodology that all team members follow, or is it more developer-driven testing where you pick complex bits to unit test as needed, or is it more about catch-all integration testing once a piece of functionality is done, or... ?

Any input would be fantastic.

19

It varies. Our library-level code tends to be very well unit- and integration- tested. At the application layer, there's a bit of a split between "q&a" and "careers". The careers code, again, has a high degree of testing. The q&a code.... well, we have some tests, but it would be incorrect to say that we live in a pure TDD world. Simply, in our particular case, we've felt that there isn't a huge overlap between the "errors this would help us catch" and "the errors that actually cause problems". We have no problem whatsoever spending time to solve real problems - and if this was something that was hurting us we would go fix that, but to date: this simply has not been an issue. We try to avoid imagineering (which is not to dismiss the value of testing, by an means).

Additionally, note that the q&a code has some pretty ambitious performance targets. To achieve that, we actively avoid unnecessary abstractions. Necessary abstractions are fine and encouraged. But you wouldn't add an IAbstractFactoryBuilderFactoryProviderService without facing the mocking wrath of the team (or is that "wrathful mocking"?). We care about the design of the code, but we don't add layers that don't solve an actual problem that we genuinely have. I don't say this as a "here's why we don't go crazy with TDD" - but it is tangentially related. If we wanted to go fully TDD in the app-code, we could - but there would be quite a lot of change required. Which, to be fair, is also not something we object to - we tend to be pretty happy (and able) to perform large refactors on the code.

If a developer feels that a particular area needs more tests: that's fine. Go do that. But there isn't a hard rule about "100% code coverage" or anything. Actually, if we ever got 100% code-coverage, I would start to suspect that I was in a Philip K. Dick-esque fantasy world in my own fevered imagination. The team trusts the team to make sensible decisions about what needs rigorous testing.

Stack Exchange is my role-model for application development

I genuinely don't claim any of this is a "here's how you should work"; the strategy we use is based on a full understanding of the problems we face daily (and importantly, the problems that we don't face daily). Every team, and every project, is different. I don't think the above would fly in finance, medical, education, or military systems (although I suspect that it happens more often than people might think in all four cases).

  • What you mean is you test well the stuff that people pay for and test less the stuff that people don't pay for but enjoy hunting down bugs in :-)? Sounds like that'd work. – ben is uǝq backwards Nov 5 '13 at 8:10
  • 4
    Wait a second, aren't you the guy who blesssed the chat code with a StackExchangeSiteFactory class that implements ISiteFactory and takes a SiteBuilder object which in turn needs an IUserService? :) – balpha Nov 5 '13 at 8:10
  • 4
    @balpha but I resisted the urge to create an IAbstractSiteFactoryBuilderProviderService... so all's well! – Marc Gravell Nov 5 '13 at 9:08
  • Thank you for your time Marc, much appreciated. – RobVious Nov 5 '13 at 15:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .