I made a <thread> yesterday night :point_down:

# feed

[pablisco]

I made a thread yesterday night 👇

[nfrankel]

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/

[thanksforallthefish]

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

[pablisco]

I guess not everyone read the thread to the end 😅

[pablisco]

As I mention in the thread (for those that read it) it’s not about one or the other. What I recommend personally is to start from the top of the test pyramid (specially with untested projects) which brings the most overall value and then go down to more edge cases for smaller components.

[nfrankel]

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

[nfrankel]

if you want to focus
the integration test vs. unit test opposition is not relevant
you should focus on:
1. business-critical code
2. complex code
how you best test it is imho quite context-dependent

[pablisco]

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

[pablisco]

Furthermore, having only class tests means the code becomes super coupled to tests and hard to refactor

[pablisco]

If you have a piece of code that is fully tested and you extract some functionality to a new class, do you write tests for that new class? Given that the original tests cover the functionality

[pablisco]

as always, it depends. However, from my experience, people focus too much on unit tests that only test classes and tend to lose the bigger picture

[nfrankel]

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

[pablisco]

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

[kqr]

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

[pablisco]

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)