[orwin]

I'm pretty sure you ought to make the tests you think are needed, and the 'form' is not a good metric.

Our libraries with a lot of logic and calculations are dominated by unit tests, our libraries that talk to external API are dominated by integration tests. That's just good testing, I'm not sure you need to imagine a pyramid or a vase to decide the tests you do.

[diggan]

People are addicted to metrics, so when "code coverage" becomes something to measure, people tend to go crazy with the testing, even trivial stuff that doesn't really need to be put under tests.

My personal rule of thumb is something like: If it makes you go slower, you're doing too little/much testing, if it makes you go faster, you're doing the right amount of testing.

If you find yourself having to rewrite 10% of the code base every time a test changes, you're probably doing too much testing (or not treating your test case as production code). If you find yourself breaking stuff all over the place when doing other things, you're doing too little testing.

As most things, it's a balance, too extreme in either direction will hurt.

[OJFord]

That probably works well when you've already established a good baseline, but when tests barely exist (or greenfield) or they're crap, I find it can be a real slowdown to try to test something you know you should.

Especially if there's something not entirely straightforward about it, like you need to figure out a way to instrument/harness something for the first time so that you can actually test against it. (Arguably inherently doesn't happen with unit tests though I guess.)

[diggan]

> like you need to figure out a way to instrument/harness something for the first time so that you can actually test against it

Indeed, and sometimes it's not worth to figure out, but sometimes it is. For example, if you have a piece of code that haven't changed since the beginning, and there been no bugs stemming from that code, adding tests to it is kind of futile unless you already know it has to be refactored soon.

On the other hand, if you join a existing project with almost no tests, and for the last N months, that code is responsible for introducing lots of bugs, then it's probably worth it to spend time building some testing infrastructure around the project with that part first up to be under lots of tests.

Basically, if the calculation shows that you can save more time by not having those bugs, you have some budget to spend on making the tests work well for that part.

[anymouse123456]

> I find it can be a real slowdown to...

Not OP, but this is the vibes approach I often use (and believe they're advocating for).

If it feels painful to add a new test, it's likely time (or nearly time) to make adding tests, or at least that test easier.

I've found that once it's easy to add tests, new tests often start appearing, so that first effort can be some of the most high-impact work available to me.

[cogman10]

Completely agree.

I think the problem some devs want hard and fast rules when a lot of the time the right answer is "it depends" and experience dictated actions.

[anymouse123456]

The thing that frustrated me as a new player, was that there often seemed to be two opposing poles and neither were very helpful.

There is the dogmatic rules crowd (triggers my self-diagnosed opposition defiance disorder), and the "it depends" crowd, which left me screaming, "ON WHAT?!"

When I was in this position, I found Kent Beck and Martin Fowler's notion of "Code Smells" [0] really helpful. Though admittedly, the comprehensive enumeration with associated Refactorings was probably a bridge too far.

"Code Smells" lean toward the "it depends" vibe, but with just enough structure to aid in decision making. It also bypasses my inflexible opposition to stupid rules in stupid places.

I try to frame too much or too little testing as a Code Smell and discussing it that way often (not always) leads to reasonably easy consensus related to what we should (or shouldn't) do about it.

[0] https://martinfowler.com/bliki/CodeSmell.html

[cogman10]

> which left me screaming, "ON WHAT?!"

The on what is context and situational dependent. Heck, there's even an aspect of personal preference in there.

From the perspective of a code smell, it's very similar to real life smell. Garlic is an awesome ingredient and in the right context, like a good Italian dish or pizza, it's the thing that makes you go "mmm". However, if you are making oatmeal or a desert, garlic is probably the last smell you want.

Code smells are much the same way and, like garlic, people will disagree on what is a code smell and good coding practice. While there are some smells that are somewhat universally despised (such as raw sewage) there are others that can be arguably good or bad based on context or preference.

To pull this out further, a common code smell is "long methods". Yet, if you are writing something like a parser or a CPU emulator, then a giant switch statement is really going to be the right thing to inject at some point even though it might create a 1000 line monstrosity method.

Martin acknowledges this in his essay.

> ... smells don't always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there - smells aren't inherently bad on their own - they are often an indicator of a problem rather than the problem themselves.

This where I think the correct position to take is just going to be "it depends" with an understanding that even if something isn't your preference it might be someone else's. Today's best practice has a nasty tendency to turn into tomorrows code smell. Being aware of that fact will help you not to quickly jump to conclusions about the state of a code base or the competence of it's devs. You might even learn something cool about what you can do by breaking the rules/smells/dogma.

I know it can be frustrating, but really a lot of this just comes with experience and humility to know you and everyone else won't always be right about everything. There's no high priest of good code.

[blueflow]

Yeah, its the "model" that is outdated. Not the testing itself.