>>109426873
You're definitely either retarded or haven't worked on any big project. Unit tests are useful to verify that new stuff you implement doesn't break anything.

>>109426897
The problem is the way I usually see people talking about unit tests they are completely localized to a function rather than testing anything useful. And then if you want to change something within that module, you now have to change the code, as well as a bunch of tests.

>Unit tests are useful to verify that new stuff you implement doesn't break anything.
Integration and end-to-end automated tests do this. To this day I don't even really know what people mean when they say "unit tests", and the books I've read on the subject are extremely wishy-washy with it as well. They can't even decide on what a "unit" should be.

Do you have an example of an open source project you'd consider to be well tested?

>>109426873
5400+ days, never written or run a single unit test.
just write good code.

>>109426932
NTA but a unit is whatever you've just implemented. It can be a function, a class, a package, doesn't matter. You're testing to see if it actually does what you expect it to do, under the assumption that the rest of your project is working correctly.

>>109426932
How is testing all of the functions of your code individually not useful? It greatly reduces the scope of your testing effort, it's much easier to assert the behavior of your code, and it's less effort to add new ones. Updating tests with changing code is annoying granted, but I don't find myself changing functional code too often and more the code that calls into it. If your project isn't large or serious enough to justify unit tests then don't bother

>>109427031
>How is testing all of the functions of your code individually not useful?
Because you can test higher level mechanisms that rely on those functions, and because you are very unlikely to change any one function, and if you do, you'd have to update the tests for it anyway.

Are your projects 80% tests, 20% code or something?

>>109426932
>Do you have an example of an open source project you'd consider to be well tested?

Llvm (compiler). Imagine working on that without any test, how you would know that your modifications did not break anything?

>>109426932
>And then if you want to change something within that module, you now have to change the code, as well as a bunch of tests.
no, this is rarely the case for unit tests. you're just being retarded.

>>109427169
>Llvm
Thanks, very relatable example...

>>109427207
How so? How are you changing functionality but not the tests that test that functionality?

>>109427031
In almost all cases, unit tests are literally useless code bloat though
>Updating tests with changing code is annoying
and technical debt
>I don't find myself changing functional code too often
I agree, unit tests are almost always useless code bloat and technical debt.

That said, there are exceptions, such as when there is an external specification that is not subject to change, e.g. an IETF RFC, or an ANSI specification, GAAP etc. But otherwise, you will spend more time revising your unit tests because the requirements changed than you will ever recoup from them catching refactoring bugs early.

>>109427235
I'm not. in a real application that is integrated into a wider system and has to respect API specs you rarely change functionality in such a way that breaks backwards compatibility.
and if you're just talking about refactoring, that doesn't happen arbitrarily in a real project either.
we have at least hundreds of tests per microservice and I almost never have to make big changes to existing tests.

on the other hand those tests make sure you don't introduce regressions.
this is especially useful when making dependency upgrades with breaking changes.
in a large application that has grown for years it's impossible to manually check for regressions.
that takes too long and there's nobody around who even has complete knowledge of the application.

>>109427361
if your requirements changing means you have to rewrite tests then you were already testing composed behavior, and not composable units

File: 1782932411999597.jpg (177 KB, 759x371)

177 KB JPG

In my mind, unit tests are only useful if you're writing 'fundamental' code, something like a math library or as someone mentioned above, code that needs to adhere to proper specifications.

In all other cases, you're most likely just writing glue code for those fundamental libraries. For this, I consider assertions, integration tests and end to end tests to be far superior.

It's far more useful to solidify expected behaviour within tests for the purposes of being able to refactor or expand the code without breaking existing use cases.

If no tests exists, nobody wants to touch the old code in fear of breaking shit that most likely everyone forgot was even a use case in the first place.

Code just gets piled on instead of going through more fundamental refactors so soon enough it becomes spaghetti with leaky abstractions.

>>109427436
>he doesn't know
even a single cpu microinstruction is composed behavior though. But congratulations on your nice (albeit transparent) attempt to avoid the issue.

>>109427527
>It's far more useful to solidify expected behaviour within tests for the purposes of being able to refactor or expand the code without breaking existing use cases.
Even then it's far inferior to just single stepping through the code making sure that everything makes sense at every step. As an added bonus, you'll come out of it with an understanding of the code, so that
>nobody wants to touch the old code in fear of breaking shit
doesn't happen, because that situation occurs precisely because people prefer to turn their brains off and abandon the hard work of understanding code. Unit tests gave generations of developers implicit permission to do so, until nobody understands the code anymore and nobody is capable of jumping into old code and doing the work to develop an understanding of it and everybody is somehow comfortable with that situation.

>>109427616
At some point, you cannot feasibly keep all the relevant code and all of the relevant use cases in mind anymore. A lot of shit works implicitly, without you having to think about it.

At some points, you WILL break something without knowing it no matter how well you understand the codebase.

Whether you like it or not, you will have to test the use cases. You can either do it by hand, or turn on the test suite and go relax for 10 min.

I make it a point to not do unit tests and only do integration tests.
If you can't touch the code from the public API and can only test it from the internal API then something is wrong. And testing something in an isolated unit is practically worthless if you actually do the precedent of making them units in the first place. I can promise you the 10 line function called AppendEntryToList(&the list, entry) works 100% of the time and I know this just by reading it without executing it in a test. And I guarantee every branch of it is going to be on the coverage path deterministically every time when I run the integration tests, as designed.s

>>109427641
When did developers become so weak-minded? I've worked on 50mloc C++ projects and there was no place in the code in which I was uncomfortable working. There was only two places in the codebase that had unit tests. This system ran 24/7/365 with thousands of concurrent users in each installation, and was dead nuts reliable. Unit tests do have a place, but there aren't nearly as many of those places as most developers have been led to believe. For the most part they're just a maintenance cost and a way to boost your LOC output if that's what your management incentivizes.

>>109427569
if your requirements are coherent behaviors of single instructions then your unit tests need to be circuit level
i'm not avoiding anything, you are just stupid

>>109427031
>source: my ass

>>109426873
It's only useful for unique cases, something based on configuration / customer configs etc to ensure you don't shit the bed. Outside of that, automated user flow testing is way superior.

>>109427031
Just because something is easy and low effort doesn't somehow automatically translate into it being good.
It's even easier and requires even less effort to not test the code at all. But obviously that isn't good.

>If your project isn't large or serious enough to justify unit tests then don't bother
This feels ironic. The larger the scope and the more interconnections, the less useful unit tests are and them ore useful integration tests are.

>>109429175
>nooo stop pointing out the absurdity of my position
I don't think I will.

File: 78A7BF30-FCB7-446B-8840-5(...).jpg (1.29 MB, 3464x3464)

1.29 MB JPG

>>109426873
>being a codetrans
Just use ai

>>109426873
>>Day
What happened to the Day # getting a CGF?

File: axxnxg.jpg (24 KB, 500x186)

24 KB JPG

>109431195 (You)

>>109426873
Unit tests are to validate the new code you wrote won't break existing behavior.

>>109429150
Were those games? Games are the only scenarios where I see unit tests not being critical.

>>109426873
Testing can be useful but unfortunately it just happens to be the favorite topic of every midwit pseud who sits in some bullshit enterprise coding job thinking about ways to justify his paycheck without ever touching the code that does the useful stuff. 99% of what you read online about testing should just be disregarded. It's one of those cases where you're actually at risk of becoming worse at programming if you listen to these people too much

>>109431476
My former tech lead regurgitated what he read online about unit tests, saying they should be written before the actual code is completed, which is the opposite of reality for practical reasons due to changing requirements. He himself never followed that rule nor anything else he imposed on the team.

code monkeying isnt engineering

>>109429150
t. microsoft jeet

>>109431387
No. Real-time control systems for extremely large industrial facilities.
>>109431640
>everything I don't like is jeet
that's a bit of novelty from the usual
>everything I don't like is jewish
but both sentiments are simply excuses made by the mentally infirm to avoid the effort of actually thinking

>>109431387
There are almost no situations where unit tests are even useful, much less critical. Testing itself is important, but unit tests are by far the least important type of testing. But it's the first form of testing that most people encounter, so baby duck syndrome makes them think it's important.

>>109431271
Cope

>>109432128
Do you do manual testing only? What kind of software do you work on?

>>109432104
>No. Real-time control systems for extremely large industrial facilities.

How do you confirm the software is behaving properly with each update?

>>109432609
Unit tests aren't the only kind of automated test. They are just the least defined kind.

Take a look at this thread. It's clear the unit testers have no idea what they're even talking about.

>>109426873
The LLM just add them for you (even unuseful ones but still)