Comments on: Enhanced Code Coverage for Finite State Machines

By: Safwat

Safwat — Wed, 24 Mar 2010 18:28:20 +0000

First, our example about proving that 100% test coverage not means full testing for business logic transitions, is an excellent example and also very simple and efficient.

Second, making the state machine design could be imported and configured from an excel sheet is a very good idea.

Third, the running of the state machine may be simple in some cases, but if the state machine is very huge, you can use the FSM framework to define the model and running it, then use your idea to adapt the code to run the result in a JUnit framework.

By: Gary P. Russell

Gary P. Russell — Wed, 07 Jan 2009 01:15:05 +0000

>>Code Coverage can’t possibly tell you if your tests are sufficient…

My point exactly; over the years I have encountered individuals that have believed that they were “done” once they had 100% coverage. The example was an attempt to illustrate that this is clearly not the case. That said, it is certainly a step in the right direction.

By: Jens Schauder

Jens Schauder — Tue, 06 Jan 2009 19:48:17 +0000

Code Coverage can’t possibly tell you if your tests are sufficient. It might tell you that you haven’t tested enough though.
http://blog.schauderhaft.de/2008/10/20/code-coverage-what-is-it-good-for/

By: Tom McCuch

Tom McCuch — Sun, 04 Jan 2009 21:27:35 +0000

I think the idea of driving JUnit Tests from Excel is an excellent one. It could be used for any automated “unit integration” tests of objects (or services) in the business layer. Every end-user can understand Excel, so an effective set of spreadsheets that helps model both input data and expected results could be used to have your users “write” your tests for you (in a structured way that does not require any further development) using a simple tool they do not need training in.

I would be very interested in seeing how you were able to get this to work.