I already know how to write JUnit test cases (can also use Mockito). Thanks for the simple tutorials in the web for that. The only problem is that I can't find any examples on implementing it to an actual or let's say realistic project.
I have a simple REST web service which uses Servlets. It has an API method that sends a POST request to another web service then arranges the data as its response.
The API request is processed by two layers:
Servlet (Controller) - validates the request parameters
Service - The sender of the POST request to another web service
Here's what the service method does:
Prepares a parameter data (some attributes are provided in the paramaters of this request, some are retrieved from the database)
sends a request to another web service which responds with an image url for a QR Code
Decodes the QRCode image and then responds to its request with the decoded text
What are the unit tests cases needed for this?
How about integration tests? Do I have to use ServletUnit, or can I just run the server and write tests with requests to the running server?
Unit testing usually involves testing a single class in isolation. So you would need tests for the servlet class and for your service class as well.
If you're interested in unit testing a servlet, then have a look at these answers. In your case, you need to mock any external dependencies and check for example if valid parameters are sent to the service method.
Unit testing the service method includes mocking all external dependencies (web service, database) and only test the logic that's performed in the method (e.g. data is prepared correctly, QR decoding and responding with the correct text).
Most of the time you end up writing integration tests since you have multiple components which need to work together. There are multiple possible solutions to tackle that problem. You could create a separate integration testing environment which tries to replicate your production environment as closely as possible (web server, application server, database). For smaller projects that might be too much work and you could just spin up an embedded Tomcat with some kind of an in memory database (H2 for example). Keep in mind that for integration tests to be repeatable you might have to reinitialize the database for every test run.
In addition, you mentioned a web service which responds with a URL to a QR code. If you're not in control of that service, I would try to mock that service as well. You don't want to have a failing integration test because of a web service which might not be available 100% of the time.
Since your Servlet acts as a RESTful web service, take a look at rest-assured. This is a DSL for testing REST services.
Related
We're in the process of setting up a web service and clients using Swagger to define the interface. Our client is a c++ app, and we're using the C++/Qt5 code generator provided by Swagger to create our interface classes.
I'd like to create a unit test framework that will let us test these interface classes, but to do so, I'd like to have a local app that is running the server end of the protocol such that we can connect as locally.
I tried running the "Generate Server" feature on the swagger editor (http://editor.swagger.io/#/) to produce different servers, but the only one I could get to work was the node.js one, which doesn't appear to be a server that fulfills the defined protocol, but instead a documentation server that allows you to use web forms to send messages to another server.
I don't need anything fancy - just a local process I can send HTTP to that will send back canned responses in order to close the connectivity loop. I know little-to-nothing about web application development, and the team that is responsible for implementing our actual server has bigger fish to fry right now than to write a testing app for me.
I am trying to write a fixture for a web app, and am running into issues understanding how to mock certain aspects of the application.
Our project has heavy dependancies on Redis, RabbitMQ, an external account authentication server for both authentication and licensing, Spring Security, and a Websocket Framework called Atmosphere.
All of these components need to be present for the App to even function. How do you go about creating mocks for objects when all of these components need to be present and working without injecting a bunch of extra logic into the production code?
From the book I have learned, most Cucumber testing are start from outside to inside (top-down approach). It starts from UI (Web or Desktop app).
My team is web service team, and we have separate team working on UI layer, which is out of our control. My question is, what is the boundary of our Cucumber test? Does it start from Web Service Layer?
One of the benefit of doing top-down approach is that, it allow the methods to be pulled (methods are created out of the need of calling object) instead of being pushed (methods are created by guessing how the calling object will use it).
However, if we are using cucumber test on the Web Service Layer by itself (without the calling object, UI layer), it seems like we are not doing top-down approach (by pulling the methods).
Please advice how to run cucumber test on Web Service Layer.
You can still write Cucumber tests by taking the esoteric user perspective of the presentation layer calling the service layer.
For example your business analysts have given you the common requirement (I've purposely kept this example simple!):
As a user
I want to log-on
So that I can access a particular service
The acceptance criteria will be that a user will provide valid credentials (i.e. valid username and password).
Hence with this story in place the presentation layer team will be able to implement this story using a Cucumber test to drive the development, where they will mock the calls to your service layer.
Your service layer team can also proceed to write in parallel a test covering their concerns e.g.
Given the authentication service knows about the user "jdoe"
When the client requests to authenticate "jdoe" with the password "contrived"
Then the response is grant user access
A great article covering service-level cucumber testing in greater detail can be found here.
hi all
i coded a custom web service for sharepoint in a remote machine and will deploy it later to the host machine
but how programs do i need to install to my computer to test that web service
Use a tool such as
Storm
SoapUI
Web Service Studio
(All open source)
You'll probably need a test application to sit on the same system as the web service.
It will locally fire the webservice and some of the test fixtures will only monitor what it returns.
The rest of the fixtures should examine what the webservice actually interacts with on the server side.
ie: If you have a webservice that accepts a command then starts a Workflow, you would:
a) Ensure that the correct response is given by the webservice when invalid input is given
b) Ensure on the server side that the correct workflow is instigated and started with the correct initialisation data.
You would probably need many, many test cases depending on what your webservice actually does.
A friend wants to consume my ASP.NET MVC 2 application in a similar fashion as adding a web reference to it, accessing my functions, and using my model objects from a .Net web form from a separate website.
Any links out there that could explain how to "dress" my MVC responses so that his server to server consumption would be similar in experience to a web service?
I suggested using System.Net.WebClient to pull the results in to a variable then deserialize the JSON result, but maybe there's a better approach out there?
I'd suggest that you consider an API controller or a separate API application depending on the load you expect from people consuming data from your application. A separate API application will allow you to move it off your application servers if needed.
Rarely, will you find that the data that you would provide via an API is a one-to-one match with what your views need to be rendered. Behind the scenes you could abstract the data generation so that your API and your application controllers reuse the same code to get at the data, but the front-end of the API would understand how to negotiate security (from an API perspective) and present data that is easily consumed by a program. Moreover, you won't find that you're creating extra controllers and methods in your application just to provide some data that will never be used in a particular view.
You could use MVC or WCF for the API and JSON or XML as the payload format. If you use WCF, you get the benefit that he really can simply add a service reference to connect to it without you having to build a WSDL file/action.
From another's advice, Phil Haack added this to MVC 2 Futures. Add the DLL reference to the Application Start, and bingo. It uses a validator.