Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

e2e Testing: Stubbing HTTP interactions made by the browser #7

Open
kanhirun opened this issue Jun 13, 2016 · 1 comment
Open

e2e Testing: Stubbing HTTP interactions made by the browser #7

kanhirun opened this issue Jun 13, 2016 · 1 comment

Comments

@kanhirun
Copy link
Contributor

kanhirun commented Jun 13, 2016

Background

In our code, we dynamically create a <script> that is injected into the DOM to be evaluated by the browser engine—the specific code [source] was copied from Zendesk. When evaluated, the browser makes an HTTP request as normal, and the response is rendered as an <iframe> to display a third-party widget.

There are many reasons to mock out this HTTP interaction:

  1. Better reliability because test failures will be isolated from some external factors (i.e. connection)
  2. Faster development because of no network latency
  3. Better [defect localization](http://xunitpatterns.com/Goals%20of%20Test%20Automation.html#Defect Localization) because it wouldn't test Zendesk, but our application interfacing with Zendesk.

Problem

There doesn't seem to be a tool that makes mocking this specific task convenient. Insofar, the solutions I've discovered are less flexible; they work with stubbing services that are within angular's API (i.e. $http, $httpBackend), but it is unclear if there are tools available that mock requests made directly by the browser.

Here is a list of some tools I've peeked into so far: connect-prism, protractor-http-mock, httpbackend. Out of the three, connect-prism has the best fit being a middleware solution.

Alternative Solutions

  1. Change production code to use $http instead of the Zendesk embed code. This increases testability because we would be able to leverage http stubbing libraries.
  2. Avoid mocking solution, and simply test through Zendesk. This can be implemented very easily, and gets the job done.

My question: Are there are mocking toolkits or frameworks that can handle this specific task that you know of? If not, what are your thoughts on the alternative solutions or your own suggestion?

@bsouthga
Copy link
Contributor

This sounds like a good idea to me (using $http) -- part of this could also be formatting / commenting the widget initialization code. That might also help find another more elegant solution for this issue: #3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants