3

I have a Spring boot + REST application. When I need to write unit testing, should I directly invoke the service beans or call the rest controller? If I invoke the rest controller directly, I have to use RestTemplate and invoke the rest api as a client, right?

What would be the best and required practice?

If I invoke the service beans directly it will result in less code coverage because controller methods code will be not covered. Is that acceptable?

THelper
  • 15,333
  • 6
  • 64
  • 104
Harshana
  • 7,297
  • 25
  • 99
  • 173

4 Answers4

2

Hmm, this is a complex question but I'll answer as best I can. A lot of this will depend on you/your organization's risk tolerance and how much time they want to invest in tests. I believe in a lot of testing, but there is such a thing as too much.

A unit test tests the unit of code. Great, but what's a unit? This article is a pretty good discussion: http://martinfowler.com/bliki/UnitTest.html but a unit is basically the smallest testable part of your application.

Much literature (e.g. https://www.amazon.ca/Continuous-Delivery-Reliable-Deployment-Automation/dp/0321601912/ ) describes multiple phases of testing including unit tests which are very low level and mock externalities such as DBs or file systems or remote systems, and "api acceptance tests" (sometimes called integration tests although this is a vague term that can mean other things). This latter type fires up a test instance of your application, invokes APIs and asserts on responses.

The short answer is as follows: for unit tests, focus on the units (probably services or more granular), but the other set of tests you describe, wherein the test behaves like a client and invokes your api, are worthwhile too. My suggestion: do both, but don't call both unit tests.

Taylor
  • 3,942
  • 2
  • 20
  • 33
  • I think if you do integration testing it cover unit testing too. So no need to again write unit test cases also know – Harshana Jul 05 '16 at 04:11
  • Debateable. Unit tests are often created as part of TDD, so they serve slightly different purpose. They drive design, ensure compartmentalization and single responsibility, and reveal the intentions of the developer writing the code, and how the dev envisioned using the units they built. API level acceptance testing is more to ensure you've met (and not regressed on pre-existing) acceptance criteria. – Taylor Jul 05 '16 at 15:09
1

Best Approach is to Test VIA Controllers. WebServices are entered and values are returned here. So Controller is having quite a good role in this. There can be small logic as well, you may miss that

You can Try Using the MockMvc Method for testing controllers.

Reference: Reference-1, Reference-2

Or use the RestTemplate as you mentioned in question Reference-3

Community
  • 1
  • 1
Viswanath Lekshmanan
  • 9,945
  • 1
  • 40
  • 64
0

It is based on what you want to test, you can separate your test, specially if you have team of developers, make test case to test your business "services", and another test cases as integration test to use REST template, in this case you can figure your bugs faster and easier.

Bassem Reda Zohdy
  • 12,662
  • 3
  • 33
  • 39
0

It depends on what you want to do.

One approach would be to unit test the units of work, like the service and the MVC controller. These test will only test eventual logic found in this classes and try to reach a high branch coverage, if applicable. Besides this, you can write an integration test that makes the HTTP request, goes to the real service bean and only mock an eventual resource access.

For integration tests you can use Spring's support, see here: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/integration-testing.html#spring-mvc-test-framework

Alexandru Marina
  • 906
  • 5
  • 9