Not writing unit tests.

Everyone reading this is guilty of it.

Anyone who says otherwise is lying.

😂😂😂😂😂😂

True. I have the bad habit of writing them after everything is working. And i know damn well it would save time if i just did the boreing work first

You don't have to write unit test if you don't know what the fuck is a unit test.

Seriously tho. What *is* a unit test?

@PythonTryHard code you write that expects certain results when calling your application code. It throws an exception if those results deviate from the expectations, signaling that you have broken your code.

@PythonTryHard something validating that you're properly using the metric system

But i dont do unit tests

I really want to follow best practices, but when gradle build fail, when I include Test frameworks, my gradle build breaks 🤷‍♂️

Hey! I DO write unit tests! They usually look something like

console.log(...)

The coop thing is that they always pass!! 😂

Can't write unit tests if you don't know how to write one.

In my defence, no one taught me that in school, and I just recently found out there was something called "unit test" (a few days after I joined devRant, actually).
I will look into it, I promise, please don't kill me!

@cantthinkofone if there is one thing to learn to improve your skill set, it would be unit tests and test-driven development (TDD). I suggest making that your number one priority. If done right, they separate novice code from professional code. They remove all the surprises of human error that can arise from working in your code. If a bug is found later, it means you need another test that exposes the bug to make sure it never happens again. Slowly but surely your code becomes incredibly stable.

Writing tests also forces your code to utilize design patterns and dependency injection and not be a pile of tightly-coupled spaghetti.

It's a shame that many educational institutes don't seem to teach them like they should. They are that important.

I, can refute this claim.
In my 90 day long career, never ever have I not written UTs for a code that'd actually be used.

I've never written a unit test in my entire fucking life 😐

How do you write unit tests if you're migrating legacy code? First goal is to match the existing code as much as possible? And will the old code is not unit testable. All I can really test is does the output match?

@billgates I only ever test outputs. In general, I loathe "assert was called". Testing outputs is the only real way to write unit tests that are also not tightly-coupled to the implementation of the code they are testing. Done this way, you can gut and re-write your entire inner workings of the implementation without having to spend an enormous amount of time refactoring all the unit tests too.

@billgates As far as refactoring legacy code, if it's a bunch of tightly coupled spaghetti that's untestable, one approach is to utilize what's known as Bastard Injection.

With Bastard Injection, you have a constructor in each old spaghetti-like class that initializes all the dependencies the class needs. This constructor should be the same one that all the other spaghetti code uses when it interacts with it.

Then, you create a new constructor the right way with dependencies injected in as parameters. This is what your new Inversion of Control (IoC) container will use (and any other new code created that relies on it will use) going forward.

You can create tests that utilize these new constructors, because now each piece of code that has them should be testable this way.

The old code can then be refactored bit by bit to not have direct references to each implementation anymore and instead use dependency injection, one refactor at a time. Then remove the old "bastard" constructors.

@duckWit well actually the classes are already DI (Spring) the problems is a lot of AutoWire fields do that get set from context inheritance. So basically would need to mock all the classes that get injected.

It just makes writing unit tests feel more like: what sort of data is this supposed to return when you pass in X, Y, Z, ... What are the actually valid inputs to test. Otherwise it can be like a N! different states that need to be covered. And then there's all the if nesting...

Like calc(A a, B b, Input I)
{
var x = a.process(I)
var y = b.process(I)

if (x == ... && y == ...) ....
var z = join(x,y);
return c.process(z)
}

@billgates test each injected piece independently, on their own. Then for a composite service that has other services injected in just make sure a single test that ties them all together behaves properly and call it good (or a minimum amount of scenarios that would be beneficial for the tested piece) because you already proved the injected services are correct. The tests can grow to cover more scenarios as bugs arise. Until then, you'll have a good amount of initial coverage. That's what I'd do, anyway.

@billgates and, if-chains and if-nesting certainly complicates things. That usually calls for a refactor, moving each option into its own implementation of a common abstraction like an interface. Then you can test each option/implementation independently. Then test the factory that initializes the right one(s) depending on parameters passed in. That's one approach for cleaning that up and making it testable.

@duckWit yes I mean all this is legacy code, if I could burn the whole thing I would. I'm basically "rewriting" cuz I needed to figure what the original code does and what's the equivalent in the new system. But to make it comparable, I have to keep the structure. But I am also required to make it pass a unit test coverage threshold... TDD helps encourage good design but writing tests just to meet a threshold feels pretty pointless.

imma be real wichu, i dont even know how to write unit tests

@duckWit did you test your rant's statement?

@eeee the rant itself is a test, and it's quite eye-opening.