1

First of I'm not sure if I chose the right name for my question, I'm not sure if they are functional tests or integration ( or other ). I'm talking about tests which test (or it should) the app from a http request to database.

With simple controllers where they query the db for some data it's pretty easy to test them. Problem comes when things get complicated. When events are fired and there are a few listeners, which either send emails, create pdfs, make api calls. What's the best practice in this case ? Mock this events and ensuring from the functional tests that they are called with the right parameters? and unit test the events and listeners? or its safer to let them fire the events and see if the result is the expected one ?

In other words should functional and unit tests work together and should rely one on another ?

LE: I'm not trying to see benefits of unit vs integration, I just want to see how others do in the above scenarios.

Marius.C
  • 119
  • 3

2 Answers2

1

I believe that what you're talking about (connecting up the layers) is called integration testing.

How much testing of this variety should you do? Well, I'm firstly going to assume your unit tests are in place with good code coverage.

After that, concentrate on:

Racing line

How the software should behave most of the time.

Known corner cases

Exceptions to the above rules.

Limit testing

Pass in data outside accepted ranges of lookup values and at (and beyond) the limits of the datatypes.

Exotics

Anything else rare that wouldn't be covered by the above, like people using the system improperly, one of the layers going down, doing things out of sequence etc.

Clearly, the further down the list we get, the more time consuming it becomes and fewer bugs are yielded. There comes a point where further testing become uneconomical/expedient. Where exactly this line in the sand is varies from development to development. If you stop testing and the users find further bugs, then clearly testing wasn't sufficient. In the wild however, testing time tends to be squeezed especially is development overruns. Why the development would overrun is a whole different topic.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
1

Your question is really hard to answer in a general way. The purpose of integration testing is to test as much of the system as possible (ideally end-to-end), but the more end-to-end it gets, the more complex it gets.

For example you might want to automatically ensure PDF's are generated correctly with the correct information and layout. This is possible but quite complex, since you need to automatically parse and query the generated PDF's. If you are say creating an invoicing system where the PDF's are of critical importance, it might be worth it. In a system where the PDF's are less critical, you might be satisfied with mocking the PDF generation.

There is no "best practices" that can save you here, you have to make a trade-off decision based on available resources and your understanding of the business requirements.

JacquesB
  • 57,310
  • 21
  • 127
  • 176