3 ms·

This has been rehashed a million times. My view is that TDD is great for non-explorative coding. So data science -> way less TDD. Web APIs -> almost always TDD

This has been rehashed a million times. My view is that TDD is great for non-explorative coding. So data science -> way less TDD. Web APIs -> almost always TDD. That said, one of the things I think the vast majority of the leans anti-TDD crowd misses is that someone else on the team is picking up the slack for you and you never really appreciated it. I've joined too many teams, even great ones, where I needed to make a change to an endpoint and there were no functional or integration tests against it. So now I'm the one that is writing the tests you should have written. I'm the one that has to figure out how the code should work, and I'm the one that puts it all together in a new test for all of your existing functionality before I can even get started. Had you written them in the first place I would have had a nice integration test that documents the intended behaviour and guards against regressions. Basically I'm carrying water for you and the rest of the team that has little to do with my feature. Now there are some devs out there that don't need TDD to remember to write tests, but I don't know many of them and they're usually writing really weird stuff (high performance or video or whatever). But I have stopped concerning myself with changing other peoples minds on this. Some people have just naturally reactive minds and TDD isn't what they like so they don't do it.

randomdata 4y ago
I find the opposite. TDD is great when you don't know what your program should look like. It gives you an opportunity to simulate how the program will be used on the outside, able to be quickly iterated upon until satisfaction, without having to write all the laborious internal code (often over and over again when exploring without TDD). Once you are happy with the result, then you just have to back and fill in the guts once. If you know exactly what you need upfront, you can simply start coding, adding a sprinkling of acceptance tests to help catch mistakes. No need for TDD in that case.
- 3pt14159 4y ago
  Really? When I get to a new database and don't even know what data is stored where I don't write a test first. I write a bunch of SQL scripts and then maybe take it into a python toolkit for stats stuff. When training a classifier and having to choose things like dimensionality I find that exploring what the dimensions actually express teaches me more about the dataset and the approach faster than starting with a test. Sometimes I don't even know what opportunities are in the data that I'm going through, so how would I even express the test? That said, I'll try it your way next time and see how it goes. If it works for you maybe I'll learn how to make it work for me, since I love TDD. As for knowing exactly what you need upfront, why start coding? Why not do TDD? I find the interfaces are more naturally expressed as the consumer than the implementer. I rarely find myself writing unnatural interfaces when starting with the test, and by starting with the test it makes abstractions that must be faked / mocked easier to slide into the code that implements the feature without too much damage to the rest of the codebase. I avoid them whenever possible, but sometimes a network call must be mocked and it's better to do so with minimal collateral damage.
  - randomdata 4y ago
    > I write a bunch of SQL scripts and then maybe take it into a python toolkit for stats stuff. That sounds a lot like a test (or set of tests). It would appear that you are already doing something akin to TDD, although perhaps without the formality of turning your exploratory work into documentation for other developers to read about what you learned. > Why not do TDD? I find the interfaces are more naturally expressed as the consumer than the implementer. If exploration is necessary to find the right interface that may be worthwhile, but I find when the requirements are well defined the interface is obvious before writing either tests or implementation. It may be still worth writing unit tests up front, but it is not testing that is driving your development. The requirements are driving your development in that case.

randomdata 4y ago

I find the opposite. TDD is great when you don't know what your program should look like. It gives you an opportunity to simulate how the program will be used on the outside, able to be quickly iterated upon until satisfaction, without having to write all the laborious internal code (often over and over again when exploring without TDD). Once you are happy with the result, then you just have to back and fill in the guts once. If you know exactly what you need upfront, you can simply start coding, adding a sprinkling of acceptance tests to help catch mistakes. No need for TDD in that case.

3pt14159 4y ago
Really? When I get to a new database and don't even know what data is stored where I don't write a test first. I write a bunch of SQL scripts and then maybe take it into a python toolkit for stats stuff. When training a classifier and having to choose things like dimensionality I find that exploring what the dimensions actually express teaches me more about the dataset and the approach faster than starting with a test. Sometimes I don't even know what opportunities are in the data that I'm going through, so how would I even express the test? That said, I'll try it your way next time and see how it goes. If it works for you maybe I'll learn how to make it work for me, since I love TDD. As for knowing exactly what you need upfront, why start coding? Why not do TDD? I find the interfaces are more naturally expressed as the consumer than the implementer. I rarely find myself writing unnatural interfaces when starting with the test, and by starting with the test it makes abstractions that must be faked / mocked easier to slide into the code that implements the feature without too much damage to the rest of the codebase. I avoid them whenever possible, but sometimes a network call must be mocked and it's better to do so with minimal collateral damage.
- randomdata 4y ago
  > I write a bunch of SQL scripts and then maybe take it into a python toolkit for stats stuff. That sounds a lot like a test (or set of tests). It would appear that you are already doing something akin to TDD, although perhaps without the formality of turning your exploratory work into documentation for other developers to read about what you learned. > Why not do TDD? I find the interfaces are more naturally expressed as the consumer than the implementer. If exploration is necessary to find the right interface that may be worthwhile, but I find when the requirements are well defined the interface is obvious before writing either tests or implementation. It may be still worth writing unit tests up front, but it is not testing that is driving your development. The requirements are driving your development in that case.