My company never used unit tests. And i would love to educate but i do not know how to unit test properly. I always en up with: if i want to properly test all ins and outs of this class's + operator. I need to add checks for positive number, negative numbers, nan, infinites, nulls etc. Etc. It needs so many tests for something so stupidly simple, that i don't see a way to motivate people to use it.

Am i missing something? Is there a guideline for "ok coverage"? Is testing just that much work and is that why nobody cares until it is too late?

I have been reading a book about working with legacy code. But still i got no answers. Halp!

Well. Instead of starting with full coverage. Try to find a few methods that often break due to other changes and implement tests for those.

Its not technically a good unit test but hopefully it will show the power of them.

Then dig deeper and add tests for all methods it is dependent on to capture the more specific reason and finally you will be down to test the basics.

Don't unit test framework or language features unless you wrote them.

We started about 2 years ago and have only come a small step.

Some 550 tests and I estimate we would need in the range of 10 000 before having a reasonable coverage.

But since the are centered on one part the have already helped speed up development there by catching regressions early.

@Voxera you basically tell me what the book said as well.

Problem being that i do know when a test is good enough. Example: i made a big double. Basically a double with an int backing it to have double precision but posibility to store a fuckload long number in there because the int kept the decimal place.

I tried writing tests for that. Like 1 method had 20ish combination just to attempt adding up or multiply. I had to manually do all the math for them ending up with like 300 manual assertions per operator to really cover all nan inf positives negatives ups and downs. It was madness. I never finished and concluded, ill fix whatever doesn't look right when i get there.

Is there any other way? I can't be expected to try ALL different possible inputs and have it work?

@Bacontaskmaster

Do you change this class very often or is it dependent on other classes?

If not, it's probably not the most important to test with unit tests.

You want to start with code that is likely to break between releases (unless you do test driven design).

So rather pick a more high level class or code to show of the power with.

As an example, I have a scripting library. My first tests was small scripts doing some math and string concatenations.

Not a "good" test as it involves way to many possible causes for an error.

But it sure catches many regressions.

In your example. Start with testing not one operation but for example.

Loop over all numbers from 1 to 100 ,
Cast them to your type. Multiply with 0, 1, 0.1, -1 ... add all up, divide by 1.3

Check the result. You might nit know what went wrong but odds are that any major error would trigger this test and then you can do manual testing to find the exact cause.

@Voxera ok, but how does the test know it is wrong? I have to define answers for the test. Implementing the math in the test is basically against testing rules right? I cant write a test that is a copy of my code, it would always pass.
How do i go about writing answers to so many input combinations?

@Bacontaskmaster My example uses a fixed set of inputs which means there can be only one valid answer.

And the test just runs your code with the fixed input and compare with a fixed answer. If they differ it knows something is wrong.

@Voxera well the problem with my method was that it had to implement an operator. Which had to account for all possible combinations of the 2 parameters it takes. So (0 -0 int+ int- inf NaN double+ double-)*2*both ways

The way i had it, i had over 200 answers to fill in per operator, and i needed to implement all of them + × ÷ - < > == etc.

It wasn't even funny how much static answers i had to provide ro ensure all the different operators would work like expected 100% of the time.

@Bacontaskmaster I do understand and the sad answer is that I do not think there ate any shortcuts to good unit testing.

Especially for complex code.

On the other hand it also depends on the reason you test.

Good tests not only catch regressions but also define the functionality.

By looking at the tests you get a form of documentation.