I'm working on a project with an AngularJS app that talks to a RESTful API. We've just started writing E2E tests for the app in Protractor. I'm fairly comfortable with unit testing but new to end-to-end testing.

We're writing a test that tries to send a message. Currently the test fills out the form, clicks the send button and then verifies that the success dialog is shown. This doesn't really seem like a good test, because theoretically the success dialog could be erroneously shown when the message wasn't really sent, but the test would still pass. We want to be able to check that the message was really sent, but I'm not sure how best to do this.

We could navigate through the interface to view our sent messages and then check that the message is in that list, but I feel there are a few problems with this approach. First, it ties together our send message and view sent messages tests, which seems a bit messy. Second, it increases the complexity of writing tests, because essentially the length of each test is doubled to include the code for checking the results. Third, in some cases the result of the user's action may be hard to verify from within the user's interface. For instance, with sending a message what we really want to verify is that the recipient received it, not that it appears in the sender's sent messages section.

The next idea I had is that we could have our test perform the action and then directly call the API to verify the result. Using different tokens we could even talk to the API as another user (e.g. the recipient) to be certain that the intended result was achieved. My only concern with this approach is that it might be adding too much logic into the test suite, which seems to be against best practices.

Another idea I had was to mock all API requests (using something like ngMockE2E's $httpBackend) and somehow assert within each test that a specific request was made. The issues I see with this approach are that there's a lot of work involved in writing the mocks for our API, and also that I don't think there's any builtin way to do this checking, so we'd be writing our own non-standard testing solution.

It seems to me that this must be a fairly common problem, so I'm keen to hear from people how they've approached it and what they like/dislike about their solution.

  • 1
    Do you also have unit tests against the mock backend to ensure that the success confirmation appears if and only if the sending request succeeds? Integration tests for the API that the requests only succeed when the message has been stored and/or sent on?
    – jonrsharpe
    May 5 '17 at 6:50
  • Good point, we do have integration tests for the API that the requests only succeed when the message has been saved to our database. We don't have unit tests against the mock backend, that seems to be the piece of the puzzle we are missing. If we have both of those then it becomes unnecessary to perform this check within the E2E test suite, right? Thanks for your input, that's helpful. May 6 '17 at 7:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.