Thoughts on client storage testing

[Tom Zeller]

As I mentioned on the last dev call, I’m wondering how to add testing client storage to the existing tests in java-idp-integration-tests. I have an idea of what to do, and thought I wound bounce it off the list.

The idea is to run the existing tests with (a) local storage toggled on|off on the server and (b) local storage toggled on|off on the client. I don’t think the term “decision table” is correct, but I am thinking that (a) + (b) result in running 4 tests.

I am wondering how to implement running those 4 tests, with room to grow for additional “configuration dimensions”. Given TestNG, my thought is to represent (a) and (b) as objects returned by a TestNG DataProvider. With support for Sauce Labs, I introduced a DataProvider which provides a BrowserData object to each test method, where the BrowserData object is a bean with 3 fields : os / browser / version. So a tuple. Next steps would be to (1) add some sort of local storage desired capability to BrowserData, and (2) add another method parameter representing the IdP configuration “dimension”, maybe a ServerData object. The ServerData object would, I guess, have a single field : idp.home.  Test methods would look like :

public void testSomething(BrowserData browserData, ServerData serverData) {
 startSeleniumClient(browserData);
 startJettyServer(serverData);
 testStuff()…

If the DataProvider route is not the right one, another option is to use Java inheritance as the implementation of the “configuration dimension” of the IdP. Right now in the integration tests, Java inheritance is used to represent profile flows (there’s an AbstractSAML2 class with SAML2SSOPOST and SAML2SSORedirect children, etc), so I’m not sure that’s how we should represent the local storage toggle.

I’ll stop there. Hopefully this makes some sense to some one.

Feedback welcome,
Thanks.