[Existenceblinks]

My best testing practice is writing tests as needed based on instinct. YES. I can feel it when a function needs test or not. It will hint by giving a little anxiety on expected result of that function. And I don't care 100% coverage anymore.

[TravHatesMe]

But this approach doesn't scale. How can you expect everyone to have this intuition? Agreed that 100% coverage is stupid.

[Existenceblinks]

So currently there is no any approach that scale at all. Everyone will write test differently.

And that's why we have code review process, and senior software engineers?

---

EDIT: add an example

When you look at a body of function and think if someone else changes some codes and you will have a hard time figuring out what goes wrong, that, the time you need to add some tests to it. Often it's a function that took numbers of iteration to work as you expect, or a function that is not simple but look so easy you write it right in one go.

[devoutsalsa]

I’ve never seen an approach that scales. Once a team passes a certain size, it all turns into a disorganized shit show. Communication is hard, and as the pressure to earn revenue intensifies, there’s less & less time or buy in for craftsmanship.

[Existenceblinks]

Yep, true. I'm really familiar with the vibe of time-to-market vs not to fuck customers up. Modules that are directly related to values to customers get more tests.

[notepalf]

Why is 100% coverage stupid? I agree that there could be configuration or data classes that does not make sense to test, so these could be ignored by the coverage tool. Is it still stupid to aim for 100% coverage in the rest of the relevant not-ignored code?

[falcolas]

100% coverage as a measure of success is stupid.

And (this gets into personal opinions) sacrificing depth on tests on critical codepaths in order to spend time getting to 100% coverage is also stupid.

Time is finite. Money is finite. 100% coverage provides nothing but false assurances and pretty green metric lights.

[necovek]

100% coverage measured by lines of code being hit is actually insufficient for proper test coverage (which is what most, if not all tools that measure code coverage do).

It's easy to get "100% code coverage" for the below function:

  def nths(number: int, divisor: int) -> float:
      return number/divisor

  def test_nths():
      assert nths(1, 1) == 1

Yet it's obvious that test is not really taking care of anything.

What you need is 100% semantic coverage, i.e. your tests should cover all potential outcomes of the code at appropriate levels.