Stub in or out?

[bjoerne]

Hello!
I would like to use the stub module of jsfutil. I found in your jira the issue
"split stubs into separate mvn module" and it should be fixed an included in the version "1.0.0.Beta2". But the module was removed in this version a few days ago although your roadmap says it is included. Whats your plan about "stub"? Do I have to wait for the "GA" until I can use it in a non snapshot version?
Greets
Bjoern

[ssilvert]

Hi Bjoern,

It's out for now. This was based on some Shale code that seemed abandoned. We had the idea to give it a new life and some refactoring at JSFUnit. But we found out that maybe the code over at Shale is not dead after all. If it will continue to be actively maintained at Shale then that gives us no reason to work on it at JSFUnit.

We never should have put it in SVN until we were sure if we wanted to release it. Sorry for the confusion.

Stan

[zhxujboss]

Hi Stan,

Since the stub is out for now, what is the alternative we have in achieving the same testing goal as described in the section Working with Stubs from the Wiki doc.

thanks

[ssilvert]

My personal preference is to not use stubs or mocks at all. Instead, you just do all of your testing in-container with real live objects. I think that makes for a more accurate test because you don't rely on the quality and suitability of the the stubs.

So instead of building tests that may or may not do a good job of simulating real-world scenarios, you do test-driven development in such a way that you are always testing use cases and their many variations. With in-container testing you do this in an environment that is as close to matching the production system as possible. To me, it seems obvious that this is a more valid and more useful test.

The only downside is that you need to start the container when you want to run a test. Some developers feel like that throws them out of their rhythm. But we now have containers that start in less than a second. And hardware keeps improving. So we can now run in-container tests faster than we ran mock/stub tests just a few years ago.

Of course there are two sides to every argument and Dennis Byrne, our other main JSFUnit comitter, disagrees with me. I have great respect for him and others who prefer the traditional technique. This is why I wanted (and still want) developers to have a first-rate stub library for JSF. For now you can use the one that comes with Shale. Unfortunately, it won't include the work that Dennis did on it. Maybe soon we'll get all this worked out.

Stan

[zhxujboss]

Thank you for the prompt response. Stan.

One more question, how can we test

1. Renderer.encodeBegin(FacesContext context, UIComponent component)
2. ActionListener.processAction(ActionEvent event)

Thanks

Mike

[ssilvert]

"zhxujboss" wrote:

One more question, how can we test

1. Renderer.encodeBegin(FacesContext context, UIComponent component)
2. ActionListener.processAction(ActionEvent event)

I would test them in the context of a real request. It is pretty straightforward to set up use cases for the expected inputs and outputs of these methods. You just need a simple JSF app.

So for #1, you just use the JSFClientSession to look at the returned page and make sure that the expected HTML really was written to the output stream.

For #2, you would test that processAction() left the server side in the expected state. In JSFUnit, you have access to the FacesContext, all managed beans, and virtually every other server-side object and resource. So in-container testing is extremely well suited for this.

IMHO, testing this way does a better job of achieving TDD goals. That is, you are able to think about how your components must behave in the true environment rather than how they behave in a mock environment. So as you develop these components, they will exhibit better design and will be better suiting to the real-world task.

Stan