testng-cloud.xml #6 

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="2016.1.0 Java SDK - Cloud configuration" verbose="1" >
    <test name="Standard">
        <groups>
            <run>
                <exclude name="no-cloud" />
            </run>
        </groups>
        <packages>
            <package name="com.perforce.hws.testing.p4base" />
            <package name="com.perforce.hws.testing.server" />
            <package name="com.perforce.hws.testing.server.project" />
        </packages>
        <classes>
            <class name="com.perforce.hws.testing.CloudEnvironmentTestSetup" />
        </classes>
    </test>
    <listeners>
        <listener class-name="com.perforce.hws.testing.reporting.YamlReporter" />
    </listeners>
</suite>
# Change User Description Committed
#6 19615 mphillips Reorder XML to Windows Eclipse TestNG likes the ordering.

Trish has tried it out on Mac and it seems fine.
#5 19535 drobins Refactor package names to hws
#4 19338 tjuricek Create custom reporting mechanism to allow for clear "multiple suite" reports...
with logging!

This standardizes on log4j 2 as the backend (was just used on the server side). We have an "in memory appender" that we use to capture results during testing, which we associate with each method run.

The whole system spits out yaml files for each suite run, which are then read in via a final task and a single html report is spit out with ... everything... in it.
#3 19053 tjuricek Rebuild JavaScript Client SDK.

The JavaScript client now is a "typed" approach that tends to be similar in approach to the other clients, based on the swagger definition for the platform version.

Importantly, client SDK tests are individual scripts (that run under node) that are actually controlled via TestNG. This approach now lets us use a consistent test reporting format so we can at least collect reports from each of the jobs.

The documentation is still in progress, that I want to validate as the tests are generated.
#2 18846 tjuricek Added test setups for p4d versions going back to r14.1.

There is now a big single testng test suite that runs through most of these variations.

I've switched to using the p16.1 builds by default, which can easily be switched to the r16.1 builds.
Mainline p4d builds are still in use, since they are informative.
We may want to not use those on candidate line runs, however.
#1 17140 tjuricek Integrating porting work from development branch.

This work is now ready for testing/CD integration.