Using Test Doubles in Browser-Based JavaScript Applications

The various thingies that make up any stateful application - things like the HTML, CSS, images, JavaScript, etc. in an HTML App - are more stable than the thingies that drive our application, or are driven by our application.

• Users - different users will each be running and interacting with our application at various times. For the most part they will all be using the same version of our application at any given time (using Progressive Web Apps may alter this, though.) For most applications, the user's identity will have to be part of our application design. Users will then have various persona that we will have to simulate. Examples might include a "new user", a "power user", a "pro plan user", a "free tier user", an "admin" or "manager" user, and maybe an "unauthenticated user". There are parts of our application that will branch based on the persona of the user (for example, an "admin user" might have additional affordances in the UI than a non-admin user). The less branching the better, of course - so we tend to generalize where we can. For example, we don't create a persona for a "disabled user". We rely on web standards and good accessibility patterns for our entire application.
• Devices - These users may use various devices to access our application. They could be using desktop browsers, mobile devices ranging from small smart-phones to high-resolution tablets. Using responsive web design will handle much of this for us, but we need to be able to simulate various devices and configurations of those devices (orientation, resolution, etc.).
• Browsers - While we will largely assume all of our users will be, at any given time, using the same version of our application, we cannot (nor should we) assume each user will be using the same browser, or the same version of any browser. We also need to simulate various data provided by the browser and browser APIs if they impact how our application is presented to the user. An example would be things like the geolocation API, and even the clock.
• Network - Network speed, latency, and availability will vary over time, even for a single user. A common design mistake made by web developers is assuming all users will have the same performance experience the developer does when writing the application, which is just silly. The performance of the application while you create it on your developer machine is always going to be the best possible experience. Every other use of your application will perform worse.