In Agile Projects using Java/JEE, the focus and scope of the Developer Testing is usually diminished to either Unit Testing or very basic Functional Testing. Arquillian brings in a newer thought process of Integration and Acceptance Testing, which includes Continuous Integration and Testing even within the JEE Container. Especially for JEE Products or Solutions that require functionalities to be Tested across various Containers - this provides the most Productive way. According to the Internet, Arquillian was also the "Duke's Choice Award for Developer Productivity at JavaOne Conference 2011". In my experience, it not only enhances productivity of the Developers but also promotes Good Practices.
It allows you to convert your TestNG or JUnit (Among Others) Test Cases into Arquillian Test Cases with few changes. Also, it allows you to directly use CDI in your test code. This allows you to inject dependencies such as EJB or Web Services directly in your test cases. The central thought process involved in using Arquillian is the ShrinkWrap API provided by it. It allows you to package your product/project code into Archives like JAR, WAR and EAR. Along with the project code that is to be tested, the test cases are also packaged. It then allows multiple Maven Configurations to allow direct deployment into one of these modes (that we used for our product):
1. Outside Container
By allowing Weld-EE container Arquillian Maven Profile, we are in effect allowing an 'Outside Container' testing environment. This should be helpful in Large, Unwieldy projects or products to get over a 'Saturation or Complexity Point' in Logic or Functionality Development. There are a few limitations of this profile, that the developer may not be able to inject container resources like Managed Thread Factories, Data Sources or Cache Containers. The Developer can go building all the logic, functionality and do both the Unit Testing/Integration Testing with other components of the product - until the time there is a need to inject resources that are not provided by this profile. The guideline for usage of this profile should ideally be the very 'initial' development phase of a sprint story.
2. Remote Container (Managed Container)
By allowing either of these Arquillian Maven Profiles, we are in effect allowing an 'Inside the Container' testing environment. Once we are over the initial phase of a sprint story, the Continuous Integration cycle should now involve Integration Testing with other product components on a daily basis. This also includes changing requirements and possibly Regression during the Sprint Cycle. Also, there is a need to start testing with all container resources available. This should be the possible point, that you either start using the Remote or the Managed Container. The ShrinkWrap allows you to directly connect to local or remote host servers to deploy the created or testable Archive. This is done by providing an Arquillian Configuration File. It supports a variety of JEE Container Profiles - Wildfly, JBoss, Glassfish, Websphere, Weblogic and Tomcat (Among Others). By allowing Continuous Integration Testing with other Components, we catch Integration Defects very early in the cycle. In a way, it matches the punchline of Arquillian - "So you can rule your code. Not the bugs." or "Death to all Bugs!". Also, providing a way of Developer Regression Testing Suite, it allows to go ahead safely with the changes in the Product. It also automatically promotes good practices, by not allowing any thought processes to be lost during the development - and allowing developers to write more test cases - that start testing Regression effectively and allow more Functionality coverage. The guideline for usage of this profile should ideally be the 'middle to end' development of a sprint story.
3. Embedded Container
Now, we are through with the 'initial' and even the 'middle to end' cycle of our Development. But all throughout this, there could be a central or nightly build running at the Product Level. The Embedded Container would be the most suitable in my experience, to automatically start off the Container, deploy the ShrinkWrap and do all the Integration Test (Regression as Well). By doing this on a daily basis - In scheduled Product Builds or Nightly Builds - the Confidence Level on the Product Code increases by a very high magnitude. When testing across containers, it should reduce Developer/Tester effort by appreciable levels. Also, the manual task of actually deploying and testing across containers is not required. The guideline for usage of this profile should ideally be the 'nightly builds' for a sprint.
For all of the above profiles, TestNG or JUnit Test Reports are created - which allows you to understand the outcomes better. Also, in most products, the development cycle that is followed by individual developers on their systems is equivalent to:
With Arquillian, in effect the daily cycle is shortened to:
[I am working on a Leading Client Automation Product - Java/JEE - The above guidelines are based on my Evaluation of Arquillian for this fairly Large and Complex Product that is actually Installed on a Desktop OS/Server OS. We require the use of only JEE Container - Wildfly. These facts are based on Arquillian 1.1.7, Wildfly 8.0, Java SE 7 and Java EE 6]
It allows you to convert your TestNG or JUnit (Among Others) Test Cases into Arquillian Test Cases with few changes. Also, it allows you to directly use CDI in your test code. This allows you to inject dependencies such as EJB or Web Services directly in your test cases. The central thought process involved in using Arquillian is the ShrinkWrap API provided by it. It allows you to package your product/project code into Archives like JAR, WAR and EAR. Along with the project code that is to be tested, the test cases are also packaged. It then allows multiple Maven Configurations to allow direct deployment into one of these modes (that we used for our product):
1. Outside Container
By allowing Weld-EE container Arquillian Maven Profile, we are in effect allowing an 'Outside Container' testing environment. This should be helpful in Large, Unwieldy projects or products to get over a 'Saturation or Complexity Point' in Logic or Functionality Development. There are a few limitations of this profile, that the developer may not be able to inject container resources like Managed Thread Factories, Data Sources or Cache Containers. The Developer can go building all the logic, functionality and do both the Unit Testing/Integration Testing with other components of the product - until the time there is a need to inject resources that are not provided by this profile. The guideline for usage of this profile should ideally be the very 'initial' development phase of a sprint story.
2. Remote Container (Managed Container)
By allowing either of these Arquillian Maven Profiles, we are in effect allowing an 'Inside the Container' testing environment. Once we are over the initial phase of a sprint story, the Continuous Integration cycle should now involve Integration Testing with other product components on a daily basis. This also includes changing requirements and possibly Regression during the Sprint Cycle. Also, there is a need to start testing with all container resources available. This should be the possible point, that you either start using the Remote or the Managed Container. The ShrinkWrap allows you to directly connect to local or remote host servers to deploy the created or testable Archive. This is done by providing an Arquillian Configuration File. It supports a variety of JEE Container Profiles - Wildfly, JBoss, Glassfish, Websphere, Weblogic and Tomcat (Among Others). By allowing Continuous Integration Testing with other Components, we catch Integration Defects very early in the cycle. In a way, it matches the punchline of Arquillian - "So you can rule your code. Not the bugs." or "Death to all Bugs!". Also, providing a way of Developer Regression Testing Suite, it allows to go ahead safely with the changes in the Product. It also automatically promotes good practices, by not allowing any thought processes to be lost during the development - and allowing developers to write more test cases - that start testing Regression effectively and allow more Functionality coverage. The guideline for usage of this profile should ideally be the 'middle to end' development of a sprint story.
3. Embedded Container
Now, we are through with the 'initial' and even the 'middle to end' cycle of our Development. But all throughout this, there could be a central or nightly build running at the Product Level. The Embedded Container would be the most suitable in my experience, to automatically start off the Container, deploy the ShrinkWrap and do all the Integration Test (Regression as Well). By doing this on a daily basis - In scheduled Product Builds or Nightly Builds - the Confidence Level on the Product Code increases by a very high magnitude. When testing across containers, it should reduce Developer/Tester effort by appreciable levels. Also, the manual task of actually deploying and testing across containers is not required. The guideline for usage of this profile should ideally be the 'nightly builds' for a sprint.
For all of the above profiles, TestNG or JUnit Test Reports are created - which allows you to understand the outcomes better. Also, in most products, the development cycle that is followed by individual developers on their systems is equivalent to:
Code > Build > Deploy > Test > Fix > Deploy > ... [Code]
With Arquillian, in effect the daily cycle is shortened to:
Code > Fix > ... [Code]
The above caters to Integration Testing and Regression Testing. But once we decide on Arquillian in our Products or Solutions - making it inherent part of the Agile Planning Processes, we should enter into a TDD driven approach for Acceptance Testing as well. The pre-planning, planning process - which includes story identification, estimation and work distribution - could trigger off the initial activity of Identifying Acceptance Tests. These Acceptance Tests should be 'accepted' or 'signed off' by the Architect/Reviewer/Owner. So, in effect, though there can be modifications/additions/subtractions - the Acceptance Test should start becoming the final 'sign off' for the successful delivery of the Sprint Story. With Arquillian, this ATDD approach - can be easily implemented or automated. The actual Implementation of these Acceptance Tests will happen during the Sprint Cycle. The Sprint Deliverable that is now available to the Testing Team of a Product for the next Sprint - is bound to have one very initial but even more thorough level of Functionality Testing complete by the Developers. With Acceptance (and Integration) Testing Reports made Available through Arquillian, the Testers' time is now saved and they will be able to Concentrate on Identifying Diverse, Granular or simply more Thought out Test Cases - In all, increasing Product Quality.
The Salient Features of Arquillian, then, are:
1. Real Tests Inside the JEE Container
2. IDE/Eclipse Friendly Integration Test Cases
3. Test Enrichment/Allowing CDI Directly in Test
The Salient Features of Arquillian, then, are:
1. Real Tests Inside the JEE Container
2. IDE/Eclipse Friendly Integration Test Cases
3. Test Enrichment/Allowing CDI Directly in Test
4. Classpath Control/Isolation - No Environment Bugs!
5. Debug Directly on the Server/JEE Container
6. Container Agnostic/Various JEE Containers Supported
7. Extensible Platform/Support Frameworks like JUnit/TestNG
8. Integration Tests from Maven Builds inside Container
There are other innovations as well in the Arquillian Project - which I have not evaluated - Arquillian Drone and Arquilllian Graphene (As Also JBoss Forge). The first two can be used in Conjunction with Selenium for more Efficient User Interface Testing - This includes integrating with the Web Driver and also generating Graphical Reports or Screenshots during the Automated Testing Process. Also, JBoss Forge allows to generate boilerplate code or configuration using a Command-Line Tool. That is all I know! :-)
[I am working on a Leading Client Automation Product - Java/JEE - The above guidelines are based on my Evaluation of Arquillian for this fairly Large and Complex Product that is actually Installed on a Desktop OS/Server OS. We require the use of only JEE Container - Wildfly. These facts are based on Arquillian 1.1.7, Wildfly 8.0, Java SE 7 and Java EE 6]
No comments:
Post a Comment