DEV Community: Pinto Infant

UI Automation Using Puppeteer

Pinto Infant — Sun, 01 Jun 2025 05:27:45 +0000

1. Introduction to Puppeteer

Puppeteer is a Node.js library developed by Google.
Provides a high-level API to control Chrome or Chromium over the DevTools Protocol.
Ideal for automating browser tasks such as UI testing, web scraping, PDF generation, etc.

2. Features of Puppeteer

Headless browser automation (can also run in headful mode).
Full control over page elements (DOM manipulation, navigation, inputs).
Screenshot and PDF generation.
Simulate user actions (clicks, typing, scrolling).
Network interception and monitoring.
Useful for testing SPAs (Single Page Applications).

3. Installing Puppeteer

npm install puppeteer

Installs the library along with a compatible Chromium binary.

4. Basic Script Example

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({ headless: true }); // or false for UI
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({ path: 'example.png' });
  await browser.close();
})();

5. Common Puppeteer Commands

Action	Command
Launch browser	`puppeteer.launch()`
Open new tab	`browser.newPage()`
Navigate to URL	`page.goto('url')`
Type into input	`page.type(selector, text)`
Click a button	`page.click(selector)`
Wait for element	`page.waitForSelector(selector)`
Take screenshot	`page.screenshot({ path: 'file.png' })`
Evaluate JS	`page.evaluate(fn)`
Close browser	`browser.close()`

6. Use Case: Login Automation

await page.goto('https://example.com/login');
await page.type('#username', 'yourUsername');
await page.type('#password', 'yourPassword');
await page.click('#loginButton');
await page.waitForNavigation();

7. Wait Mechanisms

waitForSelector(selector) – Waits for element.
waitForNavigation() – Waits for page load/navigation.
page.waitForTimeout(ms) – Waits for a fixed delay.
Helps synchronize automation with dynamic UI.

8. Handling Alerts/Dialogs

page.on('dialog', async dialog => {
  console.log(dialog.message());
  await dialog.accept();
});

9. Taking Screenshots & PDFs

await page.screenshot({ path: 'page.png', fullPage: true });
await page.pdf({ path: 'page.pdf', format: 'A4' });

10. Emulating Devices

const iPhone = puppeteer.devices['iPhone X'];
await page.emulate(iPhone);

11. Headless vs Headful Mode

Headless: No browser window shown; faster; for CI/CD.
Headful: Browser UI is visible; helpful for debugging.

puppeteer.launch({ headless: false }); // To see the browser

12. Advanced Features

Intercept network requests:

  await page.setRequestInterception(true);
  page.on('request', req => {
    if (req.resourceType() === 'image') req.abort();
    else req.continue();
  });

Evaluate JavaScript in the browser context:

  const title = await page.evaluate(() => document.title);

Upload a file:

  const input = await page.$('input[type="file"]');
  await input.uploadFile('/path/to/file.txt');

13. Use Cases

UI Testing & Regression Testing
Automated Form Submission
Capturing Screenshots for UIs
Performance Monitoring
Web Scraping and Data Extraction
PDF generation of dynamic content
CI/CD integration for UI flows

14. Pros and Cons

Pros	Cons
Headless browser is fast and lightweight	High memory usage on large tests
Easy JavaScript API	Some browser features unsupported
Active community and documentation	Heavier than HTTP-level testing tools
Suitable for modern web apps (SPAs)	Needs Chromium; increases package size

15. Puppeteer Alternatives

Playwright: Developed by Microsoft; supports multiple browsers (Chromium, Firefox, WebKit).
Selenium: Older tool, supports multiple languages.
Cypress: Focused on frontend testing, rich GUI.
Nightwatch.js: Uses WebDriver API.

16. Best Practices

Always use proper wait methods to avoid flaky tests.
Run in headful mode when debugging.
Use environment variables for sensitive data (e.g., credentials).
Combine with Jest, Mocha, or Jasmine for test suites.
Use page tracing and console logs for debugging.

Nix Flakes: Engineering Truly Reproducible and Declarative Development Environments

Pinto Infant — Fri, 09 May 2025 11:42:31 +0000

The persistent challenge of ensuring software behaves consistently across different machines – from a developer's laptop to a CI server and production deployment – remains a fundamental problem in software engineering. The infamous "it works on my machine" is often a symptom of subtle, unmanaged variations in dependencies, system libraries, or environmental configurations that creep in with traditional, imperative approaches like apt install, brew install, or manual setup scripts.

While technologies like Docker address some aspects by packaging applications with their dependencies, managing the underlying build and runtime environment itself, consistently and repeatably, still presents hurdles.

The Nix ecosystem offers a powerful, principled alternative rooted in functional programming concepts. Nix is a purely functional package manager designed to enable declarative, reproducible, and reliable system configuration and package management. The introduction of Nix Flakes, while currently tagged as experimental, represents a significant evolution, standardizing how Nix-based projects define, build, and share their environments and outputs.

This post will delve into the technical foundation of Nix and illustrate how Flakes build upon this to provide an unparalleled level of environmental predictability for software development.

The Foundational Principles of Nix: Immutability and Determinism

Understanding Nix's core philosophy is essential before exploring Flakes. Its power derives from these key principles:

The Nix Store (/nix/store): An Immutable Content-Addressed File System
- Unlike traditional package managers that install files into fixed locations like /usr/bin or /lib, Nix places each package (or component of a package) into its own unique, isolated directory within /nix/store.
- The path of each directory is derived from a cryptographic hash of all its build inputs: the source code, compiler, libraries, build scripts, environment variables, etc. For example, /nix/store/sblq...-python-3.10.8.
- This content-addressing means if anything about a package's inputs changes, even a minor build flag, it results in a different hash and thus a new path in the store. The old version remains untouched.
- Benefit: Immutability guarantees that once something is built and placed in the store, it cannot be modified. This prevents accidental corruption or conflicts between different versions of the same library. Different versions can coexist peacefully.
Purity and Hermetic Builds: Eliminating Implicit Dependencies
- Nix builds packages in highly isolated environments ("sandboxes"). By default, these sandboxes have restricted network access and cannot see most of the host system's file system.
- A build process can only access inputs (source code, dependencies, build tools) that are explicitly declared in its Nix build definition, and these inputs are referenced via their unique /nix/store paths.
- Benefit: This hermeticity ensures that a build's success and output depend only on its declared inputs. It eliminates the "works on my machine because I installed X globally" problem. Builds are highly deterministic – given the same inputs, they will produce the exact same output hash, byte-for-byte, regardless of the host system's state.
Declarative Configuration: Describing Desired State
- Instead of writing scripts that list steps to achieve a state (e.g., wget ..., tar xvzf ..., cd ..., ./configure ..., make, make install), you write Nix expressions that declare the desired outcome (e.g., "I need git version 2.30, gcc version 11, and this web server configured to serve these files").
- The Nix evaluator reads this declarative description, figures out the dependency graph, and determines what needs to be built or fetched from a binary cache (a repository of pre-built store paths) to satisfy the declaration.
- Benefit: This shifts focus from how to achieve a state to what the state should be. Nix handles the complexity of dependency management and build ordering.
Atomic Operations and Rollbacks: Safe System Updates
- System configurations or development environments managed by Nix are often represented as symbolic links pointing to a specific configuration root within the /nix/store.
- Updating involves building the new configuration entirely in the store first. Once built, a top-level symlink (like /run/current-system on NixOS or the environment links used by nix develop) is atomically switched to point to the new configuration root.
- If the build of the new configuration fails, the active system or environment is unaffected. If the new configuration is faulty after switching, rolling back is trivial: simply point the symlink back to the previous valid configuration, which still exists in the store.
- Benefit: Updates are transactions. They either succeed completely or leave the system in its previous state. Rolling back is fast and safe because the old state is preserved.

These principles make Nix a powerful tool for managing software, but using them effectively across projects, especially in a team setting, traditionally required some boilerplate and lacked a fully standardized project-level interface. This is where Flakes come in.

The Motivation for Nix Flakes: Standardizing Project Interfaces

Before Flakes, managing project-specific Nix environments and dependencies often involved ad-hoc methods: pinning nixpkgs (the main Nix package repository) to a specific commit using Git submodules or environment variables, writing custom shell scripts, and defining entry points inconsistently. Sharing these setups reliably across a team or in CI could be cumbersome.

Nix Flakes were introduced to standardize this project interface, making Nix projects more discoverable, composable, and, critically, offering a more robust mechanism for dependency pinning and guaranteed reproducibility.

Nix Flakes: A Standard for Inputs and Outputs

Flakes introduce two core concepts, defined in a standard file at the root of a project: flake.nix.

flake.nix: The entry point for a Nix-managed project. It defines:
- Inputs: The external dependencies the project relies on (like specific versions of nixpkgs, other flakes, or source code repositories).
- Outputs: What the flake provides (e.g., packages, development environments, NixOS modules, etc.).

inputs Attribute: Explicitly declares dependencies, typically referenced by a URL-like format.

# flake.nix
{
  inputs = {
    # 'nixpkgs' is the name we give this input inside the flake
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; # Source: unstable branch on GitHub

    # Another flake as a dependency
    # my-library.url = "github:my-org/my-library";

    # A local path dependency
    # local-utils.url = "path:./utils";
  };
  ...
}

Benefit: Dependencies are explicitly listed and named within the project itself.

flake.lock: Guaranteed, Cryptographically Pinning Dependencies
- When you first evaluate a flake (or update inputs), Nix resolves the input URLs (github:..., path:..., etc.) to exact, immutable references.
- For Git repositories, this means resolving to a specific commit hash. For other types, it might be a content hash.
- These precise, resolved references are recorded in the flake.lock file.
- Crucially, subsequent evaluations of the flake will ignore the URLs and use the exact references pinned in flake.lock.
- Benefit: flake.lock provides guaranteed reproducibility. Anyone with your flake.nix and flake.lock files will get the exact same versions of all dependencies, down to the specific commit or content hash. This file must be committed to version control alongside flake.nix.

outputs Attribute: Defines what the flake provides in a standard structure.

# flake.nix (continued)
{
  inputs = { /* ... */ };

  outputs = { self, nixpkgs, ... }@inputs: # 'self' refers to this flake, 'nixpkgs' is the resolved input
    let
      # Define the system architecture we're targeting
      system = "x86_64-linux";
      # Import nixpkgs for the target system. This gives us access to the vast
      # collection of packages pinned by our nixpkgs input.
      pkgs = import nixpkgs { inherit system; };
    in
    {
      # Define development environments provided by this flake
      devShells.${system}.default = pkgs.mkShell {
        # List the build tools and libraries needed in the development environment
        packages = [
          pkgs.nodejs_20 # Need Node.js version 20
          pkgs.python310 # Need Python version 3.10
          pkgs.git # Need git (even if already on host, guarantees version)
        ];

        # Optional: a shell script to run upon entering the environment
        shellHook = ''
          echo "Welcome to the project dev environment!"
          # Example: set environment variables specific to this project
          export MY_PROJECT_CONFIG=/path/to/config
        '';
      };

      # Define packages provided by this flake (e.g., building your application)
      # packages.${system}.my-app = pkgs.callPackage ./src/package.nix {};

      # Define NixOS modules or configurations
      # nixosConfigurations.my-server = nixpkgs.lib.nixosSystem { ... };

      # Other standard outputs...
    };
}

Benefit: Provides a discoverable and consistent interface for interacting with a project's Nix definitions. Tools can easily find the default development shell, build the default package, etc.

The Developer Workflow with `nix develop`

Let's see how Flakes simplify the developer experience using the flake.nix example defining a development shell with Node.js 20 and Python 3.10.

A developer clones the project repository containing flake.nix and flake.lock.
They navigate to the project root in their terminal.
They run the command:
```
nix develop
```

This single command triggers a powerful process orchestrated by Nix and Flakes:

Read Flake: Nix finds and reads flake.nix and flake.lock in the current directory (or a parent directory).
Resolve Inputs: Using the exact references specified in flake.lock, Nix identifies the necessary dependencies (like the specific commit of nixpkgs).
Fetch/Build Dependencies: Nix checks if these dependencies (and their transitive closures) already exist in the local /nix/store. If not, it fetches them from configured binary caches or builds them from source (following the hermetic build principles).
Construct Environment: Based on the devShells.${system}.default definition in flake.nix, Nix creates a temporary, isolated environment. This involves:
- Identifying all required packages (nodejs_20, python310, git, and all their dependencies).
- Building a precise set of environment variables (like PATH, LD_LIBRARY_PATH) that point only to the required components within the /nix/store.
- Crucially, this environment is isolated from the rest of the host system's globally installed software.
Activate Shell: Nix launches a new shell (e.g., Bash, Zsh) with this precisely configured, isolated environment. The shellHook is executed.

Inside this new shell:

$ node -v
v20.x.y # Exactly the version specified!

$ python3 --version
Python 3.10.z # Exactly the version specified!

$ git --version
git version 2.x # The version from nixpkgs, not potentially the host's version

The developer now has a predictable, project-specific environment ready for development, guaranteed to be the same as their teammates' and the CI server's.

Exiting the shell (exit or Ctrl+D) tears down this temporary environment, returning the user to their original, unmodified host shell. The project's Nix setup has left no lasting trace on the global system state, other than adding components to the immutable /nix/store.

Conclusion: Engineering Predictability into the Software Lifecycle

Nix Flakes significantly elevate the capabilities of the Nix ecosystem. By combining Nix's core strengths – the immutable /nix/store, hermetic builds, declarative configuration, and atomic updates – with the standardization and precise pinning provided by flake.nix and flake.lock, teams can achieve unprecedented levels of environmental reproducibility and reliability.

This approach fundamentally addresses environment drift, streamlines developer onboarding, ensures build and test consistency in CI/CD pipelines, and ultimately de-risks the deployment process. While the "experimental" tag indicates ongoing refinement, Flakes are rapidly becoming the idiomatic way to leverage Nix for modern software development. Embracing this paradigm allows engineering teams to build, test, and deploy software with confidence, knowing that their environments are not just "similar," but cryptographically guaranteed to be the same, every time.