Monday, February 3, 2014

The main purpose of the DistributionValidationTest.java class is to validate contents inside a product distribution. This post will illustrate the main aspects of distribution validation test class and some related information.


Objective


There are seven major distribution validation aspects being covered from  DistributionValidationTest.java class. These are,


1.Validation of jar files inside the product distribution against the LICENSE.txt.
2.Recursive scan to find the occurrence of SNAPSHOT keyword in file names and contents of textual files( eg : .txt, .xsd, etc).
3.Validate duplicate .jar entries inside the  LICENSE.txt  file.
4.Check whether maven variables are properly replaced inside configuration files found in
repository/conf directory.
5.Validate product distribution size against the latest released distribution in the maven repo
6.Identification of duplicate jars inside the distribution pack.
7.Product specific checks - validate sample directory - versions, resources validation


** There are several distinct test cases being developed to cover above major aspects and based on the findings/outputs under each category a summarized report will be generated with all the information included.  You can navigate to .. /target/DistributionValidationTestReport.txt to find the report.


Prerequisites


  • XSD (XML Schema Definition) files for configuration files (eg: carbon.xml , axis2.xml) inside repository/conf.  - You can generate these schemas using on-line XSD generators.
  • Latest released version of the product distribution being hosted in maven-repo.


Description


1. Validation of jar files inside the product distribution against the LICENSE.txt
           - The implemented test case is capable of identifying the .jar files which resides inside the xxx/repository/components/plugins directory against .jar file names mentioned in the carbon_home/LICENSE.txt file.  Firstly it will derive all .jar file locations inside the plugins directory and match these against the LICENSE.txt file to identify missing jars.  


2. Recursive scan for occurrence of SNAPSHOT keyword in file names and contents in textual files (.txt, .xml, etc).
           - The test will perform a recursive scan in-order to identify occurrences of the keyword “SNAPSHOT” inside the textual files and in their names. If an occurrence/s found the test will encounter a failure at the relevant assert statement.


3. Validate duplicate entries in LICENSE.txt file.
           - Test case will search for duplicate  .jar file names (If the same name is appearing more than once) in the LICENSE.txt file. These file names will be stored using a collection interface and finally the test case will output these .jar file names to the report.


4. Checking whether Maven variables are properly replaced inside configuration files found inside repository/conf
          - The test case will check for maven variable replacements by performing xml schema validation techniques. The user of the test case need to provide the xsd (XML Schema Definition) files of corresponding xml’s need to be checked. Mainly the test case will focus on the ’ $ ’ marks (these are the tags expected to update at the build time) in the XSD files and validate the relevant XML file for updation of each tag attribute value.


5. Validate product distribution size against the latest released distribution in the maven repo
         - The intention of this test case is to validate the running distribution size against the latest released distribution pack’s size. The test case will access the relevant maven repo and seek for the latest distribution hosted in it. Next It will retrieve the size of the distribution hosted and evaluate it with the running distribution’s size.
(Note: you need to make sure once a released been done , the distribution pack should be hosted in the repo. Size comparison will be based on pre-accepted value range for all wso2 products.


6. Identification of duplicate jars inside the distribution pack.
        - Test case is designed using a special regular expressions to derive the version of every .jar file and identification of duplicate .jars inside the pack. Based on the findings of the test case .jar file locations will be printed in the report file under two categories namely,  duplicate jar files in the same directory and with different versions inside the distribution.


7. Product specific checks for whether samples/resources are properly packaged
           - For this purpose the test case will perform some specific scans inside each samples directory and verification will be carried out to confirm that top most level sample directories does not carry any versions with their names. In addition the test case is capable of identifying k whether samples directory (if exists) has a README.txt/pom.xml/build.xml at the same level where src directory exists and to check whether resources directory (inside the src) contains any files.   





No comments:

Post a Comment