loading...

To test or not to test, is that even a question?

lvrbrtsn profile image Levi ᕙ(⇀‸↼‶)ᕗ ・2 min read

Frankly, it blows my mind that this is even a discussion. I am not sure how much I can really write one this topic, because my views really boil down to this...

Why the fuck are you not testing your code?

Do you like learning you broke prod?

Do you enjoy being afraid to tackle a bug because your not sure how that class really even works?

Do you like having to train any newbie for months before the feel comfortable committing?

Do you need to do TDD? BDD? MKBHD? No, I don't give a damn, but if you code professionally and don't write tests of any kind you are doing yourself and your team a dis-service so severe it could destroy the project in the long run.

If your boss is the reason you don't test quit, seriously quit that job because you will end up hating it in a few months anyway.

Lets talk facts, TDD reduces bugs that make it to Production by40% to 80%
Which according to all that stats I can find on the topic makes it almost comically more effective than types which is the common thread I see among "non testers". They work in typed languages.

The problem with this is that they are working in what I call "Liar Typed Languages" the compiler makes you feel warm and cozy, meanwhile its not checking shit. Sure its making sure you are passing in a Number and not a String, thanks every year I make that mistake a few times... You really saved me types... You know what type of bugs I suffer from daily? undefined or null. What does Java's or C#'s type system do to protect me from those? Jack shit. At least languages like Haskell or Elm have effective type systems that genuinely protect you from this.

So those are my thoughts on that, test your code and don't let lying types be your safety net. See you tomorrow!

Discussion

pic
Editor guide
Collapse
simoroshka profile image
Anna Simoroshka

If your boss is the reason you don't test quit, seriously quit that job because you will end up hating it in a few months anyway.

it's been 1 year and 8 months, I am still holding XD
I was very junior when I started and did not understand the value of testing for quite a while, mainly because there never was an example of how things could be. And when breaking production happens on a regular basis one can stop caring much...

Collapse
david_j_eddy profile image
David J Eddy

I want to hug you so hard right now.

Collapse
theredspy15 profile image
Hunter Drum

From my experience, you should always test when you can. I've had several situations where testing simply wasn't possible or it just would require more lines of test code, than production code

Collapse
lvrbrtsn profile image
Levi ᕙ(⇀‸↼‶)ᕗ Author

Agreed! I was grumpy this morning so my opinions where stronger lol

Collapse
biros profile image
Boris Jamot ✊ /

Maybe some people don't write tests because they're written by someone else. I mean, many people don't write unit tests, because their app get tested by some acceptance tests written by the QA team. But in the end, the app gets tested. In fact, I didn't ever see an app going to production without any test. I would be happy to hear about people doing so.

Collapse
lvrbrtsn profile image
Levi ᕙ(⇀‸↼‶)ᕗ Author

Someone else writing automated tests I’ll accept. Using a manual QA team as the only line of defense is a joke.

deciduously profile image
Ben Lovy

I agree that perhaps they shouldn't, but we can't ignore the fact that they do. And if someone were to come along and re-implement TeX in JS, I'm gonna want to see some tests.

Thread Thread
lvrbrtsn profile image
Collapse
kwabenberko profile image
Kwabena Bio Berko

"Liar Typed Languages"
😂😂😂

Collapse
lvrbrtsn profile image
Levi ᕙ(⇀‸↼‶)ᕗ Author

Doesn’t pascal have a superior type checker to Java and C#? In cases like Haskell or Elm I can see trusting the compiler. Write TeX in JavaScript with not tests and 6 bugs.