Interdependent conditional csv validation in SOAtest
Hi,
I have a got a csv report which has fields (e.g. column 5) containing today's timestamp, for rows with only certain values in the first column. The csv client is used to convert it to xml.
I have been struggling with xml databank, writable datasource and custom assertion to get this show on the road, but the result is not satisfactory yet.
Basically I want to have access to the content of the first column, when the column 5 is being validated at runtime. So I can make a simple if/else structure and only assert when column 1 has a certain value.
With the xml data bank and writable datasource set up, the csv file is scanned and the values of the first column are extracted and stored, BEFORE the assertion takes place. Subsequently the writable datasource is looped and the entire csv is scanned again, thus resulting in a lot of false negatives, because the value of column 1 from the writable datasource is not matching anymore with the actual value in the csv and the assertor is fooled.
I already tried to 'abuse' a custom assertor on the first column, but it would not allow me to return the column 1 content to a variable, only a boolean (0,1) result is possible. The value of the column 1 stays thus only available within the function in the customer assertion and cannot be stored in a global variable for use elsewhere, or is there a way? context.setValue does not seem to work outside the function as well. So what are the options within SOAtest to get this rollin'?
Thanks in advance.
Regards,
Daniel
Answers
-
Hi, I also tried to solve this issue with conditional assertion and string comparison on a fixed value of column 1 but that does not seem to work. I do not know whether SOAtest validates by row or by column. But with that condition assertion on column 1 in place no customer assertion on column 5 is performed apparently.
0 -
Also using a custom assertion as condition does not seem to work between different columns per row.
0 -
Did you configure your XML Data Bank to write both column 1 and column 5 to the Writable Data Source? You do this by setting up two extractions, one for each column, selecting a different column in the Writable Data Source for each one.
So, if an XML Data Bank chained to your CSV Client populates the Writable Data Source then you would need a test suite after the CSV Client to iterate over the rows in the newly populated Writable Data Source. The tests in that suite will loop over the Writable Data Source row-by-row and have access to both columns. If you are using a custom (scripted) assertion, you can use context.getValue("Data Source Name", "column name") to get access to whatever column value you need for the current data source row.
0 -
Thanks Benken for the swift reply. I will also extract the other columns that needs validation to the writable DS and see how that works from there.
Have a good weekend.
Cheers,
Daniel
0 -
Hi Benken, what kind of test(s) do you suggest to loop over the writable datasource, as long as I can hook up a custom assertion? Or can it basically be any kind?
0 -
In the meantime I have used an Extension Tool to extract the values from the Writable DS and can hook up a XML Assertor with custom assertion to do the validation stuff. Now I am struggling a bit with embedding this test suite in the rest of my test suites, now having 2 datasources. In the test suite handling the Writable DS and stuff, I set the Test Execution to Tests Run as group. And it runs fine when fired off 'stand alone'. However when I make reference to it in the mother test, where Test Execution is set to Tests run as subgroup as part of this group, the current behaviour shows that all other tests of the mother test suite are iterated over the writable DS which is not desirable. Somehow the setting Tests Run as group is overruled, once embedded. So, is there an example available for working with multiple datasources within one test? Btw. I have setup the writable DS within the child test suite and not within the parent test suite.
Thanks.0 -
what kind of test(s) do you suggest to loop over the writable datasource, as long as I can hook up a custom assertion? Or can it basically be any kind?
Using data sources is common to all tools. So, this would be whatever test or tests you want for performing your assertions.
I have used an Extension Tool to extract the values from the Writable DS and can hook up a XML Assertor with custom assertion to do the validation stuff.
This sounds reasonable. In the public scripting API, it has been common to use soaptest.api.SOAPUtil.getXMLFromString(String[] values). It will return a simple XML document containing a list of strings you provide.
However when I make reference to it in the mother test, where Test Execution is set to Tests run as subgroup as part of this group, the current behaviour shows that all other tests of the mother test suite are iterated over the writable DS which is not desirable. Somehow the setting Tests Run as group is overruled, once embedded
A test suite normally provides the context for a loop. However, the "Tests run all sub-groups as part of this group" eliminates this. It allows using child test suites as a way of grouping tests for organizational purposes without those child test suites becoming their own nested loops. The tests in any descendant suites execute as if they were living directly within the ancestor which enabled this. So, you can't use this option if you need nested loops.
This mode of execution is primarily used for browser playback scenarios where you may have long lists of actions for a single web page, like filling out fields on a form. Grouping the tests for the various "type" and "click" actions helps with organization while enabling them to loop over data source rows together with their parent instead of becoming an inner loop.
0 -
This is an advanced approach, but in case this helps you I wanted to mention that XSLT can also been used to perform validation. In this case you could covert your CSV document to XML using an XML Convertor tool. Then you would chain an XSLT tool to transform the XML and then a Diff tool to check the transformed document. The XSLT tool would need to be configured with an XSL document that translates the XML to a list of elements saying which rows passed or failed (or whatever information you find useful).
A couple examples I found on stackoverflow:
https://stackoverflow.com/questions/9306433/newbie-xslt-transformation-to-validate-rules-in-xml-document
https://stackoverflow.com/questions/9505086/xslt-transformation-to-validate-rules-in-xml-document0 -
Hi Benken, thanks a lot for your effort. As the Test run all subgroups etc. indeed does not work with nested loops, I try to detach the whole writable datasource routine in an isolated test suite, use a file DS to process the prepped csv's and see how that works out. Its like a two step rocket ...
0
