What to test when writing Unit Tests?

Question

I want to begin unit testing our application, because I believe that this is the first step to developing a good relationship with testing and will allow me to branch into other forms of testing, most interesting BDD with Cucumber.

We currently generate all of our Base classes using Codesmith which are based entirely on the tables in a database. I am curious as to the benefits of generating test cases with these Base classes? Is this poor testing practices?

This leads me to the ultimate question of my post. What do we test when using Unit Tests?

Do we test the examples we know we want out? or do we test the examples we do not want?

Their can be methods that have multiple ways of Failing and multiple ways of Success, how do we know when to stop?

Take a Summing function for example. Give it 1,2 and expect 3 in the only unit test.. how do we know that 5,6 isn't coming back 35?

Question Recap

• Generating unit tests (Good/Bad)
• What/How much do we test?

Answer 1

Start with your requirements and write tests that test the expected behavior. From that point on, how many other scenarios you test can be driven by your schedule, or maybe by your recognizing non-success scenarios that are particularly high-risk.

You might consider writing non-success tests only in response to defects you (or your users) discover (the idea being that you write a test that tests the defect fix before you actually fix the defect, so that your test will fail if that defect is re-introduced into your code in future development).

Answer 2

The point of unit tests is to give you confidence (but only in special cases does it give you certainty) that the actual behavior of your public methods matches the expected behavior. Thus, if you have a class Adder

class Adder { public int Add(int x, int y) { return x + y; } }

and a corresponding unit test

[Test]
public void Add_returns_that_one_plus_two_is_three() {
    Adder a = new Adder();
    int result = a.Add(1, 2);
    Assert.AreEqual(3, result);
}

then this gives you some (but not 100%) confidence that the method under test is behaving appropriately. It also gives you some defense against breaking the code upon refactoring.

What do we test when using Unit Tests?

The actual behavior of your public methods against the expected (or specified) behavior.

Do we test the examples we know we want out?

Yes, one way to gain confidence in the correctness of your method is to take some input with known expected output, execute the public method on the input and compare the acutal output to the expected output.

Answer 3

1) To start, i'd recommend you to test your app's core logic.

2) Then, use code coverage tool in vs to see whether all of your code is used in tests(all branches of if-else, case conditions are invoked). This is some sort of an answer to your question about testing 1+2 = 3, 5 + 6 = 35: when code is covered, you can feel safe with further experiments.

3)It's a good practice to cover 80-90% of code: the rest of work is usually unefficient: getters-setters, 1-line exception handling, etc.

4) Learn about separation of concerns.

5) Generation unit tests - try it, you'll see, that you can save a pretty lines of code writing them manually. I prefer generating the file with vs, then write the rest TestMethods by myself.

Answer 4

What to test: Everything that has ever gone wrong.

When you find a bug, write a test for the buggy behavior before you fix the code. Then, when the code is working correctly, the test will pass, and you'll have another test in your arsenal.

Answer 5

You unittest things where you

• want to make sure your algorithm works
• want to safeguard against accidental changes in the future

So in your example it would not make much sense to test the generated classes. Test the generator instead.

It's good practice to test the main use cases (what the tested function was designed for) first. Then you test the main error cases. Then you write tests for corner cases (i.e. lower and upper bounds). The unusual error cases are normally so hard to produce that it doesn't make sense to unit-test them.

If you need to verify a large range of parameter sets, use data-driven testing.

How many things you test is a matter of effort vs. return, so it really depends on the individual project. Normally you try to follow the 80/20 rule, but there may be applications where you need more test coverage because a failure would have very serious consequences.

You can dramatically reduce the time you need to write tests if you use a test-driven approach (TDD). That's because code that isn't written with testability in mind is much harder, sometimes near to impossible to test. But since nothing in life is free, the code developed with TDD tends to be more complex itself.

Answer 6

I'm also beginning the process of more consistently using unit tests and what I've found is that the biggest task in unit testing is structuring my code to support testing. As I start to think about how to write tests, it becomes clear where classes have become overly coupled, to the point that the complexity of the 'unit' makes defining tests difficult. I spend as much or more time refactoring my code as I do writing tests. Once the boundaries between testable units become clearer, the question of where to start testing resolves itself; start with your smallest isolated dependencies (or at least the ones you're worried about) and work your way up.

Answer 7

There are three basic events I test for: min, max, and somewhere between min and max.

And where appropriate two extremes: below min, and above max.

There are obvious exceptions (some code may not have a min or max for example) but I've found that unit testing for these events is a good start and captures a majority of "common" issues with the code.