My company had what was at the time one of the largest Slack enterprise contracts. You have no idea what internal corporate battles we had to face to get our higher-ups to take us seriously at every stage of adoption, and ultimately roll it out en masse. Slack succeeded in enterprise in spite of its name, not because of it. The actual product was phenomenal, relative to alternatives.
Yes, when you have the notoriety, distribution, and reputation-for-insults that Linus does, you can get away with things like that, because you're selling into a culture that already understands the "joke".
My opinion is, _my unit tests_ are to protect my code against unwanted changes. To that end, unit tests test a single unit. And everything is mocked. If I have to rewrite a method, usually I rewrite all of its unit tests. Which is fine. They’re easy to write or rewrite.
Fully mocked unit tests are then supplemented with fewer “full stack” tests higher up the pyramid.
> My opinion is, _my unit tests_ are to protect my code against unwanted changes.
This is just about the most bizarre take on unit testing I've seen in my 25-year career.
> If I have to rewrite a method, usually I rewrite all of its unit tests.
If you have to rewrite your tests every time you rewrite a method, you are entirely defeating the point of testing. What value you get from tests that only assert that the current implementation is equal to the current implementation?
You seem confused about what he was saying. I’m sure you are familiar with unit testing philosophy with your experience. Calling a function and expecting a response does test the behavior of the application, just at a lower level than a request- or multi-request level spec. When he says rewriting a method he is referring to changing the logic of it; a refactor leaves the tests unchanged. That shouldn’t have needed to be spelled out to such a senior developer.
Tests should not generally need to be rewritten unless you’re changing the externally-visible behavior API of a function or library (either the literal API, its effects, or its semantics).
If you’re changing the tests because you’ve changed the internal, non-externally-visible logic of your code, your tests are almost certainly providing you negative value.
Being able to refactor and re-run your existing test suite to ensure consistent behavior is possibly the important property of a good test suite.
> Fully mocked unit tests are then supplemented with fewer “full stack” tests higher up the pyramid.
Has the wrong priority. Full stack tests are the most valuable for shipping working software. Tests are enforcing contracts between components. Often I’ll see unit tests written for cases that do not exist. This is very bad. Testing at the boundary of your stack ensures the contracts that matter are enforced. Everything else is just making devs wonder “is this requirement actually real?”.
I used to be big on unit tests until I had to maintain a codebase for more than a couple years. I still use them, but mostly out of laziness.
