New to unit testing how to write great tests

Question

I m fairly new to the unit testing world  and I just decided to add test coverage for my existing app this week   This is a huge task  mostly because of the number of classes to test but also because writing tests is all new to me   I ve already written tests for a bunch of classes  but now I m wondering if I m doing it right     When I m writing tests for a method  I have the feeling of rewriting a second time what I already wrote in the method itself  My tests just seems so tightly bound to the method  testing all codepath  expecting some inner methods to be called a number of times  with certain arguments   that it seems that if I ever refactor the method  the tests will fail even if the final behavior of the method did not change   This is just a feeling  and as said earlier  I have no experience of testing  If some more experienced testers out there could give me advices on how to write great tests for an existing app  that would be greatly appreciated   Edit   I would love to thank Stack Overflow  I had great inputs in less that 15 minutes that answered more of the hours of online reading I just did

User · Accepted Answer

My tests just seems so tightly bound to the method (testing all codepath, expecting some inner methods to be called a number of times, with certain arguments), that it seems that if I ever refactor the method, the tests will fail even if the final behavior of the method did not change.

I think you are doing it wrong.

A unit test should:

test one method
provide some specific arguments to that method
test that the result is as expected

It should not look inside the method to see what it is doing, so changing the internals should not cause the test to fail. You should not directly test that private methods are being called. If you are interested in finding out whether your private code is being tested then use a code coverage tool. But don't get obsessed by this: 100% coverage is not a requirement.

If your method calls public methods in other classes, and these calls are guaranteed by your interface, then you can test that these calls are being made by using a mocking framework.

You should not use the method itself (or any of the internal code it uses) to generate the expected result dynamically. The expected result should be hard-coded into your test case so that it does not change when the implementation changes. Here's a simplified example of what a unit test should do:

testAdd()
{
    int x = 5;
    int y = -2;
    int expectedResult = 3;
    Calculator calculator = new Calculator();
    int actualResult = calculator.Add(x, y);
    Assert.AreEqual(expectedResult, actualResult);
}

Note that how the result is calculated is not checked - only that the result is correct. Keep adding more and more simple test cases like the above until you have have covered as many scenarios as possible. Use your code coverage tool to see if you have missed any interesting paths.

User · Answer

Unit testing is about the output you get from a function method application  It does not matter at all how the result is produced  it just matters that it is correct  Therefore  your approach of counting calls to inner methods and such is wrong  What I tend to do is sit down and write what a method should return given certain input values or a certain environment  then write a test which compares the actual value returned with what I came up with

User · Answer

tests are supposed to improve maintainability   If you change a method and a test breaks that can be a good thing    On the other hand  if you look at your method as a black box then it shouldn t matter what is inside the method   The fact is you need to mock things for some tests  and in those cases you really can t treat the method as a black box   The only thing you can do is to write an integration test -- you load up a fully instantiated instance of the service under test and have it do its thing like it would running in your app   Then you can treat it as a black box    When I m writing tests for a method  I have the feeling of rewriting a second time what I           already wrote in the method itself  My tests just seems so tightly bound to the method  testing all codepath  expecting some     inner methods to be called a number of times  with certain arguments   that it seems that if I ever refactor the method  the tests will fail even if the final behavior of the    method did not change    This is because you are writing your tests after you wrote your code   If you did it the other way around  wrote the tests first  it wouldnt feel this way

User · Answer

Don t write tests to get full coverage of your code  Write tests that guarantee your requirements  You may discover codepaths that are unnecessary  Conversely  if they are necessary  they are there to fulfill some kind of requirement  find it what it is and test the requirement  not the path    Keep your tests small  one test per requirement   Later  when you need to make a change  or write new code   try writing one test first  Just one  Then you ll have taken the first step in test-driven development

User · Answer

It s worth noting that retro-fitting unit tests into existing code is far more difficult than driving the creation of that code with tests in the first place   That s one of the big questions in dealing with legacy applications    how to unit test   This has been asked many times before  so you may be closed as a dupe question   and people usually end up here   Moving existing code to Test Driven Development  I second the accepted answer s book recommendation  but beyond that there s more information linked in the answers there

User · Answer

For unit testing  I found both Test Driven  tests first  code second  and code first  test second to be extremely useful   Instead of writing code  then writing test  Write code then look at what you THINK the code should be doing  Think about all the intended uses of it and then write a test for each  I find writing tests to be faster but more involved than the coding itself  The tests should test the intention  Also thinking about the intentions you wind up finding corner cases in the test writing phase  And of course while writing tests you might find one of the few uses causes a bug  something I often find  and I am very glad this bug did not corrupt data and go unchecked    Yet testing is almost like coding twice  In fact I had applications where there was more test code  quantity  than application code  One example was a very complex state machine  I had to make sure that after adding more logic to it  the entire thing always worked on all previous use cases  And since those cases were quite hard to follow by looking at the code  I wound up having such a good test suite for this machine that I was confident that it would not break even after making changes  and the tests saved my ass a few times  And as users or testers were finding bugs with the flow or corner cases unaccounted for  guess what  added to tests and never happened again  This really gave users confidence in my work in addition to making the whole thing super stable  And when it had to be re-written for performance reasons  guess what  it worked as expected on all inputs thanks to the tests   All the simple examples like function square number  is great and all  and are probably bad candidates to spend lots of time testing  The ones that do important business logic  thats where the testing is important  Test the requirements  Don t just test the plumbing  If the requirements change then guess what  the tests must too   Testing should not be literally testing that function foo invoked function bar 3 times  That is wrong  Check if the result and side-effects are correct  not the inner mechanics

User · Answer

Try writing a Unit Test before writing the method it is going to test   That will definitely force you to think a little differently about how things are being done  You ll have no idea how the method is going to work  just what it is supposed to do   You should always be testing the results of the method  not how the method gets those results

[unit-testing] New to unit testing, how to write great tests?

Examples related to unit-testing

Examples related to testing