testng-all.xml #17

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="All Tests" verbose="1" >
    <suite-files>
        <suite-file path="testng-basic-14.1.xml" />
        <suite-file path="testng-basic-14.2.xml" />
        <suite-file path="testng-basic-15.1.xml" />
        <suite-file path="testng-basic-15.2.xml" />
        <suite-file path="testng-basic-16.1.xml" />
        <suite-file path="testng-basic-16.1-ssl.xml" />
        <suite-file path="testng-basic-16.1-nonunicode.xml" />
        <suite-file path="testng-basic-mainline.xml" />
        <suite-file path="testng-proxy-16.1.xml" />
        <suite-file path="testng-servlet-16.1.xml" />
        <!-- This has been disabled until we re-integrate with cloud. -->
        <!--<suite-file path="testng-cloud.xml" />-->
        
        <!-- These have been disabled until we support these clients. -->
        <!--  
        <suite-file path="testng-javascript-16.1.xml" />
        <suite-file path="testng-php-16.1.xml" />
        <suite-file path="testng-ruby-16.1.xml" />
        <suite-file path="testng-python-16.1.xml" />
        -->
        
        <!--
            NOTE: We don't include this as part of our standard test suite, because it requires
            running under elevated privileges (in order to install Git Fusion from packages).
         -->
        <!-- <suite-file path="testng-git-fusion.xml" /> -->
    </suite-files>
    <listeners>
        <listener class-name="com.perforce.hws.testing.reporting.YamlReporter" />
    </listeners>
</suite>

#	Change	User	Description
#17	19803	tjuricek	Setting up the server to be deployable as a servlet, and adding custom "prefix" addition to all routes. It's not completely clear exactly when you'd want to do this, but, you could include the hws.jar in your app server and run this way. This adds a new "servlet example project" that we use to execute a basic test in the new suite.
#16	19645	tjuricek	Create test that uses reverse proxy to mount HWS under "/webservices", and then use the HWS java SDK to access it via that proxy.
#15	19643	swellard	Switch off js/python/ruby/php client tests as part of runAll
#14	19535	drobins	Refactor package names to hws
#13	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.
#12	19281	tjuricek	Adding non-unicode version of the default 16.1 p4d run.
#11	19277	tjuricek	Add self-signed SSL configuration variation (just with the 16.1 p4d) for testing. No bugs were actually uncovered, though it may be useful to debug environments. (If people don't have a properly patched JVM with the JCE extensions, this test will fail.)
#10	19269	tjuricek	Create infrastructure for calling python tests via TestNG, with our first (basic login) test.
#9	19205	tjuricek	Basic infrastructure for PHP testing, and, removing the ps check after startup - seems to be too fast, though the server should be already responding to p4 info commands.
#8	19190	tjuricek	Ruby Client SDK test reconfiguration and tests for branches, login, p4d configuration
#7	19055	tjuricek	Yet another revision: don't exec the GF tests as part of the main run, since they require privileges. We do capture the test report now though.
#6	19054	tjuricek	Re-enabling the git fusion suite within the "test all" step, and, adding some diagnostic messages. Having problems with the simulation mechanism, so I need to figure out what's going on in the build server.
#5	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.
#4	19002	tjuricek	Improve API to interact with multiple p4ds. The configuration now requires an explicit setting of what P4Ds HWS can talk to via the 'P4D config dir', where there's a file indicating connection settings per p4d, and importantly, an ID. This is the "server ID" referenced everywhere. Most methods now require a server ID to indicate which p4d to manipulate. In the future, it's likely we will interact with multiple p4d instances on some services. This completely removes the ability to run HWS as a kind of an "open proxy" to whatever p4d you want. Given the nature of the change and the lack of priority, we've removed Helix Cloud testing and disabled several methods from their "Helix Cloud" implementation. These will be relatively easy to bring back, we'll just need a new method from Raymond that lists the "allowed server IDs" that map to the HWS configured server IDs for a particular user. Another notable aspect of this change is the use of JSON Web Token to create our authentication key. We associate this key with an in-memory "session" that contains the P4D tickets we use to authenticate users. The JWT token, by default, is assigned a timeout, which allows HWS to block further access to underlying servers without having to interact with multiple auth backends. If any backend fails with that session, the user will get a 403. If you disable the timeout, you'll need to ensure your clients clear out sessions.
#3	18910	tjuricek	The git fusion tests need to be run with elevated access in order to re-install Git Fusion.
#2	18905	tjuricek	Add Git Fusion environent configuration and testing, and altered the implementation to use the newly defined API. Note: only runs on linux. We use latest GF production for testing and GF packages are linux only. The "integration" is pretty "light" at this point. This does require the test machine to have our package repository setup.
#1	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.