I have a lot of webServices that I want to test with Junit. For each webService I have between 5 and 40 tests to do, and writing those tests by hand take a lot of time and it is very tedious to do because they are almost the same.
In fact, I send an xml request to my web service, get the response and compare it with the one expected. So for each test, I need only the webService URL, the body of the request and the response expected.
What is the best way to achieve this?
Thanks
I found a good way to do this. I use JUnit parameterized tests. This is a good tutorial to learn how to implement those tests.
I use also generic methods that read a WSDL file and retrieve the types needed to do my tests.
So now I have just one generic parameterized test for all my webServices, and parameters are paths of my WSDL files, input files and expected output files.
Related
I'm a QA and know a little about coding, the developers will convert our SOAP webservice to REST and I want to write tests for this. Basically I want to read our SOAP XML, understand the request/parameters and create a REST Test Case in SOAPUI to be run when they finish the implementation.
Is it possible?
Sorry for my poor english, it's not my native language.
Technically, it's possible.
However, if the developers will be aiming for REST level 3, testing this through hard-coded URLs inside SOAPUP kinda defeats the purpose - ideally you'd be able to navigate between resources through discoverable links.
HAL Browser is one useful tool for navigating such RESTful APIs, however you need a dedicated tool for testing.
Here's an very detailed possible answer for your question.
I made an OCR service using Grails and everything is working very well. I want to make a Web Service for it. The input of the RESTfull WS should be in mime format (the client will send some images and related information in XML format to this WS). How could I implement this in Grails? Any Sample codes to guide me?
Thanks,
Reza
These days, most people do by writing one or more controllers that accept and return text/json (or text/xml if you really want).
Grails has great libraries on board for parsing these requests, all of which are part of the Groovy language:
JsonSlurper
XmlSlurper
JsonBuilder
MarkupBuilder (for making xml)
I have used the approach above successfully on a project. You will end up with Controllers that are easy to unit test, which is a huge productivity win.
I'm at the point where I need to write unit tests for a REST API written using CakePHP 1.3. The API supports GET, POST and PUT requests for querying and manipulating data.
Is there any established way to test the correct input/output of an API simulating an HTTP request, using fixtures? I do not want to run actual POST/PUT requests against the live (dev) database. How can I best mock out the system to use temporary models, yet test the rest of the stack as-is?
Testing GET requests is easy enough with controller tests. However, for data manipulation the API uses HTTP headers quite extensively and also parses raw XML and JSON POST/PUT data. The controller unit test methods only mock POST data by setting $this->data in the controller, which does not allow me to properly test the API.
You should either create Mocks or use Isolation Framework in order to simulate API environment. Unit tests should not depend on resources like internet connections, network, endpoints etc.
If you intend to test real API calls you should create integration test project and use it for this purpose. But be aware integration tests are mostly not repeatable and would give you different results on each run.
I'd recommend starting with a little research. These articles should help:
Unit Testing CakePHP Shells
Testing CakePHP controllers - Mock Objects edition
Testing Models with CakePHP 1.2 test suite
Looks like you might be able to test the raw XML PUT and POST data without too much trouble. The CakePHP REST documentation says this:
If a POST or PUT request has an XML content-type, then the input is taken and passed to an instance of Cake's Xml object, which is assigned to the $data property of the controller. Because of this feature, handling XML and POST data in parallel is seamless: no changes are required to the controller or model code. Everything you need should end up in $this->data.
Try stepping through your controller code in debug mode to see what actually comes in through $this->data during an XML request.
As for avoiding the live database, would a SQLite in-memory database be any easier?
I'm looking for a web service testing framework that has a good built in text input / output gui. The point would be for business and other non developer users to be able to test requirements by using a simple gui that they could enter values into and see the results from the web service. I have seen lots of references on Stack Overflow and the web to great developer web service testing tool but a nice, built in, I/O gui is the key feature for me.
By web service testing I mean a tool that sends xml post requests over HTTP and tests the response.
I have been trying out fitnesse but to use it I need to cut out parts of the system and I very much want to do end to end testing. The way fitnesse displays its results is great but the wiki data entry is a bit clunky for business users imo.
We use FitNesse for the most part. The developers maintain a fixture that s the connector between your app and the FitNesse server. The business user can write the test cases in an wiki style. Works fine for us.
Rational Functional Tester was in the discussion too. However, I have never seen it, but would have met our requirements too.
You might want to look at the robot framework. It's a pretty decent testing library which makes it easy to test web services. There is also a library that integrates Selenium into the framework for front-end testing. Tests can be specified in a couple of plain text formats as well as in HTML tables. You also have the option to let users create test data in spreadsheets if you like, then save them in a tab-separated format.
Look at WebServiceStudio http://www.codeplex.com/WebserviceStudio
We use Concordion for business testing. It's very similar to Fitness but the input files are HTML files "executed" by JUnit.
If your web services don't take 500 parameters, a HTML table is a great way to define input values. I agree, there no UI (although a WYSIWYG HTML editor would do it) but the benefit is that your tests can be checked into Subversion (for example), executed regularly (read every night) and the result HTML files be published internally.
I found testing composite application in Netbeans very easy to use ...
As you requested in your question you can define an input XML and a desired output XML, and when you run the test you have a classic JUnit result like this :
alt text http://netbeans.org/images_www/articles/61/soa/ep-understand-trs/testpassed.png
Here you can find a good example:
Understanding the Travel Reservation Service
I use NetBeans 6.5.1 bundled wit GlassFish ESB 2.1 ... I'm not sure that this feature is supported in the newest NetBeans Versions
What do you use as a test client for your stateful web services? Is it possible to use SoapUI? Are there best practices in this area?
You can do what's called a "Property Transfer" in SoapUI. For example, all our web services have to first call an authentication web service and obtain an authentication token.
I've set this up in SoapUI so that the returned auth token from the auth service is passed on to subsequent requests. It seems to work pretty well, but unless I'm missing a trick I wouldn't like to set it up for a lot of web services (i.e. you have to have an entry for each call you want to transfer data to / from).
Yeah, building SoapUI tests is slow, repetitive work. We didn't discover it until rewriting the SOAP server, and it makes great unit and system tests, but is s.l.o.w to create them.
Oh, and watch out for the memory leaks. Save very frequently. When you run out of memory, you can't save anymore. That sucks a little.
The property transfer stuff is awesome - you can have different scopes (test, request, global), and you can use GroovyScript to do dynamic stuff (like look up a particular date related to today's date, and so on).
With a properly formatted WSDL file, it will generate template requests for you, but you'll still need to tweak them a fair bit - or at least, I did.
I don't know whether it's practical to do this with SoapUI, but I've done things like this with both iTKO LISA and Parasoft SOATest. It wasn't for testing stateful web services, but simply executing multiple testing steps, storing results that are used in following steps. Both LISA and SOATest have the ability to define steps in the GUI that can store pieces of responses that are used in later requests.