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?
Related
I am working on a single-page web application built with Backbone.js, Marionette.js, jQuery, Handlebars and other front-end libraries. The application uses server APIs to interact with its back-end. I am interested in setting up and writing unit tests for the front-end logic that is growing in size and complexity.
What tools do people use in the industry to test the front-end of a web application? How difficult is it to set up and use? Is there a front-end testing framework that can be used with a Backbone.js application?
I know about mock servers and I don't want to test the front-end with those. I would like to test the JavaScript code (client logic) of a Backbone + Marionette app.
Thank you.
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.
I am planning to build an application bundle that includes a mobile app, a website and an web service for other developers. Website has the first priority and mobil application has second.
For creating the mobile application ordinarily first i need to create the web service.
What is the way i should follow:
Create web service, than website and mobile application using it.
Create website, than create service and mobile application.
P.S: I will develop the service and website using Scala and Play! Framework
The optimal order will vary depending on priorities and how stable requirements are.
Usually during development, the understanding of the problem improves and the requirements change. This can happen particularly for the user interface. The first usability tests can lead to changes in the application's design and behavior.
A construction order that takes this into account would be:
Create an initial version of the website. Depending on the project this would include a short description of the project, a way to collect emails, and authentication features such as user registration and login.
Create the mobile application, mocking the service layer in the mobile application itself (i.e. using mock service proxy objects). The objective is to discover and stabilize user interface requirements. This process will clarify which services are needed, which operations these services must perform, and exactly which data these operations must receive and provide.
Implement the web service, based on the already stabilized requirements.
Complete the web site, including description of the application's features and benefits, and showing the application's content (e.g. screenshots, videos).
This order assumes the application's features are the main benefit of the project. If, on the other hand, the main value and complexity resides in the web service, and the application is just a thin, optional front-end over it, then it might be more appropriate to develop the web services first and then the application.
I currently develop a Web application that can be accessed over HTTP by an Android application or a Web browser. Both user agents basically provide the same functionalities. The Android app calls RESTful Web Services built with JAX-RS/Jersey, while Web pages are Facelets backed by JSF managed beans. I thus consider that there are two types of possible entry points to the Web app. The Web services do all the necessary work (accessing the resources, performing the database operations within DAOs, etc.) and most importantly, they must act on their own. Therefore, they constitute an independent layer.
In order to reuse the code, is it a good practice to call a Web service from a managed bean? Are their life cycle compatible?
The idea is to inject the Resource object into the managed bean (with CDI, but not necessarily) and to call its methods programmatically. The Web service would act as a business delegate (?) to the underlying services.
I widely googled the question but I didn't get a clear answer. I saw some pieces of code where the managed bean invokes a Web service with its URL, but since all my components are located in a single server app, I don't see what prevents me from linking them directly.
Subsidiary question on error handling: I am also annoyed with the idea of catching WebApplicationExceptions from the Web service into my managed bean for returning error messages back to the view (with FacesMessage). My father always told me that I should never catch runtime exceptions...So, is there a good way to handle them correctly?
In this case, you would be better off having the business logic out from the Web Service into "some central shared code". Then, then web services and the managed beans would call into the shared code.
I've put the term "some central shared code" in quotes, as what you use depends on your runtime environment. If you're using a JavaEE container like Glassfish or JBoss, this sounds like a perfect use of EJB and stateless session beans (which are designed to ensure the resources are managed well). You could also use Spring Beans as the shared code and centralize the logic that way.
It all depends on what you find more comfortable from a development and production sense. But both support injection, so both the Web Service and JSF Managed Beans could have the services injected as any other resource.
A method in one EJB will call a Web service in another EJB. Do they need to be packaged in the same EAR, or can I deploy the Web service provider separately (in a WAR)? Will dependency injection (accomplished through #WebServiceRef annotation) work if the two EJBs are deployed separately?
Thanks!
Do they need to be packaged in the same EAR, or can I deploy the Web service provider separately (in a WAR)?
That depends on how you intend to deploy the EJBs. If you are deploying them in the same EAR file, and therefore, in the same container, I would consider the #WebServiceRef annotation to be pointless and a drag on performance. You might as well inject the other EJB instead of injecting a JAX-WS proxy in it's place.
If you want to separate these out and deploy one of the EJBs (the one providing the webservice) in a WAR file, then it is possible to do so in a Java EE 6 container.
Will dependency injection (accomplished through #WebServiceRef annotation) work if the two EJBs are deployed separately?
Yes, dependency injection will work as long as you have deployed the client in a managed environment (this includes application client containers, web containers and EJB containers). As far as the client EJB is concerned, the container will provide a proxy for the web-service at runtime. All calls will be delegated to the proxy, that will make the required HTTP requests to the actual web-service, and return the appropriate objects after processing the response.