Over the past few weeks I've been mulling and researching how to fill a gap in our testing methodology. In simplified terms unit tests are too small and traditional integration tests are too big.
A frequent scenario comes up where
B both use component
B have slightly different requirements for, and make slightly different assumptions about
C. If I'm the developer of
A how and where do I test my assumptions about
Obviously unit testing
A with mocked assumptions about
C is fine for testing
A in isolation, but it doesn't test the assumptions themselves.
Another possibility is to add unit tests for
C. However this isn't ideal because, while
A is in development, altering the tests for
C with evolving assumptions from
A will excessively be clumsy. Indeed
As developer might not even have adequate access to the unit tests of
C (e.g an external library).
To frame this with a more concrete example: Assume that this is a node application.
B depend on
C to read a file (among other things) and store the file contents in object passed to
C. At first all files that
C handles are small and can be read synchronously without significant blocking. However the developer of
B realizes that his files are getting huge and needs to switch
C to a async read. This results in a sporadic synchronization bug in
A, which is still assuming
C is reading files synchronously.
This is the type of bug that is notoriously difficult to track down from full integration tests, and may not be caught in integration tests at all. It is also not caught by
As unit tests because the
As assumptions are mocked. However it could easily be caught by a "mini" integration test that exercises just
I've only found a few references to this type of testing. Integration in the Small, Component Integration Testing, Unit Integration Testing. It also relates somewhat to BDD testing direction rather than formal TDD unit testing.
How do I fill this testing gap? Specifically -- where do I put such tests? How do I mock the inputs of
C for "mini" integration tests? And how much effort should be put into separating testing concerns between these tests and unit tests? Or is there a better way to fill the testing gap?