• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Integration tests - how much to test?

 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi. I have a question about integration tests.
Our codebase has a lot (really, a lot) unit tests, that mock dependencies, perform negative tests (like testing how a service will behave on invalid input or an exception being thrown somewhere deep and so on), test various permutations of input - we take good care to tests as much as we can. The result is obvious - we are very confident about our units that they work by themselves, adhere to their contracts and so on - the little classes that will eventually be assembled into modules / application. As mentioned, we use mocks wherever possible to make sure we test a single unit at a time.
Now, time has come for integration tests. Our application has a service module, that uses persistence module and many others. It has also a facade module that is coded as EJBs that use the services internally (injected via CDI), to have JTA support, security, serialization guarantees... The whole application is a Java EE 6 application, we are using GlassFish 3.1 (snapshots) for the embedded EJB support - this allows us to have tests that look up EJB, invoke methods on them, have dependency injection performed by CDI, have JTA transactions where we need them and so on. We also use a real database (PostgreSQL, the target for the initial release), and we use DbUnit to fill it with data whenever it is important (pretty much everywhere). The whole infrastructure is very complex but very powerful, we are using our own framework build upon TestNG, we can test whatever we like, and we have dependency injection into test instances as well.
The question is - how much to test in integration tests? For example take ServiceA that was tested for invalid input, for underlying storage exceptions being thrown, for various calls with valid (but differing) input so that we know that we handle what is necessary - this was all done in unit tests. Do we have to repeat all the tests in 'kind of real' environment now (kind of as it is not real deployment but EJB embedded, but this is as close as we can get), or is it enough just to include a few test that test 'valid paths' in the application, and not test everything again? As far as I know, we need integration tests to see if the module assembly is correct (no unsatisfied dependencies), that the parts can work together and so on, but not necessarily test every single permutation of input (valid and invalid) for each service - this would basically duplicate unit tests for this specific behaviour.
What do you, experienced test specialists, have to say?

Raf
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Raf,
Right. The idea isn't to duplicate the unit tests. It is to test the integration and major application flows. For example, I can test what happens for many error conditions more easily in a unit test than integration test.
 
New rule: no elephants at the chess tournament. Tiny ads are still okay.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic