but unit tests should 100% be the responsibility of the dev making the change.

True enough

A bad test is worse than no test

Also agree, if your org has trimmed to the point that you're just making tests to say you have tests, with no review as to their efficacy, they will be getting what they deserve soon enough.

If a company is going to rely heavily on AI for anything I'd expect a significant traditional human employee backstop to the AI until it has a track record. Not "buckle up, we're gonna try somethin'" track record, more like two or three full business cycles before starting to divest of the human capital that built the business to where it is today. Though, if your business is on the ropes and likely to tank anyway.... why not try something new?

Was a story about IBM letting thousands of workers go, replacing them with AI... then hiring even more workers in other areas with the money saved from the AI retooling. Apparently they let a bunch of HR and other admin staff go and beefed up on sales and product development. There are some jobs that you want more predictable algorithms in than potentially biased people, and HR seems like an area that could have a lot of that.

Why? The developer is exactly the person I want writing the tests.

It's better if it's a different developer, so they don't know the nuances of your implementation and test functionality only, avoids some mistakes. You're correct on all the other points.

The issue with my org is the push to be ci/cd means 90% line and branch coverage, which ends up being you spend just as much time writing tests as actually developing the feature, which already is on an accelerated schedule because my org has made promises that end up becoming ridiculous deadlines, like a 2 month project becoming a 1 month deadline

Mocking is easy, almost everything in my team's codebase is designed to be mockable. The only stuff I can think of that isn't mocked are usually just clocks, which you could mock but I actually like using fixed clocks for unit testing most of the time. But mocking is also tedious. Lots of mocks end up being:
1. Change the test constant expected. Which usually ends up being almost the same input just with one changed field.
2. Change the response answer from the mock
3. Given the response, expect the result to be x or some exception y

Chances are, if you wrote it you should already know what branches are there. It's just translating that to actual unit tests that's a pain. Branching logic should be easy to read as well. If I read a nested if statement chances are there's something that can be redesigned better.

I also think that 90% of actual testing should be done through integ tests. Unit tests to me helps to validate what you expect to happen, but expectations don't necessarily equate to real dependencies and inputs. But that's a preference, mostly because our design philosophy revolves around dependency injection.

I also think that 90% of actual testing should be done through integ tests

I think both are essential, and they test different things. Unit tests verify that individual pieces do what you expect, whereas integration tests verify that those pieces are connected properly. Unit tests should be written by the devs and help them prove their solution works as intended, and integration tests should be written by QA to prove that user flows work as expected.

Integration test coverage should be measured in terms of features/capabilities, whereas unit tests are measured in terms of branches and lines. My target is 90% for features/capabilities (mostly miss the admin bits that end customers don't use), and 70-80% for branches and lines (skip unlikely errors, simple data passing code like controllers, etc). Getting the last bit of testing for each is nice, but incredibly difficult and low value.

Lots of mocks end up being

I use Python, which allows runtime mocking of existing objects, so most of our mocks are like this:

@patch.object(Object, "method", return_value=value)

dependency injection

I absolutely hate dependency injection, most of the time. 99% of the time, there are only two implementations of a dependency, the standard one and a mock.

If there's a way to patch things at runtime (e.g. Python's unittest.mock lib), dependency injection becomes a massive waste of time with all the boilerplate.

If there isn't a way to patch things at runtime, I prefer a more functional approach that works off interfaces where dependencies are merely passed as needed as data. That way you avoid the boilerplate and still get the benefits of DI.

That said, dependency injection has its place if a dependency has several implementations. I find that's pretty rare, but maybe its more common in your domain.

The actual risk of those tests being wrong is low because you're checking them.

If your tests aren't repetitive they've got no setup or mocking in so they don't test very much.

@parameterized.expand([
  (key, value, Expected Exception,),
  (other_key, other_value, OtherExpectedException,), 
])
def test_exceptions(self, key, value, exception_class):
    obj = setup()
    setattr(obj, key, value) 

    with self.assertRaises(exception_class): 
        func_to_test(obj)

@unittest.mock.patch.object(Class, "method", return_value=...)

dynamic_mock =  MagicMock(Class)
dynamic_mock...

I know how to use parametrised tests, but thanks.

Tests are still much more repetitive than application code. If you're testing a wrapper around some API, each test may need you to mock a different underlying API call. (Mocking all of them at once would hide things). Each mock is different, so you can't just extract it somewhere; but it is still repetitive.

If you need three tests each of which require a (real or mock) user, a certain directory structure to be present somewhere, input data to be got from somewhere, that's three things that, even if you streamline them, need to be done in each test. I have been involved in a project where we originally followed the principle of, "if you need a user object in more than one test, put it in setUp or in a shared fixture" and the result is rapid unwieldy shared setup between tests - and if ever you should want to change one of those tests, you'd better hope you only need to add to it, not to change what's already there, otherwise you break all the other tests.

For this reason, zealous application of DRY is not a good idea with tests, and so they are a bit repetitive. That is an acceptable trade-off, but also a place where an LLM can save you some time.

If you’re writing complex mocks frequently, there’s probably room for a refactor.

Ah, the end of all coding discussions, "if this is a problem for you, your code sucks." I mean, you're not wrong, because all code sucks.

LLMs are like the junior dev. You have to review their output because they might have screwed up in some stupid way, but that doesn't mean they're not worth having.

zealous application of DRY is not a good idea with tests

I absolutely agree. My point is that if you need complex setup, there's a good chance you can reuse it and replace only the data that's relevant for your test instead of constructing it every time.

But yes, there's a limit here. We currently have a veritable mess because we populate the database with fixture data so we have enough data to not need setup logic for each test. Changing that fixture data causes a dozen tests to fail across suites. Since I started at this org, I've been pushing against that and introduced the repository pattern so we can easily mock db calls.

IMO, reused logic/structures should be limited to one test suite. But even then, rules are meant to be broken, just make sure you justify it.

also a place where an LLM can save you some time.

I'm still not convinced that's the case though. A typical mock takes a minute or two to write, most of the time is spent thinking about which cases to hit or refactoring code to make testing easier. Working with the LLM takes at least that long, esp if you count reviewing the generated code and whatnot.

LLMs are like the junior dev

Right, and I don't want a junior dev writing my tests. Junior devs are there to be trained with the expectation that they'll learn from mistakes. LLMs don't learn, they're perennially junior.

That's why I don't use them for code gen and instead use them for research. Writing code is the easy part of my job, knowing what to write is what takes time, so I outsource as much of the latter as I can.

I use it for writing code to call APIs and is a huge boon.

Yeah, you have to check the results, but it’s way faster than me.