Do they belong to you? Claim these comments.
Anne Marie
Is this you? Claim Profile »
2 years ago
in What makes a test suite good? on Thinking inside a bigger box
Since this is a very interesting discussion I just have to share some of my opinions on some of the subjects.
Test coverage: If we develop test-driven (and even better: behavior-driven), line/branch coverage should (in theory) never be a problem, since you will only write code that you have already written a test for. In theory that should give you 100% test coverage PLUS your tests are to the point. Why can't we achieve this? Is it because we aren't doing real TDD/BDD? Is it actually possible to develop the whole system test-driven?
Test coverage II: Don't introduce special test frameworks that tests getters and setters because you can't really write useful tests for your getters and setters, and leaving them untested lowers your test coverage (in the "old" meaning of the word). If your getters/setters aren't used indirectly by your other tests, and you don't want to test them explicitly, then why do you have them there at all? In addition to being absolutely pointless, these tests have a tendency to get in your way when you are actually developing real functionality in your system.
Mock objects: A good rule of thumb is to NOT use mock objects if what you really need is to stub up some interface. Implement a stub instead. This will often be both more robust and more reusable. Use mock objects when you actually want to test that the class you are testing is calling a method in another class.
Universal test: This seems like a very good idea, but the (few) times I have tried to achieve this, for some reason or another we couldn't do it. It's a cost/value question, I guess.
Test coverage: If we develop test-driven (and even better: behavior-driven), line/branch coverage should (in theory) never be a problem, since you will only write code that you have already written a test for. In theory that should give you 100% test coverage PLUS your tests are to the point. Why can't we achieve this? Is it because we aren't doing real TDD/BDD? Is it actually possible to develop the whole system test-driven?
Test coverage II: Don't introduce special test frameworks that tests getters and setters because you can't really write useful tests for your getters and setters, and leaving them untested lowers your test coverage (in the "old" meaning of the word). If your getters/setters aren't used indirectly by your other tests, and you don't want to test them explicitly, then why do you have them there at all? In addition to being absolutely pointless, these tests have a tendency to get in your way when you are actually developing real functionality in your system.
Mock objects: A good rule of thumb is to NOT use mock objects if what you really need is to stub up some interface. Implement a stub instead. This will often be both more robust and more reusable. Use mock objects when you actually want to test that the class you are testing is calling a method in another class.
Universal test: This seems like a very good idea, but the (few) times I have tried to achieve this, for some reason or another we couldn't do it. It's a cost/value question, I guess.