Senior Software Engineer at Noom, formerly Team Lead Engineering at XING. I intend to write about functional programming and occasionally some random engineering topic.
I'm of the opinion of DHH, that there's a lot of test-induced damage caused by TDD.
These days I almost never write unit tests anymore, I've almost completely replaced them with integration tests, as suggested by Kent C. Dodds. As I work on the backend with Kotlin, I use test-containers to spin-up the DB, RabbitMQ or whatever, and then test the app as if it was a function (hitting an endpoint and asserting the response, for example).
One of the biggest advantages to doing this is that the tests are completely decoupled from the code (which you typically get when you use mocks), so you can refactor freely and all you have to do is run the tests to see you haven't broken anything.
When you do these sort of tests, TDD doesn't apply much anymore because you often need to connect a few components before you can actually see a result, so the "write a failing test, fix it" iterative process doesn't fit.
One question I often get when someone sees this approach for the first time is, what do you do when the system under test has a lot of variations? For those cases, I've found that a table-driven approach has always worked well. I've found that the amount of permutations you'd write if you were unit testing would pretty much be the same, if not more as some tests from other layers might overlap.
I'm of the opinion of DHH, that there's a lot of test-induced damage caused by TDD.
These days I almost never write unit tests anymore, I've almost completely replaced them with integration tests, as suggested by Kent C. Dodds. As I work on the backend with Kotlin, I use test-containers to spin-up the DB, RabbitMQ or whatever, and then test the app as if it was a function (hitting an endpoint and asserting the response, for example).
One of the biggest advantages to doing this is that the tests are completely decoupled from the code (which you typically get when you use mocks), so you can refactor freely and all you have to do is run the tests to see you haven't broken anything.
When you do these sort of tests, TDD doesn't apply much anymore because you often need to connect a few components before you can actually see a result, so the "write a failing test, fix it" iterative process doesn't fit.
One question I often get when someone sees this approach for the first time is, what do you do when the system under test has a lot of variations? For those cases, I've found that a table-driven approach has always worked well. I've found that the amount of permutations you'd write if you were unit testing would pretty much be the same, if not more as some tests from other layers might overlap.
Another good article on the topic that describes well the philosophy: blog.twitter.com/engineering/en_us...