Fitnesse testing is the most commonly used testing framework which allows collaboration with developers, end customers and testers in writing their own test cases and evaluating the quality of application/piece of code. The test cases can be easily designed and also maintained with ease. This framework testing tool is more versatile because it allows other testing methodologies to get implemented in it.

EDI

EDI (Electronic Data Interchange) is an organized exchange of data or documents between Organizations or Business through Electronic means. EDI benefits all business processes more structured, rendering discernibility & easy to understand across the entire business when connected via broader trading partners.

For making EDI technology communication successful across all businesses when connected, Integration between all business systems becomes mandatory. Upon successful EDI integration implementation, we need to maintain the integrated system for any further improvements and scaling the business.

Implementing Fitnesse Testing in EDI Integration

EDI Integration environment consists of trading partner flows which handles both inbound and outbound traffic of EDI documents. These trading partner flows will contain EDI Maps which transform data from one EDI format to another EDI format. EDI formats can be available in any standard such as ANSI X12, EDIFACT, SAP iDoc etc or proprietary formats like CSV, Flat File, Delimited etc.

EDI Fitnesse testing – Setup & Execution

EDI Maps once created will have to undergo modifications depending on business needs. When injecting any changes in already existing and successfully running PRD maps, the EDI maps needs to be performed with a comprehensive testing either by EDI Test engineers or business team. These manual tasks will take more time than normal and also prone to miss certain scenarios that might cause PRD bugs. PRD bugs can be so serious that it will take a hit in revenue across all businesses that are connected through maps.

These bugs can be made near zero using the Fitnesse testing tool. EDI maps when needed can be done in a test environment and we have a successful running PRD version which takes care of PRD traffic. EDI mapping changes are reflected in the Test environment only. We need the below set of artifacts in order to set up an EDI fitnesse testing suite.

• Input files – The set of files that forms as an input to the map which has been changed.
• Expected Output files – The set of files that is derived as output for the PRD map version. These output files will not hold any ongoing map changes. This should be saved in a separate file location.

In order to perform Fitnesse testing, we should execute the below equation to get the exact impact of mapping change to particular maps. Fitnesse testing should perform below set of steps

• Input files should be made to run against the Test map version and their output file needs to be saved in a file location. These output files are called “Actual Output” files.
• Expected output stored in a separate file location while fitnesse testing setup should be compared with “Actual Output” files received from previous step and compared.
• “Expected Output” Vs “Actual Output” should be compared and a report file can be generated.
• This report file should show the differences only pertaining to induced mapping changes. If there are any other changes seen apart from included mapping changes, this will have an impact on the existing PRD system.

EDI Fitnesse Testing – Impact Analysis – Differences

While analysis the differences generated in report file – outcome of fitnesse testing, we can classify the differences broadly into two types

• Acceptance/Known differences: These differences are permissible differences like datetime stamps etc as “Expected Output” files will be obsolete, which will obviously be different from the date time stamp present in “Actual Output” files.
• Non acceptable differences: These differences are completely not allowed. This can be any extra value added, encoding differences, extra looping created etc. These differences will provide the exact impact to the EDI system when mapping change is done.

EDI Fitnesse testing – Best practices

The success of comprehensive Fitnesse testing belongs to test coverage using “Expected Output” files. When complete scenarios are covered up in Expected output files, it provides the exact impact to the existing PRD traffic due to change requirements

However, it is not possible to mock up test files or pull PRD test files as certain EDI systems will have very low volume PRD test files either due to business scale or their archiving policy.

Hence it is better to build a “Dedicated EDI Fitnesse Test suite”.

This Dedicated fitness test suite needs to have a bunch of test files which covers all possible scenarios in a given EDI format. Moreover, this dedicated test suite once set should be improvised from time to time through available EDI engineers. Constant improvisation should be framed as a process within EDI engineers who are taking care of EDI integration. This will help in maturing “Dedicated Test suite” a complete one and can be reused for all changes induced in any maps inside that EDI Integration platform.

EDI Fitnesse Testing – Benefits:

• Extensive Test coverage: Quantitative testing through multiple EDI test files for improvised quality will be more time consuming and also will prone to miss certain scenarios that can in turn induce PRD bugs. This fitnesse testing will result in the same time if we test with min and/or max no of test files with qualitative test results. In turn, if the EDI test files coverage is constantly increased for each file format and Doc types from time to time, the overall fitnesse testing suite can be considered as the best quality testing for that particular EDI transaction.
• Less EDI Test Engineers: Once fitnesse setup is all set with required info, we need lesser EDI testers when compared to the one without help of fitnesse suite. EDI Testing engineers job will be made easy with the report file generation and makes testers to focus only with test files which are throwing differences and ignore rest of the files. At some instances, we can involve only EDI Business analysts who can run the fitnesse suite and we don’t need to plan for EDI testers.
• Fitnesse Testing usage across diff EDI project types: Considering different EDI project types, like EDI Migration from Legacy servers to cloud, EDI Tool migration from one EDI tool to another EDI tool, Upgrading EDI tool version, we can use this EDI Fitnesse testing to get exact impact analysis due to the migration activities. Moreover, Fitnesse testing when used can reduce EDI testers and also with archiving features, a history of fitnesse testing reports can be accessed to study the overall migration activity.