2

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?

Improve this question
10

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.

Improve this answer
4
  • 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 Nov 11 '11 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)? – Muhammad Alkarouri Nov 11 '11 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). – Péter Török Nov 11 '11 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. – Sam Goldberg Nov 11 '11 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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