[hotpocket777]

_in your opinion_

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.

[stouset]

> 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?

[1123581321]

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.

[stouset]

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.

[1123581321]

Yes, exactly so.

[hotpocket777]

> This is just about the most bizarre take on unit testing I've seen in my 25-year career.

Lol ok

> you are entirely defeating the point of testing

We will disagree here

> only assert that the current implementation is equal to the current implementation

I didn’t state that I do this

[ansisjxbbx]

This is domain specific, but for most web apps

> 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.