Testing interactions with external systems

Question

I'm trying to find a way to test the interactions of our platform with external servers, like Twitter, for example.

On our online photo sharing application, we have, for example features which let the user publish a content on his/her Twitter feed. The code relies on Twitter4J.

How can we write an automated test to check if a tweet was really sent to the feed, publishing photos on Facebook etc.

The difficulty is: I can hardly modify the API in order to make my specific test, and of course, I have no influence on the external system.

Answer 1

One of the fundamentals of testing is isolation - how do you make your test environment as isolated as possible. When you're dealing with internal resources, this is fairly easy as you have complete control over the environment. External resources, not so much.

For this instance, I would recommend you create a couple test twitter accounts. (I would hope it's not against their TOS, I would check this first.) You might have TrarothTest and TrarothTestFollower. You could have it auto post to TrarothTest, and then wait to verify that TrarothTestFollower has acquired a new tweet from TrarothTest.

So you're dealing with accounts you have complete control over, isolating the environment as much as possible.

You will run into things from time to time you can't control with this. What if twitter is down (and what would hipsters do while twitter is down? :-O) or someone drives a shovel through your local fiber line running out of town? In this case, it would seem you need an alternative: a locally hosted twitter site. It might be a lot of extra work to maintain, but you could send the traffic to your local site and make sure it's what you would expect. Then simulate the tweet and "verify it happened".

Answer 2

I generally prefer to create the majority of my tests using mocks, in this situation, so I don't have to worry about whether Twitter is down, inaccessible, slow, or has users getting annoyed by a large number of posts that are just for tests. With mocks, you are less concerned about the end behavior and more concerned that the API is being called correctly. Mocks, at the very least, present an API that looks like the external API and can be called in an identical fashion (you use a configuration parameter that the developers or your product provide to point at your mock service) and return a value. Smarter mocks can be set up to "playback" certain values when their API methods are called, so you can also get back responses like the ones you expect (after setting the responses up earlier in your test).

This could reduce your dependence upon Twitter itself, but you would still need to do some end-to-end testing using mock accounts at some point. You might be able to just use manual tests at that point, if getting automation to work with Twitter turns out to be more difficult than you expected - but hopefully Twitter's API allows for easy automated checking that your code is interfacing properly. Glowcoder discusses this process in another answer, so I won't reiterate that explanation :)

Answer 3

External systems can definitely get in the way of doing end-to-end testing. Sometimes you have to test your interface to an external system separately from the rest of the product.

For example, at my current job, one our product features is the ability to move money between bank accounts. We don't have "test bank accounts" or a way to simulate bank accounts at the banks. We move the money via ACH files, so my approach to testing the money-moving feature is two-fold: use automation to test how we generate ACH files, and manually test that the bank can process the files we generate.

You could use the same approach with your Twitter interface.

Another thought: I don't know about Facebook but isn't there an RSS feed for Twitter?

Answer 4

It depends on if you are confident that the external system will be consistent with its contracts.

I have been in situation where the "external" system is maintained by other group within an organization. The other group is notorious for the workings of their API without proper communication. It also happens that their changes does not change the WSDL (it was a web service).

In that scenario, we put in a full suite of integration test against the external system to ensure we detect any deviations. The tests served us well. We were able to catch deviations early and rectify them.