can i test the action and actionListener methods in my manag

[maykellff]

Hi all i have a doubt,
i can't test my action and action listeners methods in my managed beans?

According to what i've seem i only can test a property value in a managed bean.

I hope your help,
Maykell.

[ssilvert]

You can test action and action listener methods. I didn't add an API for it, but I've thought about it some. Maybe you can help me decide.

The first way to test these methods is to do it indirectly. That is, you simply submit a page that executes the method and then examine the resulting state after the request is done.

The second way is to use the JSF API directly. You would do this in your JSFUnit code:

FacesContext facesCtx = FacesContext.getCurrentInstance();
Application application = facesCtx.getApplication();
MethodBinding binding = application.createMethodBinding(elExpression, expectedParams);
Object result = binding.invoke(facesCtx, params);

If you are running JSF 1.2, you also have the option to replace the third line with application.getExpressionFactory().createMethodExpression() and follow the Unified EL API to avoid the deprecated MethodBinding class.

The question I have about this "second way" is if it is a useful idiom in a JSFUnit test. That is, I don't know if developers want to test that way. If it is useful, it would be easy to replace the above code with a single API call on JSFServerSession.

Stan

[ssilvert]

BTW, the other reason I haven't added that API is because executing a MethodBinding outside the scope of a request can have side effects that mess up a subsequent request. Of course, that may be a good reason for testing this way. That is, you might want to test to make sure you haven't added such side effects to your action methods.

Stan

[maykellff]

BTW, the other reason I haven't added that API is because executing a MethodBinding outside the scope of a request can have side effects that mess up a subsequent request. Of course, that may be a good reason for testing this way. That is, you might want to test to make sure you haven't added such side effects to your action methods.

Stan

Hi Stan, first of all, thank you very much for this wonderful idea of a JSF testing framework.
I asked about testing facilities most of all thinking in "no regression tests".
I think that the idea in using this feature of testing action and actionListeners method would be useful to write tests cases where you can ensure that a specified method behave as expected across multiple changes in the development main line of the application.

I understand the fear you have about this topic, but this is a risk that is always present in my opinion, for example:
When you write a test case to test a dao operation over the DB, if you don't do a roll back at the end, you are running the risk of fill full the DB with garbage data, that can potentially affect other tests.

In my opinion this would be useful.

Thank you very much again,
Maykell.

[alejesse]

The first way to test these methods is to do it indirectly. That is, you simply submit a page that executes the method and then examine the resulting state after the request is done.

For this case every now and then I would like to have a

assertMethodIsCalled(...)

code in my unit-test class...
I wonder whether that could be done using aspects...

The second way is to use the JSF API directly. You would do this in your JSFUnit code:

FacesContext facesCtx = FacesContext.getCurrentInstance();
Application application = facesCtx.getApplication();
MethodBinding binding = application.createMethodBinding(elExpression, expectedParams);
Object result = binding.invoke(facesCtx, params);

If you are running JSF 1.2, you also have the option to replace the third line with application.getExpressionFactory().createMethodExpression() and follow the Unified EL API to avoid the deprecated MethodBinding class.

So it would just be the question of adding a simple sample...

The question I have about this "second way" is if it is a useful idiom in a JSFUnit test. That is, I don't know if developers want to test that way. If it is useful, it would be easy to replace the above code with a single API call on JSFServerSession.

On a "Apache-Style" vote, I think I would respond with a +0.5. Basically I'm undecided, but if the API would be there... then why not using it. And if the cost of adding it is low...

In order to reduce side-effects, especially on testcases run afterwards without redeploying the web-application, it might make sense to able to have a

JSFServerSession.resetAllManagedBeans()

API. This would have to remove all instantiated managed beans from their respective contexts.

[ssilvert]

If anyone wants their vote to be more official, you can add your vote to jira here http://jira.jboss.com/jira/browse/JSFUNIT-76

Stan