When writing a program, should I write tests that ensure that the dependencies I use are working? Those might help to check my assumptions about them, and may also help when deciding to upgrade said deependencies.

Also, are there any established opinions or schools about whether or how one should go about that?

1 Answer 1


Yes, you should definitely write tests to verify that your external dependencies are working. However, these aren't unit tests but integration tests.

Unit testing exercises small parts of your code in isolation - that is, isolated from external dependencies, using e.g. mocks. This way you can verify that each small part in itself works as expected. After that, you still need to verify that the whole app, in its fully assembled form, works properly. However, in those tests you exercise the whole system on the highest level, via its user interface (command line / GUI / web / whatever). So integration tests are very different from unit tests, in several ways: usually they

  • take much longer
  • are harder to automate
  • needn't be as detailed

In the technical sense, integration tests overlap with system / validation / acceptance / functional tests, whereas each exercises the functionality of the whole system. However, the purpose of integration tests is simply to verify that the system in its assembled form works correctly in general, so it doesn't test each and every piece of functionality down to the nittiest details. However, one can use the same tool(s) for each of these kinds of tests. These tools can be very different, depending on the UI and platform of the system. Wikipedia's Test automation page lists references to some well known tools.

  • Also, integration tests are often much less reliable (i.e. tend to fail even if there is no bug in the tested program, because e.g. the external server they rely on is not there).
    – sleske
    Commented Nov 11, 2011 at 11:44
  • That is not exactly what I had in mind. I am not testing the relationship between my application and the external dependency. Rather, I want to do something similar to an autoconf test to see whether the dependency supports a certain capability or not. For example, I am dependent on a specific capability of a web services stack. Should I write a test to check if this ability still works (for example on future versions)? Commented Nov 11, 2011 at 13:10
  • @MuhammadAlkarouri, no. You should write a test to prove that your app can handle a situation when the specific capability is missing from your dependency (e.g. fails early and gracefully emitting a clear error message, or degrades its service level accordingly). Commented Nov 11, 2011 at 13:36
  • 1
    @Muhammed: It's a little unclear in what context of testing (e.g. unit, functional, QA) you are asking about. If your dependencies are integrated into your project (for example as Java Jars, C# assemblies, or C dlls), then you should see unit tests fail if some feature is no longer supported by those external libraries. (And it's very likely you would see compile failure as well). That would address code level dependencies. If you are talking about testing or validating system or service level dependencies, that falls under the category of integration test as Peter noted above. Commented Nov 11, 2011 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.