Thanks for the comment. I agree that in principle, TDD will give us high line coverage. In practice, I have not seem a code base that gets more than 90 % or so (my own). I don’t know why this always happens. In Java, it seems like checked exception is a part of the culprit, however.

However, getting a 100 % line coverage doesn’t mean that you get perfect coverage in the sense of reducing the chance of a bug sneaking though.

About Universal Tests: I think they can be taken a lot further than people are doing today, and I think it will be beneficial. I am looking forward to working more on this topic. Hope to get your comments. Did you see the test cases I linked in?

Thanks for the comment. I agree that in principle, TDD will give us high line coverage. In practice, I have not seem a code base that gets more than 90 % or so (my own). I don't know why this always happens. In Java, it seems like checked exception is a part of the culprit, however.

However, getting a 100 % line coverage doesn't mean that you get perfect coverage in the sense of reducing the chance of a bug sneaking though.

About Universal Tests: I think they can be taken a lot further than people are doing today, and I think it will be beneficial. I am looking forward to working more on this topic. Hope to get your comments. Did you see the test cases I linked in?

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.