5

let's say we have some web service with REST API and for illustration there is some work with database. In my opinion, the most fundamental way to test this application are integration tests which are testing it from top of the REST API to verify it's working correctly whole all. But what about unit tests using some mocking technology? Is it really necessary in professional development (with of course limited human resources) to cover the code with unit tests even it already has been covered by integration tests?

Thanks

Jurass
  • 435
  • 1
  • 5
  • 17
  • 1
    I'll just leave this here as a comment :D may be worth a watch https://www.youtube.com/watch?v=VDfX44fZoMc – JSelser Feb 27 '17 at 23:09
  • 1
    That's very nice explanation, thanks for that! But I have such feeling that in usual corporate practice it's close to impossible to write such highly structured unit test how that guy recommend even if it is the best solution. So what I see on usual-corporate Java projects is there are very isolated unit tests independent on each other in consistency, which tests capabilities are very doubtful. – Jurass Feb 28 '17 at 00:35
  • http://stackoverflow.com/questions/42469686/does-unit-tests-still-matter-if-functional-tests-is-satisfied/42476254#42476254 just answered same question here, will repost answer since can't vote to close as duplicate because it doesn't have any upvotes/accepted – dm03514 Feb 28 '17 at 00:39
  • @Jurass Im far from knowleadgable and I'd say there's a huge component of opinion to the whole matter. I just happen to agree on the notion that unit tests are actually not for asserting system correctness but for code design purposes, unit correctness coming second. In this sense I'd say the purpose of both kind of testing are quite different, even if the same code is covered twice. They guy on the video is not telling you not to do integration testing but to do it on the frontier of your system, that would prevent your double cover problem, maybe? Sorry, I dont know :D – JSelser Feb 28 '17 at 02:14
  • It's not "necessary", though there are definitely benefits in having unit tests in place. ;) It's not enough to have unit tests only, as some bugs do occur on integration level. Benefits of unit tests over integration tests are quick iterations and ability to pinpoint the problem. The integration suite will run times longer, than a whole bunch of unit tests. As well, when an integration test fails, you'd spend more time to track the root cause. They're more prone to be brittle. To put it in a nutshell, having unit tests in place makes you life easier. Have you heard about Test Pyramid concept? – buxter Mar 02 '17 at 13:47

1 Answers1

4

Good question. Answers will be opinion-based, of course, but hopefuly they are based on actual real-world experience.

In my case, I've written thousands of JUnit/TestNG tests over the years, and I happen to develop an advanced testing library (mocking + code coverage + integration testing) for Java.

So, IMO, it's not needed and not productive to write unit tests when you already have a good integration test suite.

Integration tests do take longer to run, of course, but they should still be fast enough that a developer is not discouraged from running them. This is what matters: if the developer can still productively run one test, one test class, etc. when developing new code or modifications, then it's fine. So, avoid integration testing approaches (eg, Selenium) that make test execution too slow/painful.

Another criticism made against integration tests is that they make it harder to figure out the root cause of a test failure. This is not a big enough issue in practice, though.

Martin Fowler makes these same two points in his Unit Test article.

Rogério
  • 16,171
  • 2
  • 50
  • 63