ARQ-1204

[jmnarloch]

I could have something that might interest you :-)

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #22 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #23 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #24 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[lfryc]

Fantastic job, Jakub!

Few questions/comments:

• could you rebase changes on latest master? I can see pull request containing commits from history
• what's intention of WarpRuntime? Does it serve same purpose with Warp class?
• MethodMatcherBuilder can use HttpMethod "enum" instead of String
• could you add sample of usage to https://github.com/arquillian/arquillian-extension-warp/blob/master/api/src/test/java/org/jboss/arquillian/warp/TestExecutionAPI.java ?

[jmnarloch]

could you rebase changes on latest master? I can see pull request containing commits from history

Yeah. That was the first and the last time I was doing rebase through InteliJ ;)

what's intention of WarpRuntime? Does it serve same purpose with Warp class?

I wanted to fully seperate the implementation from the interface/API so I "inject" the implementation at runtime. Of course I could seperate that completly from the WarpClientActionBuilder, but I thought that it would be nice to have one extension class to which all API classes can delegate.

MethodMatcherBuilder can use HttpMethod "enum" instead of String

It does. :)

could you add sample of usage to https://github.com/arquillian/arquillian-extension-warp/blob/master/api/src/test/java/org/jboss/arquillian/warp/TestExecutionAPI.java ?

Sure.

Beside that I would like to introduce HttpHeaderFilterBuilder and implement not() function, that could be used as fallows:

request().url().contains("flavice.ico").not();

[lfryc]

I wanted to fully seperate the implementation from the interface/API so I "inject" the implementation at runtime.

We do that with Warp, and tbh it doesn't matter if Warp delegates to WarpRuntime which gets populated at runtime or Warp is populated directly - both classes needs to be part of API anyway.

The only we could do would be use Service pattern, something like this: https://github.com/lfryc/arquillian-extension-warp/blob/ARQ-937/spi/src/main/java/org/jboss/arquillian/warp/spi/LifecycleManagerStore.java#L134

request().url().contains("flavice.ico").not();

Cool - just have in mind that it could be better readable: request().url().not().contains("favicon.ico")

[jmnarloch]

We do that with Warp, and tbh it doesn't matter if Warp delegates to WarpRuntime which gets populated at runtime or Warp is populated directly - both classes needs to be part of API anyway.

The only we could do would be use Service pattern, something like this: https://github.com/lfryc/arquillian-extension-warp/blob/ARQ-937/spi/src/main/java/org/jboss/arquillian/warp/spi/LifecycleManagerStore.java#L134

JAX-RS give me the inspiration for creating the runtime delegate:
https://github.com/resteasy/Resteasy/blob/master/jaxrs/jaxrs-api/src/main/java/javax/ws/rs/ext/RuntimeDelegate.java

So overall this is similar way of achieving the same goal. I just prefer to have single extension point rather to separately set all the classes: for example Warp and separately HttpFilters and so on.

Cool - just have in mind that it could be better readable: request().url().not().contains("favicon.ico")

Consider it done.

[lfryc]

JAX-RS give me the inspiration for creating the runtime delegate

Ok, let's go ahead and make this happen!

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #25 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #26 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #27 SUCCESS
This pull request looks good
(what's this?)

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #28 SUCCESS
This pull request looks good
(what's this?)

[jmnarloch]

Ok. I'm done.

First test running builder API got a green bar ;)

Warp
            .execute(new ClientAction() {
                public void action() {
                    browser.navigate().to(contextPath + "index.html");
                }
            })
            .filter(request().uri().not().contains("favicon.ico"))
            .verify(new ServerAssertion());

[lfryc]

Fantastic, Ike loves green bars! :-)

[lfryc]

The build() method is not necessary as I can see from BasicWarpTestm right?

[jmnarloch]

A, right I made the example before adding the overloaded filter() method.

[lfryc]

Could you please create one unit test for request builder and one for URI matcher?

---

It looks awesome, this is huge addition and we will soon stretch its muscles in REST extension!

Looking forward for that! :-)

[buildhive]

An Innovative Testing Platform for the JVM » arquillian-extension-warp #29 SUCCESS
This pull request looks good
(what's this?)

[lfryc]

Thanks for this fantastic feature, Jakub!
It was merged to master.