I'm so sick of "senior/lead" developers pretending they know how to write tests and ending up with these unmaintainable test suites, full of repetitions and incomprehensible assertions.

You should take some time to learn from your mistakes instead of just continuing to write the same shitty tests as usual!!!

Every time I arrive at a new team I spend weeks just trying to understand the test suites for what should be fairly SIMPLE applications!

UNIT TESTS SHOULD TEST UNITS OF CODE!
If your unit test tests seem to be repetitive, they are not unit tests. Repetition is expected in integration tests, but that is why those are usually DATA DRIVEN tests!!!

my experience has been that "unit" tests are often not worth testing/keep maintaining for since you rarely get these units wrong. It's when these units are put together when things screw up.

A better alternative is to not do TDD unless you have someone dedicated to writing tests.

Good rant OP. I'm too tired to engage properly but agree.

Pairing and mobbing helps

@aviophille make time as it will save it if you're doing it right

@jestdotty yeah that's my experience with it as well. But once it's done, it's rare that such units need changing.

Whereas the integrations is where we make most changes around and actually would benefit from having tests that are maintained (whether it can be done well is a different story)

y'all write unit tests?? ughh what a waste of time.

I don't understand the hate on testing and tdd here.

I've been using it for years and it's absolutely, hands down, bar none, the best way to develop in my experience.

@lungdart It’s twice the work. That may work in large teams, but when you’ve only got one or two devs, it’s hard to justify the lost time.

@cuddlyogre hard disagree. TDD had always saved me time, and saved my team time.

It's 1.5x the code, 25% of the debugging, and 10% effort to maintain and refactor. So much time is saved.

I've been on large and small teams. Jr, sr, devops, architect, backend, embedded, and network automation. I've never been slowed down by testing.

@lungdart And if you don't have a team and have paying work waiting to be done?

How do you justify to clients and managers a wholly optional expenditure of time that has no immediate benefit?

@cuddlyogre because it does have an immediate benefit. Look at my comment above.

@lungdart I see no benefit to spending almost double the amount of time doing something purely optional when clients are waiting and problems need to be solved. Depending on the project, that easily delays delivery by weeks. In a competitive market like this one, how can anyone get away with that?

If you have a dedicated guy that writes tests, then go for it. When you're one/two guys barely keeping up, forget about it.

@jestdotty I'll need you to define testing then, because the idea of just pushing code without making sure it works sounds horrifying to me.

I don't use rspec but I do test the code with the console as thoroughly as I can fathom at the time. I'll even add comments before the function describing implementation details and other usage notes. Everything is right there. There's not a second shadow application that also needs to be maintained.

I see a lot of senior/lead stuff in rants lately. Seems that either is a meaningless title or assumptions are made on it.
This rant would have been the same if it was just '"developers" imo.

Anyway I almost always do table driven tests. Still that often does end up with a lot of repetition. For a lot of tests it's the same data with a slight variation. This is fine and explicit. Of course when there are swats of data creating a fixture that is slightly altered reduces meaningless duplication that detracts from readability.
Don't see how e2e and integration tests are different in that regard.

I usually follow the guideline: if the tests don't enlighten how the subject is supposed to be used you are doing it wrong. So always start with the happy flow(s) and then the most common mistakes/failures. Test input/output should be close to or documenting real world values.
If you need to test for weird random data cases, write a separate test that does fuzzing. That's what it is for.