DEV Community: Yarden Porat

Stop Waiting: How to Batch-Generate AI Images with Nano Banana

Yarden Porat — Fri, 28 Nov 2025 08:58:19 +0000

Tired of waiting for the AI to finish one image before you can ask for the next?

Use this prompt structure to force a "production loop." It tells the AI to generate a specific list sequentially without stopping or merging them.

Copy and paste this:

Call the image generation function with the following frequency.
After each image generation, always check the number.
You may finish when the last number is matched. 
Here are the images you must create:
1. [prompt_1]
2. [prompt_2]
3. [prompt_3]
...

Figma to IDE MCP integration in 2 minutes

Yarden Porat — Sat, 08 Nov 2025 07:02:48 +0000

Stop Pasting Screenshots: A Developer's Guide to Semantic Figma Integration

As full-stack developers, we are constantly looking for ways to bridge the gap between design and implementation. Recently, AI has promised to close this gap, but the prevalent workflow—pasting screenshots into an LLM—is fundamentally flawed.

When an AI looks at a screenshot, it is guessing. It sees pixels, not intent. It doesn't know your design tokens, it doesn't recognize your existing component library, and it often outputs hard-coded hex values instead of the semantic variables your team uses.

There is a better way: The Model Context Protocol (MCP).

By integrating the figma-developer-mcp server into your IDE, you can give your AI agent direct, secure access to the structured data behind your Figma designs. This allows for "one-shot" code generation that actually respects your codebase's architecture.

Here is how to set it up in minutes.

Prerequisites

You will need an IDE that supports MCP (like Cursor) and access to your Figma account.

Step 1: Generate a Figma API Token

To allow your local environment to read Figma files securely, you need a personal access token.

Open Figma and navigate to Settings > Account.

Find the Personal Access Tokens section.

Generate a new token. For security, ensure it only has Read-Only scopes.

Important: Copy this token immediately and store it securely. You will not be able to see it again.

Step 2: Configure Your IDE

Next, we need to register the Figma MCP server with your IDE. This is typically done via a standard mcp.json configuration file.

In standard AI-native IDEs, you can usually find this by navigating to Settings > MCP Tools, which will open the configuration file.

Add the following entry to your mcpServers object:

{
  "mcpServers": {
    "figma-developer-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp",
        "--figma-api-key",
        "YOUR_TOKEN_HERE",
        "--stdio"
      ]
    }
  }
}

Replace YOUR_TOKEN_HERE with the actual token you generated in Step 1.

Once saved, completely restart your IDE to ensure the new server registry loads.

Step 3: The New Workflow

Once integrated, you no longer need to take screenshots.

In Figma: Right-click the frame or component you want to implement and select Copy link to selection.

In your IDE: Open your AI chat interface and paste the link directly.

Prompt: Instruct the AI on how you want it implemented (e.g., "Implement this using our existing React UI components and CSS modules").

Why This Matters

The difference between pixel-guessing and semantic understanding is significant for professional codebases:

Design Tokens: The AI can read your Figma variables, meaning it will use --color-surface-primary instead of #FFFFFF.

Component Recognition: It can identify that a design element is an instance of your standardized Button component, rather than re-inventing it with raw divs.

Reduced Technical Debt: By generating code that aligns with your existing patterns from day one, you spend less time refactoring "AI slop."

Integrating Figma via MCP transforms it from a visual reference into a queryable data source for your development environment.

How to Create a Custom LinkedIn Frame to Stand Out in 2025

Yarden Porat — Sun, 03 Aug 2025 05:19:03 +0000

Open your LinkedIn feed. You'll see a sea of professional headshots, all blending into a uniform blue and white landscape. But every so often, a profile picture catches your eye. It has a subtle ring of color, a word, or a simple design.

That small detail is a LinkedIn Frame, and it’s one of the most underutilized tools for personal branding on the platform.

While LinkedIn offers default frames like #OpenToWork or #Hiring, they are generic. Imagine, instead, a frame that uses your brand's colors, promotes your latest project, or announces your role as an event speaker.

This is more than just decoration; it's a strategic way to communicate your value before anyone even clicks on your profile. This guide shows you why it matters and how you can create your own in less than a minute.

The Strategic Advantage of a Custom LinkedIn Frame

In the digital world, attention is currency. You have mere seconds to make an impression on a recruiter, a potential client, or a future collaborator. Your profile picture is your digital handshake, and a custom frame makes that handshake firmer.

Here’s what a custom frame can do for you:

Instantly Grab Attention: A pop of color or a clean design makes your profile stand out in crowded feeds, search results, and comment sections.
Communicate Your Purpose: Instantly signal what you’re about. Are you "Speaking at #SaaStr," "Launching a Podcast," or "Open to Board Roles"? Your frame can say it all.
Reinforce Your Brand Identity: Using your brand colors creates a consistent and memorable visual identity across all your digital platforms.

A bland profile is a missed opportunity. A framed profile is a conversation starter.

How to Create Your Custom LinkedIn Frame in Under 60 Seconds

You don't need design skills or expensive software. The LinkedIn Frame Generator is a free, simple tool designed to do one thing perfectly.

There are no accounts to create, no watermarks, and no freemium tricks. It's built for speed and privacy.

Step 1: Visit Frame-Generator.com
The tool works directly in your browser.

Step 2: Upload Your Profile Picture
For the best results, use the high-resolution photo you already have on LinkedIn.

Step 3: Customize Your Frame

Add Text: Write a short, impactful message (e.g., your tagline or status).

Choose Your Color: Use a hex code to match your brand colors perfectly, or pick one you like.

Adjust and Position: Use the image offset controls to ensure your face remains perfectly centered.

Step 4: Download and Upload to LinkedIn
Download your new, framed photo and upload it directly to your LinkedIn profile. The entire process takes less than a minute.

Best Practices for a Professional Look

Less is More: A simple, clean ring of color is often more professional and impactful than a frame overloaded with text.
Stay On-Brand: Consistency is key. Use your established brand colors to build recognition.
Keep it Fresh: Update your frame for special campaigns, events, or job-seeking cycles. A dynamic profile signals that you are active and engaged.

Frequently Asked Questions (FAQ)

Q: Is the LinkedIn Frame Generator free to use?
A: Yes, it is 100% free. There are no hidden costs, subscriptions, or watermarks.

Q: Are my images stored on your server?
A: No. Your privacy is paramount. All image processing happens in your browser. Your pictures are never uploaded to or stored on our servers.

Q: Can I use this for other social media platforms?
A: Yes! While it's optimized for LinkedIn's circular format, the downloaded image works perfectly for other platforms like X (Twitter), Instagram, or as a Discord avatar.

Ready to Upgrade Your Digital First Impression?

Your LinkedIn profile is your most important digital career asset. Don't let it blend in.

A custom frame is a powerful signal. It shows you are intentional, brand-savvy, and care about how you present yourself professionally. It’s a simple change that makes a significant impact.

Take 60 seconds and create your free frame now: Visit Frame-Generator.com

We’ve been featured on GeekyTools.com, a platform for digital tools that enhance productivity.

About Me

My name is Yarden Porat. By day, I’m a Senior Software Engineer at Vimeo, and I'm the creator of the LinkedIn Frame Generator.

I built this tool with a simple mission: to make powerful, professional branding accessible to everyone. I believe you shouldn't need complex software to make your profile stand out. I'm thrilled the tool has been recognized for its simplicity and effectiveness.
I hope it helps you make your best first impression.

Arguing with LLMs

Yarden Porat — Mon, 14 Jul 2025 06:59:27 +0000

Ever been in a debate with a colleague from a different role, and suddenly they drop a ChatGPT response on you to counter your point? 🤨

If so, you're not alone. It seems there's a new weapon in the arsenal of technical arguments.

We all love AI tools. They're amazing and help us with a variety of daily tasks with an efficiency that sometimes feels like magic.

But turning them into the ultimate authority in a professional argument? That’s where I think we’re missing the point.

Why do I find this so problematic?

An LLM is not documentation 📚
It hasn't read your internal design docs, it doesn't understand the project's constraints, and it can invent an entire API that doesn't exist.

An LLM is a confirmation bias machine 🧠
With the right prompt, you can make it say anything. "Write five arguments why X is better than Y" – and it will. That doesn't make it right or smart. Basically, it just wants to please you.

An LLM is no substitute for a real discussion 🎯
The whole point of a professional discussion is to weigh the pros and cons, to understand the trade-offs. When you pull out a generic bot answer, you're essentially saying: "I can't be bothered to think, let's just take the first answer from Google on steroids." You're just shooting yourself in the foot and missing an opportunity to learn.

I'm not against these tools, quite the opposite. But there's a huge difference between 'fake it till you make it' and 'let the AI fake it for me.' Using them to "win" an argument, without scrutiny and real references, is an abuse of the tool and cheapens the professional discourse.

So, have you encountered this phenomenon?
How do you think we should handle an argument that's based on a generic AI response?

Codeium Windsurf IDE rules file

Yarden Porat — Thu, 03 Apr 2025 05:45:26 +0000

Due to lacking documentation:

Wave 8 and beyond

Now, Rules are defined in markdown (.md) files within the repository’s root folder of .windsurf/rules. After creating a Rules file with a descriptive name (just like with Workflows), the user will be greeted with a GUI wrapper around the Markdown file.

Your browser does not support the video tag.

for more information check the official blog post

Before Wave 8

At the root of your project, create a file .windsurfrules

Add appropriate rules for you project in the following format:

1. My build system is Bazel
2. My testing framework is pytest
3. Don't modify any files in ...
4. Don't use these APIs ...

For more rule files examples, check out the official docs: https://codeium.com/windsurf/directory

How to hide Next.js 14 server logs

Yarden Porat — Thu, 20 Feb 2025 09:31:26 +0000

Example for hiding logs such as:
GET /_next/static/chunks/app/route/react-toastify.esm.mjs.map 404 in 1623ms

// ./src/utils/customLogger.mjs

if (process.env.NODE_ENV === "development") {
  // Omit NextJS writing it's log https://github.com/vercel/next.js/discussions/65992
  const __write = process.stdout.write;
  process.stdout.write = (...args) => {
    if (typeof args[0] === "string" && args[0].startsWith(" GET /")) {
      if (args[0].includes("react-toastify.esm.mjs.map")) {
        return;
      }
    }
    __write.apply(process.stdout, args);
  };
}

export {};

// next.config.mjs
import "./src/utils/customLogger.mjs";

How to Disable Removal of Formatting When Pasting Text in Microsoft Word for Mac

Yarden Porat — Sun, 15 Sep 2024 06:09:44 +0000

Recently, Microsoft Word for Mac has started stripping away formatting when you paste text using Command (⌘) + V, leaving you with plain text. To restore the original formatting, follow these simple steps:

Open Microsoft Word on your Mac.
Access Preferences:
- Click on Word in the top menu bar next to the Apple logo.
- Select Preferences from the drop-down menu.
Modify Edit Settings:
- In the Word Preferences window, click on Edit.
- If you don't see an Edit option, choose Advanced instead.
Adjust Cut and Paste Options:
- Find the section labeled "Cut and paste options" or "Cut, copy, and paste".
- Uncheck the box next to "Show Paste Options button when content is pasted".
Close the Preferences Window:
- Your changes will be saved automatically.

After completing these steps, pasting text with Command + V will retain the original formatting.

Chrome extension that allows font-weight control

Yarden Porat — Sun, 04 Aug 2024 05:55:57 +0000

Recently, I assisted a relative in setting up a new computer. This relative has vision problems that make it difficult to read fine text with low contrast. While I knew that browsers allow you to control the base font size, I was searching for a way to control the font weight (font-weight) and couldn't find an easy solution. Even the Chrome Web Store didn’t have an extension that fit the bill.

The Solution

After some research and development, I created a Chrome extension called Bold it that allows users to control the font weight on any website. This extension can help not only my family member but also others who struggle with reading online due to vision issues.

{% embed https://youtu.be/PkWMMiUn29A %}

Extension Features

Description:

Easily adjust font-weight on any webpage.
User-friendly interface with simple controls.

Features:

Real-time font-weight adjustment.
Save preferred settings.
Enhance readability.
Compatible with all websites.

How to Use

Install from the Chrome Web Store.
Click the extension icon.
Adjust the font-weight slider.

I invite you to try the extension and share it with anyone who might benefit from it.

Bold it: https://chromewebstore.google.com/detail/bold-it/dccjfkknapjcbjalaknijpoocjilpjfa

Why Do I Love Code Formatters?

Yarden Porat — Tue, 11 Jun 2024 05:39:21 +0000

Is it because standardizing the code makes it more readable? Also, but no.
Is it because it saves unnecessary discussions about style in reviews? Also, but no.
Is it because it saves us the need to think about formatting at all? Also, but no.
I love Code Formatters because they provide instant validation—immediate feedback on whether the syntax is correct. In large projects, nothing gives you validation on the code in the file you are editing as quickly. Linting can take a few seconds. Unit tests running with watch take more time. A development server with HMR is usually slower.

Even if you are an expert in a certain domain, one day you might find yourself in a codebase you're unfamiliar with, in a language that isn't your forte, and you'll be grateful that a formatter was enforced in the project.

TypeScript's noUncheckedIndexedAccess

Yarden Porat — Sat, 17 Feb 2024 18:27:45 +0000

Recently, a friend shared a TypeScript project with me, and as I delved into it, I noticed something crucial missing: the basic configuration of noUncheckedIndexedAccess

⚙️ Why is this configurations important?

noUncheckedIndexedAccess feature ensures that accessing elements in arrays or objects doesn't result in undefined or null, reducing runtime errors. Without it, developers might overlook potential null or undefined values, leading to unexpected crashes or behaviors.

🔍 Examples Speak Louder Than Words:

Consider this snippet without noUncheckedIndexedAccess:

const arr: string[] = ["a", "b", "c"];
const element: string = arr[4]; // Potential runtime error if arr[4] is undefined

✅ Conclusion:

Integrating noUncheckedIndexedAccess into your TypeScript projects might seem like a minor tweak, but it can prevent major headaches down the line. By catching potential issues early and enforcing stricter typing, these features contribute to more robust and reliable codebases.

Let's prioritize these configurations in our TypeScript projects to ensure smoother development experiences and fewer surprises in production. Keep coding confidently! 💻✨

Introducing `useThrottledCallback`: Enhance Performance with Throttled Callbacks in React

Yarden Porat — Fri, 25 Aug 2023 10:39:42 +0000

In the world of web development, creating smooth and performant user experiences is paramount.

One common challenge developers face is dealing with event handlers that can fire rapidly, potentially causing unnecessary re-renders and performance bottlenecks.

This is where throttling comes into play. Throttling limits the rate at which a function is executed, ensuring that it's called at a controlled pace, thus optimizing performance.

That is why I created a new React hook that simplifies the implementation of throttled callbacks - useThrottledCallback.

This hook streamlines the process of creating throttled callbacks and also aligns perfectly with best practices in React development, including seamless integration with React linting tools.

`useThrottledCallback`

Let's take a closer look at how the useThrottledCallback hook works:

TypeScript

import { useMemo, type DependencyList } from 'react';
import throttle from 'lodash.throttle';

export const useThrottledCallback = <TCallback>(
    fn: TCallback,
    dependencies?: DependencyList,
    wait: number = 250
) => {
    // eslint-disable-next-line react-hooks/exhaustive-deps
    return useMemo(() => throttle(fn, wait), [wait, ...(dependencies ?? [])]);
};

JavaScript

import { useMemo } from 'react';
import throttle from 'lodash.throttle';

export const useThrottledCallback = (
    fn,
    dependencies,
    wait = 250
) => {
    // eslint-disable-next-line react-hooks/exhaustive-deps
    return useMemo(() => throttle(fn, wait), [wait, ...(dependencies ?? [])]);

The hook accepts three parameters:

fn: The callback function you want to throttle.
dependencies (optional): An array of dependencies that, when changed, trigger the creation of a new throttled callback. This aligns with React's dependency tracking system.
wait: The time interval in milliseconds that specifies how often the throttled function can be executed.

Enhancing Code Quality with Linting

Linting helps Maintaining clean and organized code is essential for collaboration and long-term project health.

useThrottledCallback dependency array can be validated by linting, specifically the by popular react-hooks/exhaustive-deps rule.

In your linting configuration file (usually .eslintrc), add the following configuration to the rules section:

   "rules": {
     "react-hooks/exhaustive-deps": [
       "warn",
       {
         "additionalHooks": "(useThrottledCallback)"
       }
     ],
     // ... other rules
   }

With this setup, linting tools will recognize your usage of the useThrottledCallback hook and ensure that you provide appropriate dependencies to the hook to avoid unnecessary re-renders.

Conclusion

The useThrottledCallback hook brings simplicity and performance optimization to your React applications. By incorporating throttled callbacks, you can effortlessly manage event handlers that could otherwise cause performance hiccups. With linting integration, maintaining code quality becomes a breeze, ensuring your projects stay organized and efficient.

Give the useThrottledCallback hook a try in your next React project, and experience the benefits of smooth user interactions and enhanced code maintainability. Happy coding!

Flaky Tests, and How to Deal with Them

Yarden Porat — Thu, 26 Jan 2023 15:45:35 +0000

Intro

Hey! My name is Yarden Porat, and in this article, I will explain what flaky tests are, their costs, their causes, and how they harm your work and organization. Once we have that figured out, I will share our strategy and tools we have developed in-house for dealing with test flakiness at Wix and how we avoid their costs.

What is a flaky test?

A flaky test is an automated test with a non-deterministic result. This is a way of saying that a test sometimes passes and sometimes doesn’t, inconsistently, without any code changes.

How often does it fail?

Beautifully depicted in this article, if a single test has a failure rate of 0.05% (0.0005), and you have 100 of these tests in your test suite, it would have a success rate of 95.12%= 0.9995¹⁰⁰.

But what happens when you have thousands of these tests? A 60.64% success rate (0.9995^1,000). It’s easy to calculate the significant impact of even a low failure rate on large scale tested applications.

But… What’s the problem? Just rerun the tests!

There are some really bad implications of ignoring flaky tests. Let's go over some of the most common ones, from least important to most.

1. Wasted CI minutes (Hours? Days? Weeks?)

Consider the following scenario:

You are a developer working in a team. There’s a new feature you’ve been developing for several days, and you opened a pull request wanting to merge it into the project.

Now, your company works in a modern development workflow and runs automated tests on your code changes using your CI system. All of the product’s tests ran and failed on a test entirely unrelated to the changes you introduced.

Since you are aware of the code changes you have made, and you know that this project has issues with non-deterministic tests, you therefore know the failing test is not your fault.

So, you rerun the test, and it passes.

If you don’t know your project has an issue with non-deterministic tests, you’ll probably waste even more time investigating.

The problem is that this time accumulates. The longer the test workflows take, the more time is wasted—but how much time? This can be measured, assuming you track your CI test results.

You can easily calculate the CI time wasted due to flakiness by summing up the CI time of a workflow run that had a non-deterministic result. For example:

#	commit	workflow_name	os	result	duration
1	9f3e679	test-part-1	linux	success	10
2	9f3e679	test-part-1	linux	fail	7

Run identifier: commit + workflow_name + os

That’s 7 minutes of CI time wasted!

2. Wasted development time

When a developer reruns a test, they are forced to wait (again) for the build and test time. Precious developer time is being lost.

Even if we assume that a developer utilizes this wait time for other tasks, we still have 2 major drawbacks:
Loss of immediate feedback (long feedback loop).
Context switching—which eats away at focus and productivity.

Unfortunately, this wasted time is much harder to measure.

3. Flaky product behavior (or flaky implementation)

Sometimes a flaky test is only a symptom of a non-deterministic implementation.

The same race condition that can cause test flakiness can do the same in a feature’s implementation, thus causing flaky product behavior in production.

4. Alert fatigue

A common phenomenon in flaky test workflow is the loss of trust in the feedback you are getting. Consider this scenario:

You push your new code
Workflow tests run and fail
“Oh it's that annoying flakiness again; we should fix it sometime”
Rerun workflow, tests run and fail
“D*%N FLAKINESS”
Rerun workflow, tests run and fail
Realizing that it was actually my code changes that had failed the tests
Go back to step 1

This harms development velocity and the developer’s experience. In an environment where it's not mandatory for tests to pass to merge a pull request, it is not uncommon for changes to merge even though they are breaking some product and tested behavior.

What's lost?

Money (Developer time, CI time)
Development velocity
Confidence in tests (regressing to manual testing)
Product quality
Developer experience

Causes of test flakiness

So now that we know the price and the pain, here are some of the causes of test flakiness.

1. Poorly written test code

For example, interacting with DOM elements that are not yet ready, or improper use of waitFor functions. This is the most common case where testing is done incorrectly. Sometimes, powerful development machines (a.k.a, your local computer) hide race conditions in a test, which ends up failing on CI machines.

2. Poorly written application code

As mentioned above, sometimes the application code itself introduces a flaky behavior. These cases are much harder to detect and debug. It could be related to communications, asynchronous code, or many other alternatives.

3. Infrastructural causes

There are various environmental causes to blame, and they are the immediate culprit for those who write flaky tests. Such causes may be:

Network issues: loss of connectivity, slow connection, etc.
Hardware issues: low-performance shared virtual machines, which stress existing race conditions
External dependencies: package manager (npm\yarn), runtime setup (i.e. Node, and other dependencies, which also suffer from some level of flakiness

4. Test tools that are prone to flakiness

In our experience tests which use a browser are more prone to flakiness. One reason is that the browser itself is a complex piece of software with many dependencies, and it can be affected by a variety of factors - its version, operating system, and other specific configurations of the machine it is running on.

Key takeaways up to this point

Here are some points I think you should keep in mind:

Flaky tests could occur due to many reasons and various causes. Some are test related, some production-code related, others from the infrastructure and development environment.
They have direct and indirect implications on the development process—both technical and psychological.
Flaky tests reduce development speed and quality if left untreated.

How to deal with flaky tests?

1. Collect data

It is much easier to communicate the costs of flakiness to your team or organization if you have data to back you up.

2. Analyze it

Workflow reruns per day bar graph

A bar graph that represents the overall flakiness and displays the total number of times a workflow has been restarted.
It helps us understand the scale of the flakiness problem and the lack of developer trust in the tests/CI.

At Codux we chose to count any case of workflow rerun, but you can also create a subset of this graph that shows reruns that never succeeded, which could better depict the lack of trust in your tests/CI.

This is a general index that tells if your data correlates with your general feel of flakiness. We don’t derive tasks from it.

We count rerun by identifying the commit, branch, OS, and workflow name. We call it an “entity” and count its total occurrences minus one.

Fail rate table

This is a table that calculates a test’s fail rate out of its total runs. We collect data from all branches, including development branches, and present only tests that have failed on 3 branches or more, with a minimum number of total runs.

This table helps us find the current culprits tests. A Flaky test that fails over an arbitrary percentage of your choice (we chose 5%), is skipped, documented, and assigned to the relevant developer. This process occurs 1-2 times a week.

This process requires reasoning and shouldn’t, in our opinion, be done automatically — for example:

Some features have a low number of tests, so you probably wouldn’t want to lose coverage, and you might prefer, or should, add a retry on those tests.
Some tests are more prone to failure (during development), such as end-to-end tests, so it might indicate they have a higher fail rate than they actually do.

Fail by test scatter plot (Environmental factors)

We’ve created a plot similar to Spotify’s Odeneye. This plot helps us realize if there are some environmental or infrastructural problems. If you suspect your infrastructure is causing flakiness, try creating this dashboard.

_
Horizontal lines indicate that a test is flaky. Vertical lines indicate an issue external to the test because it shows multiple test failures in the same timeframe. _

3. Run new tests multiple times

After noticing that newly created tests are flaky and require adjustments, we have decided to raise the bar for newly created tests and created “check-new-flaky” — a CLI tool that detects new tests and runs them multiple times.

It detects new tests by running our test runner (mocha) programmatically, recursively extracting test names on the branch, and comparing them to master.

Checking newly created tests reduced the new flaky tests added to the application and the need to refactor them significantly.

Some more benefits that we got:

Faster feedback loop: This test workflow runs your new tests immediately, thus letting you know if it passes without waiting for their turn within the entire test suite
Another OS is running your test: All our tests are running on Linux, while tests/features which are considered to be operating system sensitive, also run on Windows. Using the check-new-flaky CLI, we sometimes get an indication that a test we thought wasn’t OS sensitive is actually sensitive or broken for the other operating system.

4. Set a bar for when a test isn’t flaky

At first, it wasn't really clear to a developer when he fixed a flaky test. Developers would usually run a test 2-10 times before it would be labeled as not flaky and get merged to master.

Once we declared war on test flakiness, the bar would be set to 100 consecutive runs.

There are many ways to run a test multiple times — we used parts from the above CLI (check-new-flaky) and made it accessible via our GitHub bot.

Does your test only fail when running on CI?

CI machines usually have reduced performance compared to your local development machine, thus most race conditions only show once tests are running on the CI.

Helping tests fail on your local machine

One tool that we have found to be helpful is CPU throttling emulation.
We use Playwright for integration and end-to-end browser tests. It emulates slow CPUs using the Chrome Devtools Protocol (experimental feature).

  import type { ChromiumBrowserContext } from 'playwright-core';
   ...
   const client = await (page.context() as ChromiumBrowserContext).newCDPSession(page);
   await client.send('Emulation.setCPUThrottlingRate', { rate: 2 });

Rate is the slowdown factor (1 is no throttle, 2 is 2x slowdown)

Find out what’s going on with a test on the CI

Many testing tools today allow you to take some recordings of your tests.
Playwright released a tracing feature on version 1.12, which records the test flow and provides us with screenshots and DOM snapshots. Since we had a significant issue with flaky tests, we immediately integrated this feature into our testing utils, allowing developers to record runs.

We send CI tracing to a dedicated Slack channel for ease of use.

This feature is super helpful when you have no clue why the test is failing on CI. Tracing helped us catch some unimaginable bugs that we wouldn't have caught otherwise.

Stop using ElementHandles. Start using Playwright Locators

Following the release of Playwright Locators and ElementHandle being discouraged from use, we decided to migrate our test kits and test drivers to Locators to enjoy the benefits given to us by this new API: actionability check, more strictness (detailed below), and in our React application - reduced flakiness.

From our experience, we can say that simply replacing ElementHandles with Locators in a test can resolve flakiness by itself.

What's wrong with ElementHandles?

Each ElementHandle refers to an actual specific DOM node. React, when trying to reconcile changes, might replace these referred DOM nodes. This is happening due to changes or as a result of components being unmounted and remounted again, making the referenced ElementHandle irrelevant. Keeping references to specific DOM nodes is not really needed because we usually get those references with selectors — which are agnostic to specific DOM nodes.

How Locators help us to get the correct DOM node

Locators keep the selector itself rather than a reference to a specific DOM node.
Upon action (e.g .click()) the locator:
- Uses the selector to query the DOM node relevant for that try
- Verifies it is actionable (attached, clickable, etc.)
- Validates there is no single-multiple mismatch.
- Repeats the process until it succeeds.

The actionability validation is batched along with the action itself as an atomic action.
For example, an atomic action could be: check if the button is available, visible, clickable and only then click it — meaning less communication between node and the browser.

By doing the query and validation alongside the action, we prevent possible race conditions that could occur between waitFor -> client re-render -> action.

Some more benefits

Increased strictness: default locator will throw an exception if the selector matched more than one element.
More readable errors: depicts the exact issue of why an action cannot be done instead of a failing assertion or some generic timeout.

Final words

Battling flakiness isn’t a short-term thing.

It requires developers' awareness and care, writing tests more carefully, keeping in mind possible race conditions, and a conscience that tells them it isn’t okay to just rerun tests.

It requires assistive tooling for testing the test itself and monitoring it.

It requires priority, time, and guidelines — things you should receive from the technical management, thus requiring them to be aware of this issue.

A single developer cannot change the state of flakiness — a group effort is needed.

Flakiness is a manageable long-term battle. Empower yourself with the right tools to not only increase your development velocity, but also elevate your overall experience.