Link to Part 1

Intro Paragraph

As I've told you before, this series was inspired on problems I've faced on my day to day work as a Front End Developer. Here is my creative solution. I know I'm not supposed to repeat my self, but here is the link to the repo.

In last section we waited for selectors to appear on the screen, clicked and typed in a form.

In this part of the series, we'll be introducing two new variables to the scenario.

Scenario 2: Something stoped working, can you take a look?

Inspired on something that came up last week. There is an internal CRUD application.

A nasty bug was fixed on the back end, and that required to remove unnecessary logic from the Front End. Using a script similar to the Part 1 of this series, we doubled checked that the CRUD operations are still taking place the way they are supposed to.

However, after a network request was successfully completed, one of the parameters was not being displayed on the screen. The code looked something like this.

<a>{ env.base_url + broken_reference } </a>

The solution

I put a debugger in place, just before the broken link is rendered. Then adjusted the script to do two more things:

1. Open a head-full Chrome instance. That is, one with a
2. Do it with developer tools open, so the [debugger statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger) actually works.

Let's walk trough the solution. The Puppeteer launch method, takes as a parameter an object where we can override some default options.

This is useful when:

• When we need a specific viewport, think of mobile devices not showing something.
• To catch some errors, think of a network request not working as expected.
• You need developer tools open, like the scenario described above.
• You need to pass environment variables.
• You want some extensions enabled.

Here is what it looks like in code:

// Ideally this lives in another file
const options = {
    devtools: true,
    headless: false,
    viewport: {
      width: 1920,
      height: 1080,
    },
    args: [
      '--disable-extensions-except=/path/to/extension/',
      '--load-extension=/path/to/extension/',
    ],
}

// ... within an async function

const browser = await puppeteer.launch(options);

Here is the test to run in a single file and the link to the repo, again.

const fs = require('fs'); // Nodes File System
const puppeteer = require('puppeteer'); // High level API to interact with headless Chrome
const signale = require('signale');
const locators = require('./locators'); // A JSON with all the CSS locators we need.
const config = require('./config'); // Some project variables and the browser options

const {options} = config;
// 1. Open browser.
const runTest = async (params) => {
  signale.debug('Opening browser...');
  const browser = await puppeteer.launch(options);
  const page = await browser.newPage();
  const d = new Date();
  const dateString = `${d.getDate()}_${d.getHours()}h${d.getMinutes()}`;
  const userName = `USER_FROM_TESTING_SCRIPT_${dateString}`;

  // 2. Go to the website;
  await signale.watch('Navigating to the site 🚢');
  await page.goto(LOCAL_HOST_URL);
  await signale.watch('Filling up the form 🙌');
  await signale.success('Everything is working as expected ✅');

};


runTest();

That's all for now folks. Here is what I'll be covering on the next posts:

Scenario 3: Compare a snapshot of local vs test.
Scenario 4: Headless with user manual input.