2 Replies Latest reply on Feb 24, 2010 6:14 AM by Pete Muir

    Requester API

    Dan Allen Master

      One 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:


      public void testChangePassword() throws Exception {
         new FacesRequest() {
            protected void invokeApplication() throws Exception {
               // assume the database is seeded already
               setValue("#{identity.username}", "tenaciousd");
               setValue("#{identity.password}", "rockon");
         new FacesRequest() {
            protected void processValidations() throws Exception {  
               validateValue("#{user.password}", "xxx");
               assert FacesContext.getCurrentInstance().isValidationFailed();
            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);


      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.

        • 1. Re: Requester API
          Aslak Knutsen Master

          I'm glad you bring this up, we need a plan on how to interact with the different technologies/frameworks.


          One my personal mission statements with Arquillian is to make the test case feel as close to what your trying to test as possible.

          When dealing with EJB/CDI this can be achieved by annotation support for @Resource/@EJB/@Inject/@TransactionAttribute etc..


          I havn't really given it to much thought yet, but I've been a bit puzzled by how to create the same feel for a Http/Servlet(jms as well) test.


          (just a initial comment to say, yes I've read the post, and yes we should figure something out )

          • 2. Re: Requester API
            Pete Muir Master
            This doesn't belong in Arquillian, but in the "jsf test" project that Alex Smirnov is doing as part of RichFaces 4 (yes, it needs a name). We'll definitely make it easy to use this project in Arquillian!