Imagine living in fucking 2021 and still be writing unit tests. If genius can generate gravity, with those stupid people I bet antigravity exists lmao

In our company we call this freedom. Because only when you do “unit tests” you can do 5 minutes of work and sell them to your PM with 3 hours. And he of course, will sell them as 5 hours to our customers.

So we have exactly 4 hours and 55 minutes free time!

Earth is flat.

When asked in interviews, "Do you test your code?" I say yes because I open a browser and see if the shit works, while I hope to satan they don't bring up unit testing because I STILL don't know what the fuck it is/does/how it works ;)

I write tests for components which are at least 10x larger than a satisfying test set.

What is the alternative? TDD? No tests?

Today I wrote a unit test suite for a 30 line function and it ended up 80 lines, but I caught 3 really tricky bugs in the process and since inventing test cases isn't intellectually challenging I just had to type without pausing for a couple minutes.

And another one, 100 test lines for 20 useful lines, 1 bug caught immediately.

@lbfalvy you have bugs in the first place because of either of these two reasons:
1. Not enough attention was paid to the architecture
2. The programming language you use (or SDK, or framework, whatever you write code in) is too low-level for the task you’re trying to solve

@kiki This implies that in a sufficiently high level language a good architecture enforces a correct implementation such that there's no room for human error, which is a rather brave statement to say the least.

@lbfalvy bitch, when I was a CTO for the first time, I did everything in Clojure with ClojureScript frontend, and we had only three bugs in eight months, all three in JS interop that is technically not Clojure. I don't have to explain shit. If you believe that some automated tests can give you something more than a false sense of security, go on, I'm not gonna stop you. Good luck.

For the better future for yourself, just remember that the whole world of software engineering lies far beyond imperative programming (that's what you do now). If you _are_ willing to learn, and category theory is way too hard, I recommend systems' theory as a more practical approach. Also, there are metaprogramming, DSLs, aspect-oriented programming (that mitigates dependency hell at its core). Do you really think that multi-billion dollar corporations spent ages designing and researching all that just for it to be as effective as just writing some tests? Think again.

@lbfalvy I'm no stranger to TDD. _Any_ proper TDD project that actually has integrity in tests has the full domain area description written in tests alone. From that point, what if we just described the domain area concepts not in declarative tests applied to an imperative language but in a _declarative language_ in the first place? Boom, you've just invented a DSL.

"Any sophisticated C program has a slow, informal, buggy and undocumented LISP interpreter within".

@lbfalvy again, months of coding will save you days of designing an architecture. Sometimes it pays off to spend four years in uni learning computer science.

@kiki Multi-billion dollar corporations still write the majority of their software in procedural languages. I don't know why, my guess is because it's easier to understand and therefore programmers are cheaper and more reliably available, but it could be for any reason, I'm not here to decide what people far more successful than myself should use. Since JS is a fairly big market that doesn't look like it'll vanish any time soon I'm writing my modules in JS. Of course with a type checker because I'm not a masochist.

@lbfalvy say that to Ericsson. Also, _any_ such corporation at least builds its own DSL and writes code in it rather than in raw language. DSL can be built on top of any language, maybe excluding Prolog.

So instead of using automated testing, invent a novel declarative language for your domain?

@hardCoding you mean "to do actual software engineering instead of being a code monkey"?

@kiki that is not all there is to it. A copy paste mistake. Fault in the logic, missed edge case. These are all valid bug cases

@hjk101 “There are two ways of making a software product — the one where there is obviously no mistakes and the one where there are no obvious mistakes.”

When you’re on the right level of abstraction, all that you mentioned and a lot more is instantly obvious because the whole app part signals you of some alien, wrong element of it and nothing works.

Cohesion is a good metric. Unfortunately, it’s a misnomer, and the token is shared between “it’s much easier to do something wrong than to do something right” and “too many parts know too much about each other”. The former is what I’m talking about, the lower the better.

Cohesion is at its minimum when both horizontal and vertical alignment are achieved — you’re coding on the right level of abstraction (vertical) and you’re coding with entities describing the domain area accurately (horizontal).

@kiki coding has nothing to do with it. I can't account for an edge case of I didn't know it was an edge case. If it is still a bug can be debated long and hard but to the user it is. Coffee needs to be always 70°C was the requirement. But due to more insulated macchiato glasses in practice this was too hot for this type.

Silly example but this is how it works. Output is incorrect, no programming language or architecture could have prevented it from being so.

@hjk101 you're wrong, again. I can see a trend here.

In a proper language / system / DSL / whatever, you just do this:

coffee {

temperature: 70C;

}

and it's fucking 70 degrees. That's it. This is the example of how the code looks when you're on the right level of abstraction for your job and your toolchain is designed around your domain area.

You clearly spent too much time writing code in a wrong, bouba way. You're also probably self-taught. It's not inherently bad, just go out there, there's a whole new world waiting for you to explore it. You also probably will delete devRant account because there'll be nothing to _rant_ about.

@kiki sure I'm wrong. But your code serves macchiatos wrong...

@kiki also you don't tell me what to do/will do with my account. You don't know where I'm coming from and it's not related at all to anything. It's just a stupid personal attack. I like to see things a bit broader, we clearly have a different way of seeing things.

I will try to avoid you from now. Hope you can give me the courtesy of doing the same.

@hjk101 I never did, it was merely a joke about devRant having the word "rant" in it. Yes, you are wrong, no need to be so edgy about it.

Matter of fact, you can't even theoretically be in the right when it comes to this topic, because the situation isn't symmetrical — I experienced both your way of implementing things _and_ the right way of doing so, while you merely experienced the former.

"You don't know me" save doesn't work here, as if you were to also experience both approaches, you wouldn't have come up with the arguments you came up with.

You arguing about what you never did is like some guy who only ever did automation in Bash shitting on Ansible when arguing with you. He never tried it, yet he thinks he can argue with you, the guy who used both Bash _and_ Ansible. Same stuff.

@kiki coffe { temperature: 70C } still has the bug, but this code is worse than the procedural equivalent because it comes with a dev with a superiority complex so bad they will claim the customer is at fault for finding 70C coffee too hot rather than admitting their code is doing the wrong thing.

@lbfalvy guess that is the way to bug free code 🤣. Just claim there are non...