I made a thread yesterday night 👇

keeping the car analogy, unit testing is testing each nut and bolt and believing it’s sufficient on the other hand, integration testing is leading your car on a test drive does it make sense to do that without having tested each nut and bolt? full rant available here: https://blog.frankel.ch/unit-test-vs-integration-test/

isn’t single class vs feature test a matter of DRY and reduce duplication? or maybe, because that is where I am struggling, how can I have unit and feature testing without executing the same production code twice? should my production code being buggy (ofc, never happened to me but I hear is a possibility 😛 ) or should I need to change some logic, how can I avoid having now to adapt 2 tests? ideally I would like test coverage to be comprehensive but not redundant, and it is the redundant part that makes doubt the value of single class tests

I guess not everyone read the thread to the end 😅

i did read the thread to the end and it ends like this:

If we concentrate on gaining coverage by using unit tests only, we end with many tests that often don’t test much. There is a finite time we have to spend on testing. We should focus on the bigger picture and then go down to specifics if we want extra confidence.

what i understand: focus on integration tests if that’s not what you wanted to express, you’d probably want to rephrase your thread

Well, at no point I say to not do Unit tests, only that there is more value on integration tests so we should focus on those first and then go to more specific complex parts of the code

that’s one of the reasons why twitter is not a great medium to convey subtle thoughts i’d advise to have your blog and use twitter to link to your posts

That’s true 😅 I need to finish up my blog hehe. One of these days

does this boil down to test of API vs test of implementation?

It’s not really an A vs B situation. The fact that Unit and integration vary widely depending on the stack doesn’t help. It’s more about how do you get a good balance of value (in terms of code and logic paths covered) vs speed. The move internal components (in a module) that tests cover, the easier it’s going to be to refactor the implementation. If you have tests that verify that the production code calls a certain method in a colaborator and tha’s it you are going to have issues changing that implementation. i.e.: In an ideal world, we should only have to change tests if the requirements of our code changes, not when we change the implementation. In reality we have to change when dependencies change their APIs, although, supporting a new version of a dependency could be seen as a change in requirements (ish)