Two real reasons people write unit tests:
- mommy’s boy can’t even fart without mommy’s approval, but instead of mommy, there are unit tests now
- Stockholm syndrome

Not sure what you mean? Unit tests are good to have around when you're refactoring or changing code. In case of TDD even before you have written the code, like a set of specifications you know have to hold up once the code is done.

@kiki I was writing a little expression parser recently, my own project, not work related. And before the main code was done I wrote unit tests for all sorts of edge cases and formats it needed to pass.

It helped a lot, mostly because I thought of edge cases early and knew how yo approach the final architecture better.

It's not valueless, maybe you used it wrong at your job, I worked at a place that used unit tests to essentially tested mocks and nothing else... But when done right It's like automation for manual testing through a debugger...

@Hazarth https://devrant.com/rants/4607192/... comments. I'm not gonna explain it all again

@kiki ah ok. Neat. Your logic is incredibly flawed.

Your entire point is "You don't need tests if you, and everyone else involved, is perfect"

Which is true, I agree and im glad you work in a perfect environment and that you yourself are perfect. Must be nice

So... what testing do you do? Are you advocating scrapping unit testing but keeping integration testing / UAT etc.? Or is all such testing bad?

@AlmondSauce testing? Just build it in prod 🤷‍♂️

Obviously that's the only way forward now.

@C0D4 Yeah...

I'm curious as to the logic more than anything else. There are occasions when unit testing is basically impossible - working on a large, monolithic codebase for instance that has everything crammed into a few classes and methods. You can't really test anything as there's no real units to test. In that case large scale, thorough integration tests are kinda the best you can do without heavy, often impractical refactoring - but I don't think that's the point that's being made here somehow.

In all other cases, the only people I've met who think unit tests are a waste of time are people who've never written them properly, or at all.

@Hazarth have you ever worked with a Turing-complete declarative language? Even if it was prolog.

@atheist the first good answer, hallelujah!

I can almost smell taming legacy code from what you've written.

https://devrant.com/rants/4752097/...

@atheist “if you use dsl, your product is the dsl, not the code” argument is flawed. Everything maybe except for assembly is a dsl of some sorts. If I use a headless CMS solution with one of its domain-specific entities being the user, according to your argument, I’m better off testing the CMS rather than the code I write that uses its entities. Sounds wrong to me.

Our language lists are uncanny similar. The only difference for me is Swift instead of Objective C and Clojure instead of OCaml.

Argument about “just constructs” is your basic “X is just Y” argument that is inherently flawed. I also never mentioned functional programming because it’s still imperative in its core. The way you’re presenting different languages like a matter of personality preferences is misleading. Languages aren’t created equal, and it’s much easier to make a mistake using language that just doesn’t fit the task.

@atheist oh I heard about it but forgot what the name was. Thanks

@atheist it’s not an abstraction if you can’t go lower

@atheist thanks, but I don't quite understand what you're trying to say. Declarative good? Declarative bad?

Declarative is different. One thing I know is that it's easier to do this

coffee { temperature: 70C }

than this:

if (coffee.temperature >= 70) return

coffeeHeater.start()

coffeeTermometer.on('change', function measure (e) {

if (e.temperature < 70) return

coffeeHeater.stop()

coffeeTermometer.off('change', measure)

})

@atheist
heater is undefined
heater has no member called is_on
coffee is undefined
coffee has no member called temperature
is_on is not assignable to boolean

> coffee.temperature
true

Disagree.

In fact, I've had scenarios where a change triggered by one requirement broke something else, caught by unit tests; and once there was an 8 hour outage, thanks to me not running unit test, someone had skipped them in the build scripts, and I didn't test one particular scenario. Funnily, unit tests were actually failing, and it would have been caught had the tests been run.

@BugsBuggy e.g. "bad and cohesive imperative code was saved by unit tests"

Maybe because that's the whole point?

My point though is writing declarative code that doesn't fucking crash every 5 minutes if left alone in production

@kiki you didn't get my point

Okay, so there's a requirement, and we build a microservice for it.
There's another requirement that is quite similar to the previous one, with 90% similar codebase, hence we decided to keep it as a common microservice.

Now, a change in the previous one, broke a functionality in the newer one. The code doesn't need to be bad for something like this to happen. A simple careless developer error, a human mistake, can happen.

@BugsBuggy that's why DRY as-is sucks at scale. Spoiler alert: the whole concept of aspect-oriented programming was invented to tackle this fundamental problem in imperative code. Google it.

@kiki your statement is so complicated man

@kiki okay, just curious.
How do you want to make sure that a change in a feature will not break some other feature?
(one application might serve multiple features even as microservices)

@BugsBuggy you want to turn your codebase from a single-dimensional thing to a double-dimensional one, literally. It may sound complex but was famously solved in Lisp with a bunch of macros and that costed Java a lot of mockery back then. Just read the wikipedia article bro

https://en.wikipedia.org/wiki/...

Although I still think UTs should be there, specially for large features, but this whole AOP thing looks interesting.

Apparently, I've done some of it, like metrics and all...
Yet to use it with something regarding business logic.

@BugsBuggy man, not even learning new paradigms but just reading about them is what I consider one of the most valuable time investments when it comes to professional growth

@kiki I just shared a blog explaining AOP to my team's channel.

Third reason:
I don’t trust the idiots I work with to not break everything.

@Root in Code Complete, Steve Mcconnell strives to define a medium where errors are impossible. Np matter what you do, you can't produce an error — language or toolchain just doesn't allow it.

If adopting a declarative language as-is is not possible, I think state machines would be the optimal approach instead of tests, where your linter would just compute every possible state transition and trivially catch impossible ones.

@kiki Defensive programming (and designs) are great and all, but you don’t need to produce an error to produce incorrect output.

Also, how about dealing with user input?

Or how about someone changing either the name or interface of a class/module that my code relies upon?

@Root as we say here in Russia, "idiot-proof systems only deter _lazy_ idiots". (Защиту от дурака придумали, а защиту от долбоеба — еще нет)

when it comes to user input, only a runtime solution is applicable, so tests are useless here

@kiki What are you talking about? It’s easy to write specs to check your code against various bad cases. Input too long, wrong formatting, unexpected characters, bad nesting, whatever.