3 ms·

It “does actually seem to work” at my workplace.

ramraj07 6y ago
And so I have noticed teams and orgs which go for eternity without seeing effective examples of TDD in practice. Is there any resource which might help people like that (includes me?) something that shows TDD in real life scenarios maybe.
- runawaybottle 6y ago
  There’s a world of difference between writing tests for a rest api endpoint vs other types of pesky code. Too big a difference really. Writing a bunch of tests for your utility methods like a DateFormatter is obvious, but if you shackle up other abstract implementations with tests and strict type checking, you can easily make a piece of unalterable code (maybe that’s the point). The question is, what is the value in doing that? Why shackle up all parts of your codebase when only a few parts are critical? I’ll admit that I also lack (and have lacked) guidance on testing.
- villasv 6y ago
  I wouldn't know what resource to point without having a lot more context. And even if I had, I don't feel qualified to properly give you a diagnostic. All I can give is my anecdotal evidence. Most of our development teams apply TDD most of the time. We're working on a mature (5y) enough codebase to have a stable foundation. We do lots of integration testing and our testing is not without issues (it's slow, some of it is flaky, lots of test fixtures that are a pain to manage) but those issues do not come from TDD and are being dealt with piecemeal. The only downside of TDD I've personally witnessed in practice is tendency to write superfluous tests. They either don't test anything useful (e.g. things already guaranteed by types) or leak implementation details. But we encourage developers to improve those tests and the engineering team is overwhelmingly positive that TDD has been a net win for productivity. We try to deploy as much pair-programming as we can and the TDD methodology is specially improved by this. It helps dealing with loose ends from the task description or the technical kick-off and double-checking if the task acceptance criterion makes sense. If one developer of the pair has to take off halfway through, the most important bit is already agreed upon and the code review is much easier later on. Or if the pair-programming starts halfway through, the arriving developer can read the tests to catch up and help make the other tests pass.

And so I have noticed teams and orgs which go for eternity without seeing effective examples of TDD in practice. Is there any resource which might help people like that (includes me?) something that shows TDD in real life scenarios maybe.

runawaybottle 6y ago
There’s a world of difference between writing tests for a rest api endpoint vs other types of pesky code. Too big a difference really. Writing a bunch of tests for your utility methods like a DateFormatter is obvious, but if you shackle up other abstract implementations with tests and strict type checking, you can easily make a piece of unalterable code (maybe that’s the point). The question is, what is the value in doing that? Why shackle up all parts of your codebase when only a few parts are critical? I’ll admit that I also lack (and have lacked) guidance on testing.
villasv 6y ago
I wouldn't know what resource to point without having a lot more context. And even if I had, I don't feel qualified to properly give you a diagnostic. All I can give is my anecdotal evidence. Most of our development teams apply TDD most of the time. We're working on a mature (5y) enough codebase to have a stable foundation. We do lots of integration testing and our testing is not without issues (it's slow, some of it is flaky, lots of test fixtures that are a pain to manage) but those issues do not come from TDD and are being dealt with piecemeal. The only downside of TDD I've personally witnessed in practice is tendency to write superfluous tests. They either don't test anything useful (e.g. things already guaranteed by types) or leak implementation details. But we encourage developers to improve those tests and the engineering team is overwhelmingly positive that TDD has been a net win for productivity. We try to deploy as much pair-programming as we can and the TDD methodology is specially improved by this. It helps dealing with loose ends from the task description or the technical kick-off and double-checking if the task acceptance criterion makes sense. If one developer of the pair has to take off halfway through, the most important bit is already agreed upon and the code review is much easier later on. Or if the pair-programming starts halfway through, the arriving developer can read the tests to catch up and help make the other tests pass.