Hello! Thinking inside a bigger box is using DISQUS, a powerful comment system, to manage its comments. Learn more.
Community Page
- www.brodwall.com/johannes/blog/ Jump to website »
-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- The evolution of SOA Introduce the concepts of services and SOA Design principles of SOA ... The benefits of employing SOA Review of common business goals ... Related articles. Web Application...
- Great article and I agree with you that ............ Thanks for the tips!
- Great read, good work old chap :)
- Hi...Your post really got me thinking man..... an intelligent piece ,I must say.
- Was a good read. thank great post, I think this article is useful. I'll be back for more. Thanks for sharing the information . .. :)
Jump to original thread »
Many people enjoy splitting testing up in a myriad of test types: Acceptance Tests, Functional Tests, Integration Tests, Performance Test, Technical Tests, Unit Tests. I have myself been guilty of such terminology as “embedded integration tests” and “r
... Continue reading »
2 years ago
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.
2 years ago
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?