A set of tests demonstrating the various types of test that may be required for generated code. Uses Arquillian container and client tests with embedded JBoss Wildfly server.
Tests a very simple application. Screen displayed to allow a username and password to be entered. User is validated against a database; if it exists, the password is then validated. If all is good, user gets a welcome message back.
As this runs in a container to facilitate JPA persistence, Arquillian will provide the 'in container' testing as well as driving Selenium tests on the UI.
| Test | Description |
|---|---|
| DataAccessTest | Purely tests the data layer. Not really required in database, but will use JPA/JTA persistence, so container is required to inject the entity manager and user transaction. 'Before' the tests run, the Java entities are persisted in the 'in memory' H2 database. The simple test then ensures that all 3 entities have been written. |
| BeanandExtensionAccessTest | This tests the EJB that will sit above the persistence layer to ensure it validates the username/password provided correctly. This test utilises the Arquillian persistence extensions to stand-up the data (@UsingDataSet) and manage its lifecyle (@Cleanup). The tests are: persist - makes sure persistence extensions add expected stand-up data testGoodCredentials - tests the content of the data in the H2 database testBadCredentials - Intercepts the expected exception due to username/password being incorrect. |
| MockLoginScreenGrapheneTest | Demonstrates 'Specialized' mocking. This kind of test is useful if a persistence layer isn't an appropriate option. So here the UI references the Mock login bean, which stores the credential data in a Java collection. The Mock bean is a specialisation of the actual bean, which means it completely masks the true EJB in the container. Therefore, when injection is performed into the controller, the specialised bean will be used as it's been made available in the deployment. The test utilises an injected browser (controlled by Selenium libraries), 'types' in the test username and password and then validates output to see if the test has worked. The test itself is '@RunAsClient', which means it runs outside the container (i.e. the deployment isn't decorated by Arquillian to provide in-container facilities). |
| LoginScreenGrapheneTest | This follows the pattern of the above, but uses the true persistence layer. This caused ALL kinds of problems when setting up. Even through it's running in 'mixed-mode' (i.e. at least one test 'RunAsClient' and at least one in the container), there were class loading issues with the WebDriver class in the container even though it is only required on the client. This was overcome by enriching the deployment with the Selenium packages. A 'dummy' test was created to load the data into the H2 database with the Arquillian Persistence extensions and clean-up switched off to ensure data wasn't cleared before next test. |
One key element is that all the test 'plumbing' is performed in the test layer of the project; the true application code is completely test agnostic.
The structure is represented in the following: file system
The files are heavily commented, especially with any of the esoteric things encountered.
It's not big, it's not clever, but it contains the foundations of quite a few important concepts and workarounds.