DEV Community

Vitali Haradkou
Vitali Haradkou

Posted on

Bun: Is it fast for test automation?

What is Bun?

From official site - Bun is a fast JavaScript all-in-one toolkit/bundler/runtime/package-manager/test runner.

Bun - it's similar to node.js and Deno - both of them are JavaScript runtimes.

Deno also can supports typescript out-of box and compilation step does not required.

Bun logo

Environment information

I use MacBook Pro 14-inch, 2023.

Name Description
Chip Apple M2 Pro
Memory 16 GB
OS 14.0 Beta (23A5337a)
npm 9.6.7
yarn 1.22.19
pnpm 8.7.0
node.js v18.17.1
bun 1

How to install Bun

From Official site:

curl -fsSL https://bun.sh/install | bash
Enter fullscreen mode Exit fullscreen mode

Test

Disclaimer: I cannot test bun on the current project, since we use unimplemented bun node: API. When bun will fully compatable with node.js - I will retest on the real project.

The test is simple. We will run both headless and headful modes

Video 1. Repesentation of headless mode.

Project structure will be looks like this:

- src
  - demo.test.ts - our scenario to test
- package.json 
- playwright.config.ts - playwright configuration
Enter fullscreen mode Exit fullscreen mode

Round 1. Headful mode

playwright Configuration will be looks like this:

// playwright.config.ts
import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  // Look for test files in the "tests" directory, relative to this configuration file.
  testDir: "tests",
  workers: 1,
  use: {
    // Base URL to use in actions like `await page.goto('/')`.
    baseURL: "https://google.com",
    launchOptions: {
      // headful mode
      headless: false,
    },
  },
  // Configure projects for major browsers.
  projects: [
    {
      name: "chromium",
      use: { ...devices["Desktop Chrome"] },
    },
  ],
});
Enter fullscreen mode Exit fullscreen mode

And Test file will be looks like:

// tests/some.test.ts
import { test, expect } from "@playwright/test";

test("should work", async ({ page }) => {
  // opens baseURL
  await page.goto("/");
});
Enter fullscreen mode Exit fullscreen mode

Let's see some results:

Launch # Bun pnpm yarn npm
1 2.6 2.87 2.77 2.75
2 2.5 2.72 2.71 2.66
3 2.45 2.77 2.68 2.64
4 2.51 3.05 2.77 2.67
Median
N/A 2.5 2.82 2.735 2.665
Difference
N/A 0 12% 9.4% 6.6%

Table 1. Bun vs. pnpm vs yarn vs npm. Headful mode. Time in seconds

Very impressive. Bun is about 12% faster than pnpm in execution time. Npm is a second after bun! 🤯

Round 2. Headless mode

Same test file, but let's update configuration in playwright.config.ts file

// playwright.config.ts

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  // Look for test files in the "tests" directory, relative to this configuration file.
  testDir: "tests",
  workers: 1,
  use: {
    // Base URL to use in actions like `await page.goto('/')`.
    baseURL: "https://google.com",
    launchOptions: {
      // headless mode
      headless: true,
    },
  },
  // Configure projects for major browsers.
  projects: [
    {
      name: "chromium",
      use: { ...devices["Desktop Chrome"] },
    },
  ],
});
Enter fullscreen mode Exit fullscreen mode
Launch # Bun pnpm yarn npm
1 1.97 2.16 2.07 2.17
2 1.97 2.24 2.32 2.1
3 1.97 2.20 2.06 2.17
4 2.02 2.22 2.19 2.14
Median
N/A 1.97 2.21 2.13 2.15
Difference
N/A 0 12% 8% 9%

Table 2. Bun vs. pnpm vs yarn vs npm. Headless mode. Time in seconds

Difference between executions for pnpm and bun is about 12%! pnpm is a slowest!

Conclusion

I was impressive! Bun is 11% faster than pnpm; 9% faster than yarn and 8% faster than npm

NOTE 1: I cannot test bun on the current project, since we use unimplemented bun node: API. When bun will fully compatable with node.js - I will retest on the real project.

Observation 1: NPM is a second after bun by execution time. It blows my mind! 🤯

Observation 2: PNPM is a slowest package manager by execution time. Nevertheless, I'm still like it by installation and lock-resolving time.

I thing that Bun is preferable than Deno! Why? Because deno starts own ecosystem without node.js compatibility and it's have own package system (as URL importing instead of local package name). URL import notation can confused developers and it always to be remember package URL.

Bunbye!

Used Links

P.S

Did you know that i have an own blog site where I share my observations? On my blog you can see exclusives post which I'm not publish on other resources like devto or medium. Check it out - https://blog-vitaliharadkou.vercel.app/blog/

Top comments (0)