When implementing API clients, you tend to always run in to the situation where you need to test if the client you’ve tirelessly worked on actually works. All your unit-tests are passing; now you just have to make sure! So you loosely wire it up in a console application and send a request, to then dump the response to a file or similar — a “manual unit test”.
I would argue that this is in fact the most important test of all, as it is the only test that truly verifies whether your client is working. Why leave it to manual testing? i.e.; wouldn’t a unit-test be nice for this as well? I would sleep better if Travis reported that Sentry accepted my request before every deploy.
So the idea in short is: Send a JSON-representation of an event to sentry, then have the API parse it and then respond accordingly, the only difference being that this event would not get saved.
I think the most elegant solution for this would be to simply provide a sandbox DSN, say:
Or to have a public sandbox DSN for this purpose, say:
The sandbox would follow all the semantics of the live environment, only it would not save an event, and always reply with an “agreed upon” event ID. As an extension it would be nice if the API responded with the “would be saved”-event, that way validation could be made more thoroughly on the client-side assertions.
I do realize this is somewhat of a “luxury feature”, but it is not uncommon for API’s to provide sandboxes.