19/06/2009

Introducing dstx/wtx unit

Context

At my current client, I work with Datastage Transformation Extender (DSTX) recently re branded Websphere Transformation Extender since it was bought by IBM. To me DSTX looks like a strongly, statically typed functional programming language with added seemingly arbitrary limitations, but that's not the point for today. When I was asked to develop a completely new transformation map for my current project, I immediately thought, cool let's practice Test first, where do I find DstxUnit ? I didn't find it :(

Building DstxUnit

I could have done a small shell framework but I wanted it to both run under Unix (because I intend to make some kind of continuous integration later on) and Windows (developers). However I didn't want to bother with writing 2 shell scripts, also I was really looking forward to getting the green bar. Since DSTX is used for data transformation it is easy to make it take text files as input and write text files as output (you can even override input and output settings of the map for specific runs) So I went the java way (I am used to working with java) and extended a JUnit Testcase which provides runTx and assertTx.

runTx

runTx will take the transformation map name, the file extension for input and output, a test case number for the given map and a flag to know if errors are acceptable or not for this run. With that and a configuration file (to know where the maps are and where the resources are) it will build all the correct paths to run the map and place its output in a know location for comparison (see assertTx). Here is how my files are organized :
project/
  DSTX/
    Map/
     map.mms
     common/
       lib.mms
    Test/
      testmap.mms
      common/
        testlib.mms
      resources/
        in/
          test_map_1.txt
          common/
            test_lib_1.txt
            test_lib_2.txt
            test_lib_3.txt
            test_lib_4.txt
        out/
          [output of map run will be generated here]
          common/            
            [output of lib run will be generated here]
        ref/
          test_map_1.out
          common/
            test_lib_1.out
            test_lib_2.out
            test_lib_3.out
            test_lib_4.out
        trace/

assertTx

I chose to separate the run itself from asserting the results, mostly to be able to see an "assert" line in the test, but also because run errors are not the same as assertion errors. assertTx thus requires again the name of the map, the output extension, and the test case number and compares the produced output (in out/ ) with the reference file (in ref/ ) If the files are different, the assertTx method will raise an AssertionFailed exception including a detailed messages explaining the differences in the usual "expected <...> but got <...>" format.

Aucun commentaire: