Posts tagged as:

REST

Note: For overall context for this blog please read integration testing with soapUI.

SoapUI Pro has extensive reporting functionality: creating reports on different levels (project, testsuite, testcase, etc.), different formats (pdf, cvs, xls, xml, etc.), easy customization and more. The feature provides three basic types of reports:

  1. Printable Reports : Reports are based on the JasperReports reporting engine, and a good understanding of how Jasper works is necessary to customize the reports created by soapUI.
  2. Data Export: lets you export the same underlying data that is used for printable reports to xml or csv files.
  3. JUnit-Style HTML Reports: to generate HTML reports very reminiscent of the “classic” ant/junitreport reports

Our requirement was to show functional test results with complete details in XML/HTML format. Some of the details we want to show as part of XML/HTML reports were:

Description of test case:

  • List of passed/failed test steps
  • Passed/failed assertions in each step
  • Capturing screen shots where failed test step invoked selenium (please read our blog about selenium integration with soapUI)
  • Fetch Selenium logs
  • Providing attachments like screen shots, request/response details in case of failed test step

Others

  • It should show results for different browsers
  • Test results can be publishable on Hudson or on specified web server
  • If published on Hudson result should be consistent for different browser and can be categorized by browser.

We decided that JUnit-Style report is right candidate to meet the above requirement as it provides functional test results in XML/HTML format as well as Hudson understands the JUnit test report XML format.

Now the challenge was to generate reports with complete details as per requirement above because default reporting functionality gives a simplified overview of functional test results. Refer screenshot.

To fulfill all this requirement we need to customize the JUnit-Style reports created by soapUI and that is not supported by soapUI!…

So what did we do?

We did some analysis and found that we can achieve what we need by extending com.eviware.soapui.report.JUnitReportCollector class and implementing custom behavior as per our requirements.

In our custom JUnitReportCollector, we are adding custom behavior in the afterStep method. As we required to show all steps with assertions regardless of they got success or failed, we added one more map to record steps status that are got success

HashMap<TestCase, String> status;

public IsplJunitReportCollector() {

reports = new HashMap<String, JUnitReport>();

failures = new HashMap<TestCase, String>();

status = new HashMap<TestCase, String>();

}

In beforeRun method we added common properties to system out so it can be shown by each test case. At this point we sets name of test case with prefix project.browser so that Hudson can separate test cases accordingly. Check code and Screen Shot below.

public void beforeRun(TestCaseRunner testRunner, TestCaseRunContext runContext) {

TestCase testCase = testRunner.getTestCase();

TestSuite testSuite = testCase.getTestSuite();

if (!reports.containsKey(testSuite.getName())) {

JUnitReport report = new JUnitReport();

String browser = PropertyExpansionUtils.getGlobalProperty(“Browser”);

String project = PropertyExpansionUtils.getGlobalProperty(“Project”);

report.setTestSuiteName(project + “.” + browser + “.” + testSuite.getName());

StringBuffer buf = new StringBuffer(“Date: “

+ new Date(System.currentTimeMillis()));

buf.append(“\nUIURL: “ + PropertyExpansionUtils.getGlobalProperty(“UIURL”));

buf.append(“\nStoreCode: “

+ PropertyExpansionUtils.getGlobalProperty(“StoreCode”));

buf.append(“\nVersion: “ + PropertyExpansionUtils.getGlobalProperty(“Version”));

report.setSystemOut(buf.toString());

reports.put(testSuite.getName(), report);

}

}

hudson_grooup_tc

Next customization point is afterStep method, which takes care of following points.

- Proper formatting result to make readable even if deployed by hudson

- Shows selenium log in case of failed step invoked browser

- Provides screenshot link if available

- Provides failure step’s details file link.

- Shows all steps results irrespective of it is failed or passed

- Show all assertions details if available

public void afterStep(TestCaseRunner testRunner, TestCaseRunContext runContext,

TestStepResult result) {

TestStep currentStep = result.getTestStep();

TestCase testCase = currentStep.getTestCase();

if (result.getStatus() == TestStepStatus.FAILED) {

StringBuffer buf = new StringBuffer();

if (status.containsKey(testCase)) {

buf.append((String) status.get(testCase));

}

if (failures.containsKey(testCase)) {

buf.append((String) failures.get(testCase));

}

Get report file and screenshots if available to attach. Hudson doesn’t support html formatted Stack trace but provide link for URL so we had provided plane text with URL of attachments. Here to check whether screen shot is available or not we are checking property of test case which will programmatically created by our custom groovy script which Invoking a seleniumRC test from soapUI (Please read our blog about Invoking a seleniumRC test from soapUI)

String screenshot = testCase.getPropertyValue(currentStep.getLabel() + “screenshot”);

String reportFile = getErrorReport(currentStep, runContext, result);

buf.append((new StringBuilder()).append(“\n” + result.getTestStep().getName()).append(

” Failed”).toString());

buf.append(lineBreak());

buf.append(showFile(reportFile, “View Details”));

buf.append(lineBreak());

//buf.append(“Absolute path: ["+reportFile+"]“);

buf.append(lineBreak());

buf.append(showFile(screenshot, “View Screenshot”));

buf.append(lineBreak());

Show Complete Message Logs:

buf.append((new StringBuilder()).append(

XmlUtils.entitize(Arrays.toString(result.getMessages())))

.append(lineBreak()).toString());

if (testRunner.getTestCase().getSettings().getBoolean(“Complete Message Logs”)) {

StringWriter stringWriter = new StringWriter();

PrintWriter writer = new PrintWriter(stringWriter);

result.writeTo(writer);

buf.append(XmlUtils.entitize(stringWriter.toString()));

}

failures.put(testCase, buf.toString());

}

Here is the code to show success steps information as well as all assertions

else {

StringBuffer buf = new StringBuffer();

if (status.containsKey(testCase)) {

buf.append((String) status.get(testCase));

}

buf.append(“\nTest Step: “ + currentStep.getName());

buf.append(“\tResult: “ + result.getStatus() + “”);

if (currentStep instanceof Assertable ) {

Assertable requestStep = (Assertable) currentStep;

if(requestStep.getAssertionCount()>0){

}

}

// any prior test-step failed!…

if (failures.containsKey(testCase)) {

String str = (String) failures.get(testCase) + “\n” + buf.toString();

failures.put(testCase, str);

} else {

status.put(testCase, buf.toString());

}

}

}

Screenshots:

– failed test case (failed UI test step)

seleniumts_before

After Customization

seleniumts_after_n
After Customization it shows failed test step with complete details, link to screen shot if it had invoked selenium as well as test steps that got success with assertions details. Next screenshot shows how it reports if deployed in Hudson.

seleniumts_after

VN:F [1.9.10_1130]
Rating: 9.4/10 (10 votes cast)

  

{ Comments on this entry are closed }

Note: For overall context for this blog please read integration testing with soapUI to understand why extending soapUI to work with Selenium is ever necessary.

A selenium RC groovy script which is one form of customizable edition of the recorded selenium IDE can be invoked in the soapUI. It is useful to perform various tasks in soapUI like as follows:

  • As a test step
  • To control testcase flow based on output of previous steps
  • To trigger the execution of test steps or test cases
  • As a data generator
  • As extended script libraries for common functionalities.
  • To write the results of test steps or test cases to an external source

Selenium RC and IDE

Selenium Remote Control (RC) is a test tool that allows user to write automated web application UI tests in multiple available programming languages against any HTTP website using any mainstream JavaScript-enabled browser.Selenium RC has two processes:

  1. A server which automatically launches and kills browsers, and acts as a HTTP proxy for web requests from them.
  2. Client libraries for multiple computer language.

The RC server also bundles Selenium Core, and automatically loads it into the browser.

Firefox extension calling Selenium IDE (Screenshot001) is used to record the functionality of the web site. It is easy to use and powerful tool for controlling, automating or testing web sites. It has record and playback feature that can be used to automate any thing in the web sites.

000011

(Screenshot001)

Selenium IDE has feature to save and export automated task in Groovy script (Screenshot002) which in turn can be used in soapUI.

0021

(Screenshot002)

For Selenium IDE users, Selenium RC is ideal solution to write tests in a more communicative programming language. So, to be more expressive, compatibility and for extra assertions recorded scripts are exported in Groovy Scripts.

Groovy Scripts

Groovy:

  • is an agile and dynamic language for the Java Virtual Machine
  • builds upon the strengths of Java but has additional power features inspired by other languages.
  • supports Domain Specific Languages and other compact syntax so that code is easy to read and maintain
  • makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
  • simplifies testing by supporting unit testing and mocking out-of-the-box
  • seamlessly integrates with all existing Java objects and libraries
  • compiles straight to Java bytecode so you can use it anywhere you can use Java

Groovy scripts can be widely used in a soapUI for different functionalities.

SoapUI

soapUI is open source desktop application for inspecting, invoking, developing, simulating/mocking and functional/load/compliance testing of web services over HTTP. In a given framework, soapUI is used for testing web service.

Following are the functionalities of the groovy scripts in soapUI:

  • As part of a Testcase with the Groovy Script Test Step, allow tests to perform virtually any desired functionality
  • Before and after running a Testcase or Test Suite for initializing and cleaning up before or after running the tests.
  • When starting/stopping a MockService for initializing or cleaning-up MockService state
  • When opening/closing a Project, for initializing or cleaning-up Project related settings
  • As a dynamic DataSource or DataSink with the corresponding DataSource/DataSink test steps
  • For creating arbitrary assertions with the Script Assertion
  • To extend soapUI itself, for adding arbitrary functionality to the soapUI core. User can create his/her own script libraries for common functionality which can be used shared by the Testing team.

Benefits of Groovy Scripts in Test Automation Framework

In Test Automation Framework, we have used groovy scripts mainly:

  • As a test steps. (refer below screen)

0061

(Screenshot003)

  • As a dynamic DataSink. (refer below screen)

0072

(Screenshot004)

  • Before and after running a Testcase or Test Suite for initializing and cleaning up before or after running the tests. (refer below screen)

008

(Screenshot005)

  • To involved Selenium RC scripts for extend soapUI, we have created own script libraries for common functionality which can be used shared by the Testing team. We have further customized it by creating a jar for the same i.e. scripts.jar and kept it in the soapUI setup at “C:\Program Files\eviware\soapUI-Pro-3.0.1\bin\ext”. (refer below screen)

0091

(Screenshot006)

When tester will run the soapUI project either from Test Automation Framework or from soapUI Pro, it will take the extended script libraries from scripts.jar file.

Conclusion

Using test automation framework, a tester can execute the soapUI test suites or test cases automatically segregated by categories and browsers. Framework is customizable by updating the extended soapUI libraries for common functionalities. It will actually help the user to create a groovy script for commonly used functions and then bind those scripts in a jar file so that user can use in soapUI. While executing soapUI, it will automatically use customized selenium groovy scripts with assumption that selenium services are running.

VN:F [1.9.10_1130]
Rating: 8.5/10 (2 votes cast)

  

{ 16 comments }

At two recent engagements we had to solve SOA integration testing problem. Simply  put, in a heavy SOA environment, our tests had to verify web services (SOAP  or REST) and additionally, for the validating the end to end scenario,  there were MORE than web services involved in the same scenario.  For  example, we had to incorporate GUI testing, or invoke a POJO or validate  something else using a DB script in the same test. For instance ,  you  could create a user using a web service and validate that the user can  login to the system under test using the web user interface.

Clearly this needed us to invoke a GUI test tool (or  framework) while doing a web service test. Our solution involved using  soapUI as the main container for our tests hooks for other tools. We  integrated following tools  with  soapUI

  • Selenium RC  for web based testing
  • Java interface testing (invoking a basic controller like java object – to test and validate some business functionality)
  • DB Unit

SoapUI was a natural candidate for us as it  was already being used by either the development or testing team for our  clients. Secondly, as these were tests with in a SOA environment, soapUI  was a great tool to home all the tests.

Our specialized  steps with in soapUI test invoked selenium or a Java interface or a DBUnit  based test  and asserted using the native assertions provided by  these tools. We will have a series of blogs here tagged with soapUI that  explain how we achieved it. Stay tuned …

Here are the links to these blogs:
Invoking a Selenium RC test from soapUI

Customizing soapUI reports

VN:F [1.9.10_1130]
Rating: 9.3/10 (4 votes cast)

  

{ 3 comments }