I have software that connects to several marketplace APIs such as Amazon, eBay, Etsy, and so on and imports it into our database.

I've written a basic test. The test provides an order number for each marketplace importer. Each importer attempts to import it's order number. The test then asserts if this order exists in the database.

On one hand, a single Amazon import will call several different functions and does many different things.

On the other hand, all these importers act independently from each other.

Is this unit testing or integration testing.

  • That depends, are you testing one unit which its only role is to contact each marketplace and store the result somewhere (just an example) ? Or are you testing a couple of function all together in the same test, or the multiple implementation of one interface ? By default according to what it is said. I will go for integration tests, but what does it changes for you that it's call a unit or integration test ?
    – Walfrat
    Mar 28 '17 at 13:52
  • @Walfrat Each importer is very different, but in general many importers do more than just import, such as acknowledge, record data for outbound, record data to be passed to accounting, and so on. As to what it matters, I just have a poor understanding of what people mean when they talk units and unit testing/integration testing and I thought this question would help me understand by applying it to what I do.
    – Goose
    Mar 28 '17 at 13:55
  • 2
    If you're calling actual Amazon servers, it's an integration test.
    – Eternal21
    Mar 28 '17 at 16:14

Rule of thumb: If your test data is mocked (e.g., you already know what will be returned) your test is unit test. Otherwise you have a integration test

For example, when you use C#+MOQ and configures the .Returns((List<string> result)=> return myPreviouslySetList;) you are mocking a return. So you are not testing if whether you can actually hit a database, but what your method will do with the given data... so, Unit test!

Edit 1
In this specific scenario, I believe you have a mix of both, so you default back to Integration Testing. I would recommend you to mock the data for two reasons:

  1. You can test scenarios that are hard to find in prd environments
  2. You don't waste time testing the same scenario again and again

Edit 2
If you are worried about APIs breaking i'd suggest contract testing! they are really useful! (https://martinfowler.com/bliki/IntegrationContractTest.html)

  • 1
    I'm unsure if you're implying that I'm unit testing or integration testing. I'll clarify on the details. On most import tests, all I provide is the order number, and everything runs as if real, and afterwards I check the database to at least see if the order now exists in the database. On some import tests, I can't reach out to an API, for instance they email a CSV, so I'll mock the CSV in a string and use that to import and then check that it exists. Is the CSV example a unit test and the true API examples more of an intergration test?
    – Goose
    Mar 28 '17 at 14:00
  • 1
    You updated to suggest I should mock the data. I'd extend that to say create a separate test that mocks instead of uses the API. I say this because APIs break frequently, and that's something I want to catch as well as problems inside my code. I guess that sentence I said right there strongly suggests that I am using these tests like integration tests.
    – Goose
    Mar 28 '17 at 14:12
  • @Goose check out new edit
    – Leonardo
    Mar 28 '17 at 14:14
  • Intergration Contract Testing; That sounds extremely useful for what I do! Can't tell you how often I've had an API appear to change what it returns, with me having no easy way to verify. This has been a very helpful answer.
    – Goose
    Mar 28 '17 at 14:20

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.