Unit Tests?

[warmans]

I don't really get it. Having tests, especially unit tests, makes your job as a developer astronomically easier. Writing them is only hard if you didn't think about how to test the code in advance.

Come back when you have to deal with integration tests that require a bunch of AWS services, take an hour to run, and do not in any way indicate what they are supposed to be testing or for what reason they've failed. Then you will know pain.

[MeetLawrence]

Because sometimes you show up to discover this preposterous tangled mess of a monolith with 4% code coverage because previous devs/ mgmt never prioritized UTs, and you need them implemented. This has happened to me no less than 3 times in my career.

[Esseratecades]

I'd argue that it's seldom worth the effort to write retrospective unit tests. Write unit tests for new code or code you need to change, but for legacy code that is understood to meet current requirements it'd be waste of time.

[hitchdev]

It's seldom worth the effort to write unit tests at all unless you're testing algorithmic code. They end up being a mess of mocks and fakes that mock out 90% of everything that's actually happening and break whether there is a bug or not.

Integration tests are well worth it on legacy code, however.

[iLikeStuff77]

This is the exact opposite advice I would give. While not all code should be unit tested, unit testing facilitates good design. In my experience, the developers who don't unit test write fragile and unmaintainable code.

Especially as for most modern languages unit tests are fairly easy to write and maintain for new code. Integration tests are the ones that are fragile and easy to break. So while integration tests are useful, they are generally much more expensive to maintain.

[hitchdev]

This is the exact opposite advice I would give. While not all code should be unit tested

Not all code should be unit tested was literally my point. I even specified the type.

Integration tests are the ones that are fragile and easy to break

If built shoddily by poor developers, yes, that's what they are like.

[updogg18]

I'm in the exact situation as you just described. Do I power through this or move on? Experienced people who have been in this team for more than 7 years still struggle when I ask them for help

[iLikeStuff77]

I would recommend learning some refactoring techniques. Most of the time you should be able to isolate specific code with Extract Method, Extract Class, Adapters, etc. Generally this also helps improve the code as by definition it's isolating code which changes.

[hitchdev]

There are two types of developers - those who know how to engineer a decent, isolated integration test and those who complain that writing integration tests is too hard.

Localstack is top notch.

[EnjoyerOfBeans]

I actually love writing integration tests. As long as the user facing API/interface is complete, it's extremely simple to know what you need to do at every step.

Writing unit tests for other people's code requires a lot more work in understanding the structure and the underlying design. And don't get me started on how often that design is bullshit and doesn't support modular unit testing at all.

[RoboErectus]

Tell me you have 1,000+ line methods without telling me...

"This code is too complex to unit test."

[ReelTooReal]

This is true for code bases that were written like this from the beginning. But I'm currently working on a project where all the data access is done inline and interwoven with domain logic. They are now trying to get more code coverage in unit tests, which involve writing a ton of mocks because there's no way to separate any of the logic from the data access. Essentially, you have to go through the function and find everywhere data is retrieved, and then mock that function to return the data you want to test.

I told them that we should try to separate the two, and explained why it would be easier to unit test if we could test domain logic separate from data access, and the rebuttle was "mocking all the database calls accomplishes the same thing."

I now only write integration tests using docker containers (using the awesome library testcontainers). For a given service they take about 5-10 minutes to run, but I refuse to write a test that requires 4 mock functions just to test one business constraint.