Requester API
dan.j.allen Feb 16, 2010 10:17 AMOne of the things I would like to consider adding to Arquillian (not necessarily right away, but shortly after 1.0.0) is a requestor framework. If you've ever used SeamTest, it would be something similar to the following:
@Test public void testChangePassword() throws Exception { new FacesRequest() { @Override protected void invokeApplication() throws Exception { // assume the database is seeded already setValue("#{identity.username}", "tenaciousd"); setValue("#{identity.password}", "rockon"); invokeMethod("#{identity.login}"); } }.run(); new FacesRequest() { @Override protected void processValidations() throws Exception { validateValue("#{user.password}", "xxx"); assert FacesContext.getCurrentInstance().isValidationFailed(); } @Override protected void renderResponse() { assert getValue("#{currentUser.name}").equals("Jack Black"); assert getValue("#{currentUser.username}").equals("tenaciousd"); assert getValue("#{currentUser.password}").equals("rockon"); assert getValue("#{identity.loggedIn}").equals(true); } }.run(); ... }
The API wouldn't be limited to just Faces requests, that's just the example I show here. It would also be able to do a basic GET or POST request.
This API is important as a way to test contextual beans. To grab a hold of a session or request-scoped bean, an HTTP request lifecycle must be active. Currently, this is done in the embedded Weld container by wrapping each test method in a request, but that is opinionated software, as ALR would put it. It's far better to provide easy hooks to setup and teardown contextual lifecycles around the test code. (We don't have to stick to the anonymous class approach, that just happens to be an impl detail of SeamTest).
Btw, it's much better to create a chain of requests inside of a single method than to use dependent test methods. Dependent test methods are really quite evil (with the occasional exception).
Perhaps we can brainstorm what the API might look like in this thread and flesh it out some.