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
  • 9
    The pattern is known as ETL or Extract Transform Load. – k3b Jul 31 '14 at 11:12
  • thats a really coarse description. i am looking for a class level design. I have input objects (hierarchical test descriptions), then the tests are executed and producing results. then the results have to be exported together with the descriptions. In the current system the input objects have "null"-fields for the result information. In my opinion its not very clean to "read in" objects wich should represent only the description, but instead already contain "invalid/empty" results. This way the description can not be reused for multiple test runs. – kaeLum Aug 4 '14 at 10:49
  • 2
    Fundamentally your input and output objects may be two very different things, which is why the current design feels wrong: it is only the coincidence of their similarity at this point in time that makes that route convenient. You will likely encounter a point in the future where the output begins to deviate more and more and you will want dedicated input/output types. – J Trana Aug 15 '14 at 5:03

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.