Designing tests - 6.3

Talend Software Development Life Cycle Best Practices Guide

EnrichVersion
6.3
EnrichProdName
Talend Big Data
Talend Big Data Platform
Talend Data Fabric
Talend Data Integration
Talend Data Management Platform
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Real-Time Big Data Platform
task
Administration and Monitoring
Deployment
Design and Development
EnrichPlatform
Talend Administration Center
Talend Artifact Repository
Talend CommandLine
Talend Repository Manager
Talend Studio

While designing the processes (Jobs and Routes), developers need to think of how to test them: Talend recommends you to use the Test Case feature: it automatically creates a Test Case with a skeleton in a Test Instance.

A Test Case is an executable test that consists of an immutable part extracted from the initial Job or Route, along with other editable components that form the skeleton of the Test Case.

A Test Instance is a set of data that allows you to run the Test Case with different parameters that you define (input, reference files, etc.).

For more information, see the Talend Studio User Guide.

Best practices:

  • It is recommended to create and use a context adapted to your environment (a Test context to execute test Jobs with the metadata of this environment, and a Production context to execute Jobs in the Production environment).

  • When the feature is designed and tested, it is recommended to use Talend Repository Manager to pass items to the QA environment. See Continuous Integration: Deploying to QA and Production environments for more information.

Example 1. Creating a Test Case based on a Job

A Job called job_load_California_clients is created in a project called ci_project. The Job aims at reading a .csv file containing a list of clients living in California, matching these clients with those coming from the Orange county of Los Angeles using a tMap component, before uploading the result into a MySQL database.

The processing part (tMap) is used to create a Test case called test_process_client_file and will allow developers to test, filter and map any types of input and output files.

Note that the generated skeleton depends on the component(s) selected in the Job to create the Test. Here, the Test case aims at:

  • reading input data files (tFileInputDelimited components),

  • transforming data with an immutable set of components (INPUT and OUTPUT items) based on the initial Job,

  • writing the output data (to a tFileOutputDelimited component),

  • comparing the temporary output file (tCreateTemporaryFile component) to a reference file you need to define, using a tFileCompare component,

  • generating the Test execution status (OK if it succeeds, Fail if it fails) using a tAssert component.

Note that you can add as many instances of tests as you need, which means you can run the same test with different input and reference files.

The Test Case is ready to be executed once the data set has been defined in the Test Case view, and a specific context group (called Test) has been defined in the Context view. The data set consists of data files that you define as input and reference files to test your data.

The Test Case was successfully executed on the Test Instance and the input and reference files are identical.


Once developers have designed the integration tests locally in the Studio, these tests need to be automated with continuous integration tools such as build systems. For more information, see Continuous Integration: Executing Tests.

Example 2. Creating a Test Case based on a Route

This example applies only to users of Talend products with ESB.

A Route called route_file is created in a project called ci_project. The Route aims at reading a file before converting its content to String rows, splitting it line by line and outputting the result in a log file.

The processing part (cConvertBodyTo and cSplit) is used to create a Route Test case called test_route_file and cMock components are used to simulate message generation and message endpoints, allowing developers to test and map any types of input and output messages.

For more information on the Route Test Case creation, see the Talend Studio User Guide.

Note that the generated skeleton depends on the component(s) selected in the Route to create the Route Test. Here, the Test case aims at:

  • generating test message exchanges and reading input test data (cTimer and cMock_1 components),

  • transforming data with an immutable set of components (INPUT and OUTPUT items) based on the initial Route,

  • checking that messages have been routed as expected and validating the Test output result (message content, count, header, etc.) using the cMock_2 component.

Note that you can add as many instances of tests as you need, which means you can run the same test with different input and reference files.

The Test Case is ready to be executed once the data set has been defined in the Test Cases view. The data set consists of data files that you define as input and reference files to test your data.

The Route Test Case was successfully executed on the Test Instance and the input and reference files are identical.