Processing of xml files

[Radhika]

Our current test solution is built on this architecture where in we have a Main test which is binded to an xml file. The xml file has all the information for logging and also the test data that the tests need. The Main test can call a number of Shared tests. These shared tests are again binded to the same xml file. The reason being, for the shared test to run stand alone (for debugging) it needs the same input values from the xml file.

Our question is when we have such binding across the tests for the same file, does this create multiple DOM trees in-memory ? The xml file that we are using is growing as we are adding more and more tests. We have 80 tests in our suite and we are now constantly running into OutOfMemory exceptions when running the whole suite. I see in the test run log that it is creating data iterations for xml files. Does this mean it is creating an in-memory tree and we also want to know how does telerik processes handle the release of this memory in between the test runs?

Exception details:

<<< Test-as-Step 'VerifyVitalsGridFirstRowData.tstest' log ends.

InnerException:
System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Text.RegularExpressions.Match..ctor(Regex regex, Int32 capcount, String text, Int32 begpos, Int32 len, Int32 startpos)
   at System.Text.RegularExpressions.RegexRunner.InitMatch()
   at System.Text.RegularExpressions.RegexRunner.Scan(Regex regex, String text, Int32 textbeg, Int32 textend, Int32 textstart, Int32 prevlen, Boolean quick)
   at System.Text.RegularExpressions.Regex.Run(Boolean quick, Int32 prevlen, String input, Int32 beginning, Int32 length, Int32 startat)
   at System.Text.RegularExpressions.Regex.Match(String input, Int32 startat)
   at ArtOfTest.Common.Parser.GetNextTag(Int32 startPosition, Int32& tagLength, String& tagContent, String& tagName, String& tagRemainder)
   at ArtOfTest.Common.Parser.Parse()
   at ArtOfTest.Common.Parser.Parse(String text)
   at ArtOfTest.Common.BaseTreeBuilder`1.BuildDomTree(String text, Boolean trimWhiteSpace)
   at ArtOfTest.WebAii.Silverlight.VisualTree.Refresh(String xamlTree)
   at ArtOfTest.WebAii.Silverlight.SilverlightApp.RefreshVisualTrees()
   at ArtOfTest.WebAii.Silverlight.SilverlightApp.Connect(Int32 timeout)
   at ArtOfTest.WebAii.Silverlight.SilverlightApp.Connect()
   at ArtOfTest.WebAii.Silverlight.SilverlightAppsList.get_Item(Int32 index)
   at FusionUITestsPOC.Pages.QAAUTOSYNC1228183918Page.get_SilverlightApp() in c:\Builds\120\Fusion_2010\PCDEV02_FusionUITestBuild\Sources\PCDEV02\Tests\WeUiPoc\FusionUITestsPOC\FusionUITestsPOC\Pages.g.cs:line 135

Any help appreciated...
Thanks

[Cody]

Hello Radhika,

...does this create multiple DOM trees in-memory?

Do you mean multiple copies of your XML file or multiple copies of the Browsers DOM? To the first question, yes. What's actually happening is that Test Studio is reading and parsing your XML file in order to generate an in memory .NET DataTable object. There will be one object in memory for each "active" test i.e. if you have 3 tests, A calling B calling C, and all 3 are bound to the same XML file, then while C is running there are 3 DataTable objects in memory. When C terminates, the DataTable it was using is discarded, and so on.

To the latter, no. There only be one copy of the browsers DOM in memory at any point in time.

Does this mean it is creating an in-memory tree and we also want to know how does telerik processes handle the release of this memory in between the test runs?

As I was just explaining above, no not a tree, but a .NET DataTable for each test that is bound to any datasource. Then Test Studio starts iterating through each row contained in the DataTable. To make things worse in your case, if Test B is bound to your XML file having 100 rows, but only using rows 3-5, all 100 rows will be loaded into memory and only rows 3-5 will be used.

To overcome the OutOfMemory problems you are running into I suggest changing to using a SQL database. You can use multiple tables along with T-SQL JOIN queries. This approach will give you the greatest flexibility and minimize duplicate data across multiple tests.

Regards,
Cody
Telerik