Confession: In my almost 10 years of professional dev experience, I have never written any kind of units tests for my code. Ever.

I haven't done much unit test as I feel I should've done. But there's always time to learn and improve.

Bad. Just... Bad.

I really wouldn't like to work with you.

Agreed, i wouldn't want to work with you either.

I don't write unit tests either because the work to mock up every little piece of crap just doesn't provide enough added value. Or, if the mockup is easy, then the tests are trivial and don't yield information.

Even worse, the unit test work required when the code changes dwarfs the actual code change, which in reality leads to architecture rot because nobody has the time to refactor when refactoring takes four time as long as needed.

Also, they just aren't good when the point of the code isn't computation, but behaviour. That needs integration and system level tests where shit is linked to actual business requirements.

At code level, I prefer code reviews, and I tend to find bugs that no test would have revealed because they're corner cases that would only manifest under exceptional circumstances. I can review code with the mindset of "what has to happen to break this code here".

Integration tests are essential. Unit test are mostly useless, and even counterproductive when you later want to change the code.

Use best judgement.

this rant has a vibe like an alcoholics anonymous meeting

@PublicByte absolutely not! You're comparing a quality-measuring tool and a style.

IMO not testing your code is like building a house without any structural tests of the walls. Can be done. Can hold. But I won't live in there.

You cannot be serious about some software if it has not been tested. "It works on my machine" or "I made manual tests, trust me it works" are sentences for side projects or junior developers.

But I agree, that doesn't mean you have to unit test everything. There's a balance to find.

@react-guy How exactly would you do structural tests of walls? I've never seen that at construction sites. Houses are built as per static calculations which can and should be double-checked.

I wish I have your guts, laziness or awesomeness. Whatever it is I'm amazed.

Isn't something that is well tested before production. Is better then to panic all over when it broke in production.

That is where hell let loose?

The best way to test all functions, is via unit testing. Though i do agree. When refactor codes junit has to be amended.

But in the long run, it would be worth it? agree?

@matwx All the work I have done is not of absolute critical importance. If something breaks, the business does not lose money, we dont drive away customers. We have had stuff broken for weeks and nobody tells me. I do my diligence before deploying but in the end I'm not going to write test for code that has no written requirements and can be broken and nobody cares.

@BobbyTables

Then is probably fine. The stuff i wrote are critical. But junit practice isn't in place.

It really depends on the organization.

I do get clients screaming all over the place.

@PublicByte "I'm not doing it because I saw projects that do it badly. So it's obviously always bad."

Hmmm, what can be wrong in this thinking... 😅

@PublicByte well that's what your comment made me think 😊

@PublicByte their developers must think they are like God or their job is unimportant. "Hey, let's just go straight to testing in production. It's just movies." :D