Front End Development Automation with Puppeteer. Part 2
Tags: webdev, automation, javascript, node
Published: 2018-05-27 00:24:05

---
title: Front End Development Automation with Puppeteer. Part 2
published: true
description: 
tags: #webdev #automation #javascript #node 
---


[Link to Part 1](https://dev.to/papaponmx/front-end-development-automation-with-puppeteer-part-1-2k9n)

## 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](https://github.com/papaponmx/puppeteer-in-the-wild)**.  




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](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) 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](https://dev.to/papaponmx/front-end-development-automation-with-puppeteer-part-1-2k9n), 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.

```JSX

<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](https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#puppeteerlaunchoptions) 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:


```Javascript

// 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](https://github.com/papaponmx/puppeteer-in-the-wild), again.

```javascript

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.