2

Background:

I am working on a node project which consists of a core package and several addon packages. For the end product to work, the core package and atleast one of the addon packages should be integrated. These addon packages are basically database adapters. Addon packages have a production dependency on the core package. All the packages are planned to be distributed as separate npm packages.

I can do unit tests and test functionality of all components separately. But for me, integration tests are important and they test against a real database. I should be able to put together the core and addons, to test them in integration.

The question is, in which package should I do the integration test?

  • Do the tests in the addon packages. This seems the most 'right' and it is the first thing I thought. However, since the functionality of each addon is very similar, the tests are also similar. Implementing hundreds of similar tests for each of them will bring code duplication.

  • Do the tests in the core package. This will definitely remove code duplication. But it will cause a development dependency from the core to the addons. Also if a new addon is to be implemented, it will cause the core test suite to change?

  • Create a separate package just for integration testing. This will prevent code duplication. But it is something I have never seen an example of. Also, adding addons will cause this package to change.

3

In any integration there is a depender and dependee relationship. I recommend creating the tests in the dependee.

In your question the addon packages depend on the core package, so it's right for your first inclination to be to write the tests there.

since the functionality of each addon is very similar, the tests are also similar. Implementing hundreds of similar tests for each of them will bring code duplication

Create a separate package just for integration testing. This will prevent code duplication.

This is a good approach to the problem. These packages are usually called "automated test suites" and are useful in situations where a specification (e.g. your integration with core) is being tested agnostically of the implementation.

But it is something I have never seen an example of

Java has the JDBC API test suite for testing database drivers so that third-parties can create drivers and test them.

Tinkerpop has a test suite to verify third-party graph databases correctly implement the Tinkerpop API

Also, adding addons will cause this package to change.

The correct approach to this problem, the test suite should not be coupled to any specific addon. Just like the JDBC test suite above doesn't know anything about each driver. This package should include test code, but each concrete addon should configure and run the test suite customized to their needs.

In psuedo-code your test suite would have tests like so:

function testDelete(addon) {
  addon.insert(1, "foo")
  assert(addon.select(1) === "foo")
  addon.delete(1)
  assert(addon.select(1) === null)
}

and your addon package would have a test like so:

const addon = new PostgresAddon("localhost", "5432", "user", "pass")
testSuite.testDelete(addon)
  • 1
    My role model when developing this package was Karma. They also use a plugin based system. And seems like they also use a separate package for integration tests and I have overseen that. I started doing what you said and for now I have no problems. Thank you. – Gökhan Kurt Sep 8 '17 at 5:22

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.