[lfryc]

Hey Jakub, the ClientAction states that you provide one client action (even complex ones) which leads to single request.

So in your use case, you have two actions which leads to two separate requests and you need to provide two ServerAssertions (you can certainly re-use one object).

[lfryc]

Jakub, could you clarify why you have not used @ArquillianResource finally (used @SpringMVCResource)?

The issue was that when you used @ArquillianResource then the assertion wasn't serializable?

[jmnarloch]

Lukáš Fryč wrote:

Hey Jakub, the ClientAction states that you provide one client action (even complex ones) which leads to single request.

So in your use case, you have two actions which leads to two separate requests and you need to provide two ServerAssertions (you can certainly re-use one object).

Thanks. I figured this out.

BTW. I think I have an interesting use case for You. It occured that I can not anyhow test a controller that redirects the response (https://issues.jboss.org/browse/ARQ-992). Currently when the controller redirects the response the test case hangs untill it timeouts on the request. This is caused by the fact that the redirection response does not comes with the PayloadResponse. I've debug the WarpFilter and when the setHeader was called, the Warp header was not added. The internal collection of headers hasn't been changed for 302 HTTP status response (I do not know whether this is HTTP standard issue or rather implementation one).

The assertion isn't registered with the second request the one wich is send to redirected address, so either way I can not test the initial request or the redirected request.

[jmnarloch]

Lukáš Fryč wrote:

Jakub, could you clarify why you have not used @ArquillianResource finally (used @SpringMVCResource)?

The issue was that when you used @ArquillianResource then the assertion wasn't serializable?

This was a warkaround for now - we can change that in future. I wasn't abble to use the @ArquillianResource anyhow, this was related with the bug reported last week. I tried to simply use it with my custom TestEnricher, but any field that was annotated with ArquillianResource, not only the URL, was causing a serialization problem.

[jmnarloch]

Lukáš Fryč wrote:

Jakub, could you clarify why you have not used @ArquillianResource finally (used @SpringMVCResource)?

The issue was that when you used @ArquillianResource then the assertion wasn't serializable?

I was thinking, is ResourceProvider is going to be actually helpfull here? The ResourceProvider was designed to suport only one type at a time, so clearly it is going to be quite inconvenient to implement using it support for multiple types.

{code}
public interface ResourceProvider
{
   boolean canProvide(Class<?> type);
   Object lookup(ArquillianResource resource, Annotation... qualifiers);
}
{code}

[jmnarloch]

BTW. The Warp Spring MVC extension has been merged with the Arquillian Spring Extension and will be avaible with next (probably Alpha 2) release.

[lfryc]

Great job, Jakub!

I would like to shape the Warp Alpha2 too, so let me know if you have anything what should go into that release.

Are you going to highlight Warp integration in a release blog?

[jmnarloch]

Hi,

Lukáš Fryč wrote:

I would like to shape the Warp Alpha2 too, so let me know if you have anything what should go into that release.

I was thinking about one thing in particual, does Warp currently triggers the BeforeClass/AfterClass events? They are currently used by the Spring extension enrichers for injecting beans configured with application context.

Lukáš Fryč wrote:

Are you going to highlight Warp integration in a release blog?

Definetly, planning to do that with next release, but the exact date isn't yet set.

[lfryc]

Hey Jakub,

you mean using @BeforeClass / @AfterClass in ServerAssertion?

What would be semantics? Before/after the first/fast test in ServerAssertion is triggered?

What are use cases?

Aren't @BeforeServlet and @AfterServlet better alternatives?

[jmnarloch]

Let me a bit clarify my idea, we have two extensions at the moment, the Arquillian Spring Extension for injecting Spring beans and Warp Spring Extension. The thing is that the first one needs to be configured with annotation in order to create the application context. Like for example:

{code}
@RunWith(Arquillian.class)
@SpringConfiguration("applicationContext.xml")
public class DefaultEmployeeRepositoryTestCase {
}
{code}

The initialization currently works that way that it awaits for the BeforeClass event triggered by Arquillian and then retrieves the information of the test class from it. Question is if the Warp is also triggering that events before executing the ServerAssertion? Without them it won't be possible to inject Spring beans into the ServletAssertion. This is only the matter of internal implementation, so I don't want to itroduce any new features in the Warp API.

I'm asking becouse the annotation @SpringWebConfiguration, which was implemented already with the first milestone, perfectly feets for working with Warp. One could use it to annotate the ServletAssertion and inject any beans of the tested DispatcherServlet.

[jmnarloch]

I just came accross the LifecycleTestClassExecutor in Warp Impl:

{code}
public class LifecycleTestClassExecutor {
    private LinkedHashSet<Object> executedAssertions;
    @Inject
    private Event<BeforeClass> beforeClass;
    @Inject
    private Event<AfterClass> afterClass;
    public void beforeRequest(@Observes BeforeRequest event) {
        executedAssertions = new LinkedHashSet<Object>();
    }
    public void beforeTest(@Observes(precedence = 100) EventContext<Before> context) {
        Object assertionObject = context.getEvent().getTestInstance();
        if (!executedAssertions.contains(assertionObject)) {
            executedAssertions.add(assertionObject);
            beforeClass.fire(new BeforeClass(assertionObject.getClass()));
        }
        context.proceed();
    }
    public void afterRequest(@Observes(precedence = 100) EventContext<AfterRequest> context) {
        List<Object> list = new LinkedList<Object>(executedAssertions);
        Collections.reverse(list);
        Iterator<Object> iterator = list.iterator();
        while (iterator.hasNext()) {
            Object testInstance = iterator.next();
            afterClass.fire(new AfterClass(testInstance.getClass()));
        }
    }
}
{code}

So cool! It looks like already with Warp Alpha 1 it is possible to autowire any bean from the application context of the selected Dispatcher servlet:

{code}
   @SpringWebConfiguration(servletName = "welcome")
    public static class WelcomeControllerVerification extends ServerAssertion {
        private static final long serialVersionUID = 1L;
        @SpringMvcResource
        private ModelAndView modelAndView;
        @Autowired
        private EmployeeService employeeService;
        @AfterServlet
        public void test() {
           // TODO test
        }
    }
{code}

[lfryc]

Awesome work!