I am trying to test internationalization from integration tests for a grails controller.
The controller is REST enabled and returns JSON responses.
In order to test internationalization, one can simply give ?lang=es in the URL and the respective message bundle is used internally by grails.
I am in a support project where the internationalization already works as it is supposed to. When I give a curl request, I receive the responses in the correct languages.
The integration test is just intended to validate the different language specific responses.
I am not sure how I can request for any language from the integration test.
I tried :
response.locale = new Locale("es", "es") //did not work
controller.params.lang = "es" // did not work
I have not found much help on this from http://grails.org/doc/latest/guide/i18n.html#changingLocales. And neither from other questions but A related article could be How to unit or integration test use of injected messageSource for i18n in Grails 2.0 service
Integration tests use the GrailsMockHttpServletRequest class that have the method addPreferredLocale(Locale) to change the locale of the current test request.
Normally we get the request through RequestContextHolder:
def request = RequestContextHolder.currentRequestAttributes().request
request.addPreferredLocale(new Locale("pt","BR"))
Related
Is there a public Web API that I can use to test my calls? Maybe specifically for get requests?
For example:
/async/takeslongtime : Tests how your application acts when you do an API call that takes a long time
/params/encoding?exactstring=!## : Tests if you are encododing as %21%40%23
Something with path parameters maybe
Anything else I should bother testing for (multiple parameters, etc)
Or, what things did I not mention that I should test for?
Please find the url of the sample REST Service "http://httpbin.org/".
Navigating to the endpoint display's all the available resources and its supported methods.
For Example:
/delay/:n -> Helps you create the delay.
/response-headers?key=val -> for testing encoding
It also provides endpoints that can be used for testing various other HTTP methods.
This will mostly meet your requirements.
I want to write a web application with a simple Frontend-Backend(REST API) architecture.
It's not clear to me where and how to write tests.
Frontend: should I write tests mocking API responses and testing only UX/UI?
Backend: should I write here API call testing and eventually more fine grained unit testing on classes?
But in this way I'm afraid that Frontend testing is not aware of real API response (because it's mocking independently from the backend).
On the other side if I don't mock API response and use real response from backend, how can the Frontend client prepare the DB to get the data he wants?
It seems to me that I need 3 kind of testing types:
- UX/UI testing: the Frontend is working with a set of mock responses
- API testing: the API is giving the correct answers given a set of data
- Integration testing: The Frontend is working by calling really the backend with a set of data (generated by who?).
There are framework or tools to make this as painless as possible?
It seems to me very complicated (if API spec changes I must rewrite a lot of tests)
any suggestion welcome
Well, you are basically right. There are 3 types of tests in this scenario: backend logic, frontend behaviour and integration. Let's split it:
Backend tests
You are testing mainly the business logic of the application. However, you must test the entire application stack: domain, application layer, infrastructure, presentation (API). These layers require both unit testing and integration testing, plus some pure black box testing from user's perspective. But this is a complex problem on this own. The full answer would be extremely long. If you are interested in some techniques regarding testing applications in general - please start another thread.
Frontend behaviour
Here you test if frontend app uses API the right way. You mock the backend layer and write mostly unit tests. Now, as you noticed - there can be some problems regarding real API contract. However, there are ways to mitigate that kind of problems. First, a link to one of these solutions: https://github.com/spring-cloud/spring-cloud-contract. Now, some explanation. The idea is simple: the API contract is driven by consumer. In your case, that would be the frontend app. Frontend team cooperate with backend team to create a sensible API, meeting all of client's needs. Frontend tests are therefore guaranteed to use the "real API". When client tests change - the contract changes, so the backend must refactor to new requirements.
As a side note - you don't really need to use any concrete framework. You can follow the same methodology if you apply some discipline to your team. Just remember - the consumer defines the contract first.
Integration tests
To make sure everything works, you need also some integration e2e testing. You set up a real test instance of your backend app. Then, you perform integration tests using the real server instead of fake mockup responses. However, you don't need (and should not) duplicate the same tests from other layers. You want to test if everything is integrated properly. Therefore, you don't test any real logic. You just choose some happy paths, maybe some failure scenarios and perform these tests from user's perspective. So, you assume nothing about the state of the backend app and simulate user interaction. Something like this: add new product, modify product, fetch updated product or check single authentication point. That kind of tests - not really testing any business logic, but only if real API test server communicates properly with frontend app.
Talking about the tools, it depends on your language preferences and/or how the app is being constructed.
For example, if your team feels comfortable with javascript, it could be interesting to use frameworks like Playwright or WebdriverIO (better if you plan to test mobile) for UI and integration tests. This frameworks can work together with others more specialised in API testing like PactumJS with the plus that can share some functions.
Organising the test correctly you will not have to do a big extra work if some API specs changes.
I've been trying to find a simple all purpose unit test framework for Spring MVC based Rest Services I've written.
I've been searching online and narrowed it down to:
RestFuse (http://developer.eclipsesource.com/restfuse/)
Rest Assured (https://github.com/jayway/rest-assured)
MockMVC (http://www.petrikainulainen.net/programming/spring-framework/unit-testing-of-spring-mvc-controllers-rest-api/)
I like RestFuse because it's mostly annotation based, but rest assured seems to have a easier way of passing parameters and checking responses. And finally being a Spring MVC Rest Service project, I'm wondering if I should just stick with the already established way of testing Rest Services in Spring with MockMVC.
Interested to get any feedback, as well as performance, past experiences and if there's anything else I should take into consideration.
Rest-Assured is gaining acceptance over the other frameworks to test REST services in Java. Having BDD style fluent interface, its easy to read the test scripts also, with minimal learning curve.
I am using this framework for verifying REST services as an end user, and it has been easier to implement test scripts for them. Hence I cannot comment much on Spring MVC part of REST-assured.
However, this blog post gives you more details on RestAssured v2.2 which includes spring-mock-mvc module built on top of MockMVC giving BDD style fluent interface flavor through REST assured. The blog post also cautions:
When not to use it:
RestAssuredMockMvc is not to be considered a complete replacement to
vanilla MockMvc since it contains more specific features coupled to
Spring MVC. For example right now there’s no first class support for
things like flash attributes and principals. You can how ever add
those by using an interceptor. Standard REST Assured also supports a
lot of different authentication schemes and filters which are not
available in the RestAssuredMockMvc API. Another reason for why you
may want to use the standard REST Assured API is if it’s important to
your organization to test the REST API in a real container (for
example if you’ve configured authentication or authorization in a
container specific manner) or if you’re using JAX-RS (or any other
framework regardless of language).
Finally, have a look at REST-Assured spring-mvc-webapp examples in REST-assured codebase, and decide, whether you like to give a try for it and make the best use of both REST-assured and MockMVC frameworks.
The beauty of MockMVC is that it provides a mock servlet container, allowing you to integration-test your REST services without deploying to a web server. I believe that you can still leverage this power when using REST Assured with the spring-mock-mvc module.
Another framework that I just learned of is Karate. Its author is currently experimenting with a mechanism to allow execution in a mock servlet container (see Peter Thomas' answer to Is there a mechanism for integration testing JAX-RS services without deploying (a la MockMVC)?).
We are currently in the process of identifying a suitable Automation Framework using JMeter for our RESTful APIs. A typical POST Request in our suite would be something as shown below :
URL : https://host123.com/createuser
Message body(JSON) :
{ "UserName" ,"Password","FirstName","LastName","PhoneNumber" }
There is an equivalent message body for XML as well
One framework we are interested in as shown :
The JSON/XML Repository would contain all the XML/JSON message bodies of every unique API Endpoint(We have close to 350 such unique API URLs).
The Test case repository would contain all the relevant tests containing data to be passed into the JSON/XMLs. One such example is shown below :
JMeter would run these tests and export the response to a file which would be parsed and presented graphically by another reporting plugin/utility.
Could you please let me know if the above data driven framework is suited for Automating RESTful Services ? Also if Jmeter is the ideal tool for performing these tests.
Not sure regarding the "ideal" but JMeter is definitely capable in helping you automating your scenario.
Some references:
CSV Data Set Config or JDBC Request Sampler (depending in what format you have your data) - to read from Test Case Repository
Beanshell Pre Processor or Sampler combined with i.e. GSON to dynamically construct JSON or XML test structures
XPath Assertion - to validate XML response from server
JSON Path Extractor and Assertion (available through JMeter Plugins
Hope this helps
D.
JMeter is a perfect solution for this.
If you want to automate running JMeter and graphing here are some solutions using Jenkins and the CLI:
https://blog.codecentric.de/en/2014/01/automating-jmeter-tests-maven-jenkins/
Need Step by Step Guide to execute the Jmeter Scripts in Jenkins (with Hudson build) over Ubuntu
Another option is a paid solution with http://BlazeMeter.com which is basically JMeter as a service. They have an API and a Jenkins Plugin as well. A lot simpler but not free.
Lastly, also look at the JMeter plugin project which has some great JMeter extras
http://jmeter-plugins.org/
I would use Staf/Stax to call XML test cases, run JMeter and collect the results.
Here is a very good article about this.
I'm currently developping a REST Web service with Spring MVC.
And I am struggling to find the best way to do integration tests on my WS.
First solution : using rest-assured
Advantage : fluent api, really easy to use with its cool DSL
Drawback : when i perform POST or PUT requests on my WS, the state of my database is modified, and next tests are corrupted.
Second solution : unit test the controllers and perform integration tests at the service level separately
Advantage : i can control the state of my database, using Spring Test Framework and perform rollback after each test
Disadvantage : i do not perform end-to-end integration tests anymore.
Question : how can i use rest-assured to do integration tests without modifying the state of my database ?
Thanks a lot.
Why don't you delete the rest assured doubles and redirects before every test and set them up fresh for the test?
RestClient.delete "#{RestAssured::Server.address}/redirects/all"
RestClient.delete "#{RestAssured::Server.address}/doubles/all"
Or alternatively you can use different doubles for the GET and POST/PUT calls to the rest assured and use the redirects in between these calls.
I am not sure, your request makes sense as you state it.
RestAssured is just a framework to support you with testing. You can also write unit tests, that do the equivalent of PUT and DELETE (basically the internal implementations), which then modify the database state.
Or you can only issue HEAD and GET requests with RestAssured and not modify the database state by this.
Both of the options will only test parts of the code path if you leave any updates out, so your issue is orthogonal to the selection of RestAssured or hand written unit tests.
Of course you can mock your backend away, but either the mocks are trivial and you don't gain any insight. Or they are complex and you will need separate tests to assure that the mock objects to what you think they are doing.
In order to perform integration tests on a REST Spring MVC Web Service, the SpringSource team has provided a new library called spring-test-mvc, which is now integrate to spring-test.
http://blog.springsource.org/2012/11/12/spring-framework-3-2-rc1-spring-mvc-test-framework/
For my special purpose, it is more adapted than Rest-Assured.