Comments for Javascinating

Comment 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.

Comment on Enhanced Code Coverage for Finite State Machines 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.

Comment on Enhanced Code Coverage for Finite State Machines 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/

Comment on The Customer Comes First (Back to the Future?) by Bob Palmer

Bob Palmer — Tue, 06 Jan 2009 12:17:44 +0000

Well said Gary! It is unfortunate that the younger workers of today have not all been able to grasp these concepts. How frustrating!

These tenants have also served me well as I know they have taken care of you.

I look forward to more insight on your blog.

Comment on Enhanced Code Coverage for Finite State Machines 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.

Comment on Proxying Your Stubs Can Save Space and Time by Oleg Zhurakousky

Oleg Zhurakousky — Sun, 28 Dec 2008 04:14:04 +0000

One of the benefits of Stubs over Mocks is reusability, where one can reuse the object (CUT) in other test cases.
One of the benefits of Mocks over Stubs is dynamics, where one can define a behaviour in-line and see that it is executed.
Both cover the two sides of testing. . . but what is in between???
What if I want to stub one part of a component, but mock the other? This sample clearly shows how it could be accomplished. I almost want to call it reversed AOP Introduction, where arbitrary class (CUT) could be matched to a method or two of the interface view Proxy. . .
I think a better example would clear up any uncertainty, but pretty clever (I think) from the technology perspective…
Oleg

Comment on Proxying Your Stubs Can Save Space and Time by Gary P. Russell

Gary P. Russell — Sat, 27 Dec 2008 01:46:32 +0000

>>
You’ve essentially just written a really clumsy implementation of a mock object.
< <

Thanks for your opinion.

I tried to preempt such comments with my preamble; I guess I failed.

>>>
Setting aside the discussion of stubs Vs. mocks in JUnit testing (that is covered more than adequately elsewhere), let’s say you’ve decided to use stubs, for whatever reason.

Please understand that the simple examples in this article may be more appropriately handled with mocks; they are for illustrative purposes only
<<<

The key phrase being “…let’s say you’ve decided to use stubs, for whatever reason…”

I necessarily had to greatly simplify the example. I had, and have, no intention of getting into a religious war on the subject.

Comment on Proxying Your Stubs Can Save Space and Time by Charles Miller

Charles Miller — Fri, 26 Dec 2008 21:20:26 +0000

You’ve essentially just written a really clumsy implementation of a mock object. Why not go the whole hog at this point and use a real mock framework that’s actually better designed, easier to use and expresses the intent of the test more clearly?

Comment on Proxying Your Stubs Can Save Space and Time by Tom McCuch

Tom McCuch — Thu, 25 Dec 2008 23:09:34 +0000

This is especially nice for consulting engagements where the consultant is being brought in to implement a few bug fixes and/or some additional functionality to an existing system and needs to verify the new development was completed as designed with pin-point precision, and without breaking the bank.