Which patterns/architecture to apply for "Import Data, Process Data, Export Result"

Question

I was wondering which architecture/patterns to choose for the following problem divided into three steps:

1. Import TestScript Description from File (e.g. .xls, .txt)
2. Process Described TestScript
3. Export Description with processed Results as .xml

Here is what I got so far:

• Importer that reads in xls and creates a hierarchical object structure
• Parser that creates an Abstract Syntax Tree (If,then,else,end,command) from the object structure
• A Processor (VisitorPattern) of the AST. This Processor instantiates the command implementation, executes the command, collects the results and controls the flow (if, then, else)

Currently the imported object structure already contains a field for the result and can just be serialized out as xml. But in my opinion it's not very elegant having a result field in the input objects.

The main reason I don't like it is that I can not reuse the imported object structure in order to process it multiple times. I would like to divide the whole component also into three parts:

1. Import, which creates an hierarchical object structure that describes the TestScript (containing a fileparser and a preprocessor)
2. Process, which creates an AST and processes it
3. Export, which takes the results and the descriptions and writes it out

Here a few other conditions:

• Not every AST Node represents an object in the object structure (description)
• But each result object is connected to an description object
• Description and Results are hierarchical

Answer 1

Outputting results embedded in the TestScript Description seems excessive. If the results thus written are preventing the TestScript Description from being reused without an edit to remove them, then, the architecture is silly.

Output specifications belong in the Description. The typical test pattern I've seen all my life is that the test has a name, that name is included in the output to identify what the test does. An individual test result should identify what was done, what was expected, what was actually found. The test name usually suffices for what was done, but the expected value, accepted range and actual value are good things to see in the output.

If there's doubt or uncertainty that the expected setup from the Description results in the right objects, a very verbose output mode might cause the Abstract Syntax Tree to be written out to the output. Pause-on-fail or a single step mode that pauses at the point the pass/fail evaluation is made can freeze the system at the moment of decision, and allow the developer or another developer or test maintainer, etc, to look around and be sure the setup from the Description has been correctly assembled.

Reproducing the Description, verbatum, in the output, saves a putative user from having to open an edit/display window for the Description as well as the Output. I sense good will, but unexpressed desires.