Handling repetitive unit testing tasks [duplicate]

Question

This problem arose whilst writing a simple 3D vector class.

The class contained methods (Java, so no operator overloading) for addition, subtraction, multiplication, and division. These methods performed this operation between the instance they were called on, and another vector or single value.

When it came to writing the unit tests, I was unsure how I should approach testing this class.

The three options I could come up with were as follows:

• Test the Add, Sub, Mul, and Div methods separately (two for each, vector and value), with different values for each
• Test the methods separately with the same values each time, but different expected results
• Don't test the methods as they are very simple (not good for coverage)

What method would be most desirable in this situation? This pretty much also applies to any other scenarios where a task is very repetitive.

Answer 1

The only choice that is clearly wrong is "Don't test the methods as they are very simple."

Not testing is bad testing, regardless of how simple the methods are.

Some developers favor very spare unit tests, in which "only one thing can fail." As a result, even simple methods might deserve many individual test functions/methods.

To reduce boilerplate, excess "testing noise," and boredom, my preference is longer tests that really give each base method a good run for their money (at minimum including some simple cases, and some edge cages).

I would use a hybrid of choice 2 and choice 1: Use at least some of the same values in tests of your different Add, Sub, etc. methods, with different expected results (choice 2). Common inputs will simplify understanding not just of the testing code, but also the scope of testing--an important element as, over time, the ideal is to extend the tests to be fuller, richer, and cover more cases.

But some methods like Div and Mul beg for some tests that are different from those for additive operations (e.g. testing divide by zero). So for simplicity, start with choice 2, then to properly exercise useful edge cases, a dash of choice 1 (adding different inputs).

Answer 2

I don't really see this as a Question and Answer problem but an entirely subjective one. The 'correct' answer is the one that gets the most complete and accurate set of tests.

Boredom is the most defining obstacle with your 'problem': At one end of the spectrum errors will creep in because you're so bored by the repetition that your eyes glaze over and loose attention to detail.

At the other end you devise an elaborate automated test structure which keeps you challenged, but is inevitably error prone due to unexpected quirks (ie bugs) and esoteric maintenance issues. Too far up this end and you need tests for your testing code.

As individuals our path-of-the-least-errors will vary. Just know there is one and walk the line that you think works best for you.