We have a use case for regularly publishing our own data to Twitter (as tweets). We have Elevated Access. We have setup a specific app using OAuth 1.0a, and written the appropriate code to post the tweet under an Automated Handle that we control, via the v1.1 API. Everything works.
Our concern is as follows. We have automated tests which cover our application’s functionality, and we would naturally like to have automated tests for this use case.
It is easy to write the tests, but the question is: where do they tweet to? We have separate dev, test and production databases but it seems to be impossible to have dev, test and production ‘clones’ of a twitter handle. The Twitter Developer docs suggest that apps can be dedicated to dev, test and production, but these apps all seem to post to the live stream, not to a separate “sandbox” stream.
Are we missing something obvious?
Otherwise, it seems like the only solution is to create multiple handles, e.g. @ myhandle, @ myhandledev, @ myhandletest , and set the non-production handles to “Protected Tweets”. In our case this means going through the whole procedure to request Elevated Access for each handle, set up Projects and Apps etc - altogether quite a lot of effort.
The best way for automated tests for posting tweets I found so far, is to mock the API responses as opposed to actually making them. It does mean it’s not a live test, but it gets around the issue of randomly failing tests because you’ve hit a rate limit or something else. How you do that depends on the testing framework you’re using - but generally there should be a way to mock an API response.
1 Like
Thanks. We could mock the API response - the API itself is not complex - but what is really interesting to test are all the rules behind it governing when a post is allowed or not. Difficult to mock those without significant dev effort.
What we can do though is factor out the code which builds the tweet content and test that for obvious gotchas (such as excessive length).
1 Like
