Hello -
Question: Is there a recommended approach to testing values returned in an SSRS report?
Context: I have just started evaluating Test Studio for use with my company's client extranet. The site makes heavy use of SQL Server 2012 SSRS reports. I want to be able to run a report and validate the results that come back by spot checking key values returned in the report table. These tables are often thousands (if not tens of thousands) of rows long by dozens of columns wide. Consequently, I can't create reliable ID's for each data point.
When I run the Test Studio recorder, select a few cells in the SSRS results, then run the test, I typically get errors indicating that Test Studio was "Unable to locate element." Furthermore, it says that it was found by backup search using the xpath value. I can resolve the failure by going to the "Resolve Failure" tab, removing the existing filters, and replacing them with the xpath suggestion. From there, the test will work.
The down side is that this seems fairly fragile in nature. The xpath for most data points looks something like this:
xpath=/html[1]/body[1]/form[1]/div[5]/div[1]/div[1]/div[1]/div[4]/div[1]/div[3]/div[2]/table[1]/tr[2]/td[1]/div[1]/div[1]/div[3]/div[1]/div[1]/div[1]/div[1]/table[1]/tbody[1]/tr[1]/td[1]/div[1]/div[1]/table[1]/tbody[1]/tr[2]/td[1]/div[1]/table[1]/tbody[1]/tr[1]/td[4]/table[1]/tbody[1]/tr[1]/td[1]/div[1]/span[1]/div[1]/table[1]/tbody[1]/tr[5]/td[3]/div[1]/div[1]/div[1]/table[1]/tbody[1]/tr[1]/td[1]/div[1]/table[1]/tbody[1]/tr[52]/td[6]/div[1]
To say that's ugly is an understatement, and it seems like it wouldn't take much of a page update to throw it off. Plus, because I need to add many data point validations, I really don't want to go into Test Studio, create all the tests, and then run each one over and over until I resolve all the failures by following the steps above.
Restating the Question: Is there a recommended approach to testing values returned in an SSRS report?
Thank you in advance for any direction you can provide!
Best regards,
Jason W. Pegg
Question: Is there a recommended approach to testing values returned in an SSRS report?
Context: I have just started evaluating Test Studio for use with my company's client extranet. The site makes heavy use of SQL Server 2012 SSRS reports. I want to be able to run a report and validate the results that come back by spot checking key values returned in the report table. These tables are often thousands (if not tens of thousands) of rows long by dozens of columns wide. Consequently, I can't create reliable ID's for each data point.
When I run the Test Studio recorder, select a few cells in the SSRS results, then run the test, I typically get errors indicating that Test Studio was "Unable to locate element." Furthermore, it says that it was found by backup search using the xpath value. I can resolve the failure by going to the "Resolve Failure" tab, removing the existing filters, and replacing them with the xpath suggestion. From there, the test will work.
The down side is that this seems fairly fragile in nature. The xpath for most data points looks something like this:
xpath=/html[1]/body[1]/form[1]/div[5]/div[1]/div[1]/div[1]/div[4]/div[1]/div[3]/div[2]/table[1]/tr[2]/td[1]/div[1]/div[1]/div[3]/div[1]/div[1]/div[1]/div[1]/table[1]/tbody[1]/tr[1]/td[1]/div[1]/div[1]/table[1]/tbody[1]/tr[2]/td[1]/div[1]/table[1]/tbody[1]/tr[1]/td[4]/table[1]/tbody[1]/tr[1]/td[1]/div[1]/span[1]/div[1]/table[1]/tbody[1]/tr[5]/td[3]/div[1]/div[1]/div[1]/table[1]/tbody[1]/tr[1]/td[1]/div[1]/table[1]/tbody[1]/tr[52]/td[6]/div[1]
To say that's ugly is an understatement, and it seems like it wouldn't take much of a page update to throw it off. Plus, because I need to add many data point validations, I really don't want to go into Test Studio, create all the tests, and then run each one over and over until I resolve all the failures by following the steps above.
Restating the Question: Is there a recommended approach to testing values returned in an SSRS report?
Thank you in advance for any direction you can provide!
Best regards,
Jason W. Pegg