@RunAsClient && access to server for bootstrap

[oehmsmith]

Hi All,

I need to configure the service that is run in a JAX-RS test run with @RunAsClient.

I inject the Service and set values in a @Before but the service that is being used in the client test is a different instance.  Is there a way to have a reference to the service that is used?

Thanks,

Brooke

@RunWith(Arquillian.class)
public class RestTest() {
    @Inject
    HistoricalAlertService historicalAlertServiceSUT;

    @Deployment
    public static Archive<?> createDeployment() {
        return new BaseDeployment(ProjectType.WAR) {
            {
                jar.addClasses(AlertPersistService.class, HistoricalAlertService.class);
                jar.addClasses(AlertHistQueryParams.class);
                jar.addClasses(AllAlert.class);
                jar.addClasses(ApplicationConfig.class);
            }
        }.build();
    }

    @Before
    public void init() {
        // For the @RunAsClient, the server-based variables will be NULL
        if (historicalAlertServiceSUT != null) {
            // force it to use the JPA @NamedQuery instead of the @NamedNativeQuery
            historicalAlertServiceSUT.setFindRangeQuery(AllAlert.findRange);
        }
    }

    @Test
    @RunAsClient
    public void test02Service_01_parameterArgCorrect(@ArquillianResource URL deploymentUrl) {
        DateUtils dateUtils = new DateUtils();
        AllAlertTemplate aat = new AllAlertData02(dateUtils);

        String queryString = String.format("queryType=range&from=%s&to=%s", dateUtils.UTC_DATE_ARG_FORMAT.format(aat.getFromDate()),
                dateUtils.UTC_DATE_ARG_FORMAT.format(aat.getToDate()));
        String target = deploymentUrl.toString() + RESOURCE_PREFIX + "alertHist/json?" + queryString;
        System.out.println("    test target:" + target);
        Client client = ClientBuilder.newBuilder().register(JsonProcessingFeature.class).property(JsonGenerator.PRETTY_PRINTING, true).build();
        WebTarget path = client.target(target);
        Response response = path.request().get();
        JsonObject json = path.request().get(JsonObject.class);
        assertNotNull(json);
        System.out.println("Json:" + json);
        System.out.println("Response: " + response.getStatus());
        assertEquals(2, json.getJsonArray("alerts").size());
        assertEquals(200, response.getStatus());
        preventDBCleanup = true;
    }
}

[oehmsmith]

No response???

Does this mean that Arquillian and it's brethen provide no way to access the server that the clients run on?

[kwintesencja]

Hi there, client tests are by definition a black box, they only see what was deployed in your deployment.

a way to workaround this is to deploy your service already configured with findRangeQuery. Another way is to make your findRangeQuery configuration based on a property file só when you run your tests you deploy an specific configuration.properties(witth findRangeQuery = alert, for example.)

maybe it heps.

[oehmsmith]

Thanks for your reply Rafael,

I thought access to the server would be possible as in other tests (and this one, but I didn't show it), I have @Tests that proceed the @RunAsClient one and setup the database on the server for the server component to use.  Thus I thought more access to the server would be available.

I followed the idea of your suggestion and setup a bean to hold the value of the query to be used and supplied a specialized version of the class just in testing.  This works well.  I think I could have used a specialized producer to avoid needing to create an entire class or two just for this purpose.  I'm okay with it as a bean.

public class HistoricalAlertService {
    ...
    @Inject AllAlertQueryChoice allAlertQueryChoices;
   
    public AlertsDTO getAlertHist(...) {
          ...
          queriedAlerts = alertService.findWithNamedQuery(allAlertQueryChoices.getFindRangeQuery(), parameters);
          ...
    }
}

public class AllAlertQueryChoice {
    private String findRangeQuery = AllAlert.findRangeNative;
    // setter and getter
}

The Specialized version is defined and used just for testing.

@Specializes
public class AllAlertQueryChoiceSpecialization extends AllAlertQueryChoice {
    @PostConstruct
    public void init() {
        this.setClassification(Classification.jpaQuery);
        this.setFindRangeQuery(AllAlert.findRange);
    }
}

I'm much happier now!  Though I still need to work out why JPA (EclipseLink) can't optimize the @NamedQuery properly and thus require me to create a Native version.  This is a question for somewhere else ...

Cheers,

Brooke

[bmajsak]

Wouldn't Arquillian Warp be a help in this case too?

[oehmsmith]

I've yet to use Warp though I thought it was a UI Functional testing tool.  No?

[bmajsak]

Wrong Warp is intended for so called gray-box testing, which let's test from the outside, but gives you access to the internals, so you can execute some fixtures or verifications on the server side. Historically it started with JSF support in mind, but it's way more than that.

[oehmsmith]

Sounds like just what I needed.  I've worked around it which will suffice for now, but should I need to do something like this again I'll give Warp a try.

Cheers,

Brooke