I have to write a microservice(springboot application) with cucumber. The microservice is dependent on another microservice from external environment. We have written a mock for the external microservice. In order to perform end to end flow, we have to run the mock.
How can I run the cucumber for end to end txns?
Can I run the mock service from cucumber as an independent microservice before executing the scenarios? if yes, how can we do it?
Related
I am building a microservice architecture with different Spring Boot projects and two different repositories for each one of them:
One application is called project-api-1
The other one project-api-2.
Now, within the JUnit tests of project-api-2 I need to test some functionality that requires making a REST call to the API exposed by project-api-1.
Is there a way to link these projects together for testing purposes, in such a way that when I run the tests for project-api-2 I can also start the project-api-1 application at runtime, without having to create a mock API of project-api-1 from scratch within project-api-2?
What is the best practice here?
I ended up solving this problem by running a multi-module Maven project, and importing the REST API project with <scope>test</scope>.
In my tests, I then start the Spring Boot application with:
new SpringApplicationBuilder(RestApplication.class)
.profiles("test")
.run();
I'm running functional tests using Spock where the tests manipulate the database, and the Specs can conflict with each other if run simultaneously. From my web debugger, it appears that when I run gradle test that the calls to the web service from different Specs are being called simultaneously. The Specs themselves are being called with the #Stepwise annotation, and the tests are run in the correct order. How can I have Specs run separately in some order? They do not need to run in any specific order.
Is it possible to write junit test that persist in mysql using hibernate / jpa?
If so any example available?
I'm using spring/hibernate for my application
When you have real database connection I would not call your test unit test, but more like integration test. To be honest this kind of tests is not a good idea in most cases. It requires some maintenance (every time you have changes in db), and in most cases just tests if it is possible to connect do database (and save some simple object).
Focus on writing good tests for domain level classes. Simple database integration tests will only give you illusion of high quality application.
If you want to write an integration test that looks like a unit test, you could try Arquillian.
What Arquillian does is basically start an application container (Glassfish I think is the default), then it deploys your server-side application in the container and runs the tests against the just-deployed application.
What you write in the unit tests is really client code, so that what you are effectively running is an integration test (with a real database and all the services you would have in a real environment), just in a junit-like way.
They also have a specific tutorial for persistence testing.
If I want to unit test my dao classes in spring would I just call my service methods and test those or would you test the service methods separately to the actual dao methods?
Also should I mock the dao calls or actually use an in memory database like H2? I see that as more of an integration test although some tutorials do this, or would a standard approach be to test with mock database objects for the service tests and use H2 when testing the dao calls?
Finally.. My application has a rest API which is called from the web front end using the Spring rest template and so only the API web app accesses the database.
Would I test the rest methods in each web app using mocked objects and then Start a tomcat instance and integration test between the 2 apps? If I used tomcat and ran integration tests between the apps would connect up a database or mock objects in the API app?
Testing the rest calls from the web app relies really on how the API app's rest method responds so is this even worth testing in isolation?
I find unit testing quite confusing as some of it seems almost to be integration testing.
Does it matter if you run integration tests against H2 in memory but then in reality I would be using MySQL?
Trying to answer your questions in the order asked...
For unit testing DAO methods, you should test the actual DAO classes directly with a database in a known state. H2 is great for this, since you can run it without setting up MySQL for each test. Utilizing setup methods with the #Before annotation is great to make sure that the database will respond in expected ways.
For unit testing Service classes, you should mock the DAO classes, so that they will always behave in expected ways. If you use your service and DAO classes with actual data, you are now running integration tests, by testing multiple layers simultaneously. Both have their value, though is generally best to unit test before integration testing, to make sure each component is functioning.
The same goes for testing your controller, you should unit test it and mock the service classes, and then perform integration tests with mock requests to test request/response scenarios. Again, with this test setup you are now testing many layers and classes simultaneously. This is great, because it gives you a good idea of how your application will function in reality, but is not useful for isolating bugs.
H2 and MySQL obviously are not the same, and don't share all the same functionality, so you can't say with 100% confidence that an H2 test will pass in MySQL, but if you are just testing standard CRUD operations, it should do the trick.
I have a maven/mule/spring development environment that I build REST services within. I also have a series of TestNG tests to validate these services. I also want the ability to alter the responses from the services, either returning specific information or throw an exception. This was I can automatically test broader behaviours of the services. I figured that mocking the services would be the best approach, but I cannot find any good information on how to mock a REST service.
Is there any material I can review on how to mock a REST web service?
--Update---
I thought I would add an example to make the problem more concrete. If I have the following setup:
testA calls serviceA, which then calls serviceB
If serviceA should return a web exception to testA if serviceB responds with an error, I would like to inject a mockedServiceB in to the system for the test where mockedServiceB always returns an error:
testA calls serviceA, which then calls mockedServiceB (which always returns an error to serviceA)
Generally speaking I would fragment my Mule configuration to have one service per fragment then load real service A fragment and a test service B fragment at test time. Test service B would use the Mule test:component to simulate good or bad returns.
I had the same problem and wrote a small lib for mocking REST services: https://github.com/mkotsur/restito.
You can give it a try.