DEV Community: Sawan Bhattacharya

Why frontend developers don't wanna write e2e tests

Sawan Bhattacharya — Tue, 13 Jan 2026 08:13:34 +0000

If you have clicked on this article by reading the title, that means you are one of those frontend devs who hate writing tests, no worries, I am also one of you.

Recently I came across a survey which showed that majority of the frontend teams don't write tests. That made me think, why is that, why is it that writing tests in frontend is mutually hated upon, and I came across these few points.

This is not just a rant, but I am also gonna talk about what kind of tests really matter and an easier option to write your tests fast.

1) Writing test is slow and involves too much boilerplate

Most developers see writing tests as a chore rather than a benefit, and honestly, can you blame them? When the test file ends up having more lines of code than the actual feature you just built, something feels wrong.

The biggest momentum killer is the boilerplate.

Before you even get to the “user flow” you actually care about, you have to do a bunch of administrative work:

You have to define the browser environment.
You have to mock the API calls.
You have to handle authentication states (the classic “log in before every test” struggle).

By the time you’ve finished setting the stage, you’ve forgotten what you were even trying to test in the first place. There’s no “quick way” to just record a flow and move on. Instead, you're stuck writing infrastructure code for a headless browser. It feels like you're building a “Shadow App” just to keep your real app in check—and that’s a massive time sink.

2) Developers don't understand what to test

If you’re working on the backend, testing is usually straightforward: you send an input, and you check if the database updated or the API returned the right JSON. It’s binary. It’s clean.

But in the frontend? It’s a mess.

When you finish a feature and sit down to write a test, a million questions pop up:

Do I test that the button is blue?
Do I test that the loading spinner appears for exactly 200ms?
Do I test the internal state of my React component, or just what the user sees?
What happens if the API fails? Do I need a test for every single error toast?

For most of us, this leads to Analysis Paralysis. Since we don't have a clear “blueprint” of what matters, we either try to test everything (which leads to a maintenance nightmare) or we test nothing because we’re too overwhelmed to start.

When you’ve just spent the last 6 hours wrestling with a complex UI feature, the last thing you want to do is spend another 3 hours playing a guessing game about which parts of the DOM are “important enough” to assert. It feels like throwing darts in the dark.

3) Frontend moves faster than backend

As we discussed before, frontend is not binary and straightforward like backend. Plus, the thing in the frontend moves a lot faster than it does in the backend. In the backend, an API contract rarely changes. But in the frontend, we’re constantly moving buttons, tweaking layouts, and renaming CSS classes to improve UX.

So, when you make a “tiny” UI change that takes 2 minutes, your test suite suddenly breaks. You end up spending more time updating selectors and fixing “broken” tests than actually shipping features. Eventually, maintenance becomes such a headache that it’s easier to just stop writing them entirely so you can keep up with the pace of development.

Why E2E tests matter

In frontend, E2E tests actually matter more than your unit tests. Think about it: you can have 100% test coverage on a button component, but that won't tell you if the API failed to load or if a transparent div is accidentally covering the entire screen.

At the end of the day, we only care about one thing: Is the user’s experience broken? E2E tests are the only ones that actually simulate a real person on a real device. They check if the “Happy Path” (like logging in or hitting 'Buy Now') actually works from start to finish. We hate writing them, but they’re the only reason we can click “Deploy” on a Friday afternoon and actually go home without worrying about a production meltdown.

The problem with modern E2E testing

You might be thinking, “But we have tools like Cypress and Playwright! Aren't they supposed to fix this?”

They definitely made things better, but they didn’t solve the fundamental problem. Even with the “modern” stuff, we’re still running into the same brick walls:

The Flakiness Factor: You run a test in CI, and it fails. You run it again without changing a single line of code, and it passes. T“flakiness”ess" destroys your trust. Is the code actually broken, or was the API just 50ms slower this time?
The “Shadow App” Maintenance: As we talked about, these tools are still tied to your code. If you rename a class or change a data-testid, you have to go hunting through your test files to fix them. You're basically maintaining two apps at the same time.
The Learning Curve: To use these “modern” tools properly, you have to learn about async/await patterns, complex locators, and how to handle headless browser contexts. It’s a lot to ask of a frontend dev who just wants to make sure their UI doesn't break.

In short, even the best frameworks today still feel like they were built for Automated Testers, not for Frontend Developers who need to move fast. They focus on how to test, but they don't help with the pain of keeping those tests alive.

Something to help you write E2E test faster

After years of fighting with brittle selectors and spending more time in Cypress docs than in my actual codebase, I decided to build something better.

I’m working on a tool called Symphony.

The goal of Symphony is simple: Make E2E testing feel like a natural part of the frontend workflow, not a second job. Instead of writing complex, imperative code to click buttons and wait for loaders, Symphony lets you define your user flows in a way that actually makes sense. It uses a YAML-based DSL—which basically means you describe your test steps in plain, human-readable English.

Here is why I think it’s a game-changer for devs like us:

Zero Boilerplate: No more setting up browser contexts or massive beforeEach blocks. You just define the flow and run it.
Built for Speed: It’s designed to be fast to write. If it takes you 2 minutes to build a feature, it shouldn't take you 20 minutes to test it.
Readable by Anyone: Because the tests are written in a simple YAML format, even a PM or a designer can look at the test file and understand exactly what is being covered.

Symphony is built for the "lazy" developer (the best kind of developer) who wants the safety of E2E tests without the nightmare of maintenance.

Understanding Conditional TypeScript Props: Building Adaptable Components

Sawan Bhattacharya — Sun, 23 Jul 2023 15:41:49 +0000

Have you ever come across situations where certain properties of a component should only appear under specific conditions or when particular data is provided? This can be a real challenge, but fear not! TypeScript offers a nifty feature called 'conditional types' that can help us deal with such scenarios effectively. In this blog, we'll explore how conditional TypeScript props allow us to control the availability of properties based on different conditions, making our components more adaptable and secure. Let's dive in and discover the magic of TypeScript's conditional types!

To achieve this, TypeScript provides two primary ways: types and interfaces. In this blog, we'll start by exploring conditional types using types, and later, we'll dive into interfaces to further enrich our understanding.

Conditional props using `types`

Let's say you are making a component called Shape where we can define the id, colour, type of shape, and their dimensions, and according to that it's going to render out the shape.

Here is the component

export function Shape(props: Prop) {
    const { id, typeShape, color } = props;

    if (typeShape === "circle") {
        const { radius } = props;
        return (
            <div
                key={id}
                style={{
                    width: `${radius}rem`,
                    height: `${radius}rem`,
                    borderRadius: `1000px`,
                    backgroundColor: `${color}`,
                    alignItems: `center`,
                    justifyContent: `center`,
                    display: `flex`,
                }}
            >
                Circle
            </div>
        );
    } else if (typeShape === "square") {
        const { sideLength } = props;
        return (
            <div
                key={id}
                style={{
                    width: `${sideLength}rem`,
                    height: `${sideLength}rem`,
                    backgroundColor: `${color}`,
                    alignItems: `center`,
                    justifyContent: `center`,
                    display: `flex`,
                }}
            >
                Square
            </div>
        );
    } else if (typeShape === "rectangle") {
        const { width, height } = props;
        return (
            <div
                key={id}
                style={{
                    width: `${width}rem`,
                    height: `${height}rem`,
                    backgroundColor: `${color}`,
                    alignItems: `center`,
                    justifyContent: `center`,
                    display: `flex`,
                }}
            >
                Rectangle
            </div>
        );
    }
}

So for this component, if we have to define a type, then this is how most of us will write it

type Prop = {
    id: number;
    color: string;
    typeShape: "circle" | "square" | "rectangle";
    radius?: number;
    sideLength?: number;
    width?: number;
    height?: number;
};

The current problem with this type definition is that if the typeShape is set to "circle", it allows the usage of properties like width or sideLength in addition to the expected radius, because we have defined this property optional. This flexibility can lead to potential errors, and it's not as clear which properties are valid for a particular shape.

To fix this, we are going to take leverage of union type in TypeScript. Union types allow us to combine multiple types into a single type, giving us the flexibility to represent a value that can be one of several types.

In our case, we are going to use union types to construct a more refined type definition for the Prop type. The common part of the type have properties id, and color. We then utilize the & (intersection) operator to combine this base type with different conditional types, each corresponding to a specific shape.

type Props = {
    id: number;
    color: string;
} & (
    | { typeShape: "circle"; radius: number }
    | { typeShape: "square"; sideLength: number }
    | { typeShape: "rectangle"; width: number; height: number }
);

Now you can see that the editor is throwing an error, which says Type '{ id: number; typeShape: "circle"; radius: number; color: string; width: number; sideLength: number; }' is not assignable to type 'IntrinsicAttributes & Props'. Property 'width' does not exist on type 'IntrinsicAttributes & { id: number; color: string; } & { typeShape: "circle"; radius: number; }'.

This is precisely what we aimed to achieve with the implementation of conditional types. By using conditional types, we have transformed our type system, making it more precise and reliable. TypeScript's static analysis capabilities enhance our development experience and promote the creation of robust and type-safe components.

The error message demonstrates that TypeScript recognizes the specific shape-related properties that should be allowed for each shape type. In this case, it correctly enforces that width and sideLength properties are not allowed for the "circle" shape, and the correct property for a "circle" shape is radius.

Conditional props using `interface`

Now let's explore how we can achieve the same result using interfaces. Interfaces are another essential feature of TypeScript that allows us to define custom types and object shapes. Similar to types, interfaces provide a way to create reusable type definitions for our components and data structures.

interface IShape {
    id: number;
    color: string;
}

interface ICircle extends IShape {
    typeShape: "circle";
    radius: number;
}

interface ISquare extends IShape {
    typeShape: "square";
    sideLength: number;
}

interface IRectangle extends IShape {
    typeShape: "rectangle";
    width: number;
    height: number;
}

Here, the extends keyword acts as an intersection (&), effectively creating a relationship where the properties of IShape will be shared across all other shape interfaces.

By using extends, we establish a connection between the base IShape interface and the shape-specific interfaces (ICircle, ISquare, and IRectangle). This relationship ensures that all shape interfaces inherit the properties defined in IShape (id and color).

Now to make it optional, we have to use union in the component prop

export function Shape(props: ICircle | ISquare | IRectangle) {
// body will be same
}

In conclusion, we have achieved conditional props with interfaces, just like we did with types.

Making Life Easy with Makefile: Streamlining Software Development for Beginners

Sawan Bhattacharya — Sun, 14 May 2023 16:29:07 +0000

Anyone who's spent time in software development knows the tedium of writing and executing repeated commands for testing and building applications. It's a time-consuming process that can feel like running on a hamster wheel. But what if there was a way to streamline this process, automate these repeated tasks, and ultimately make your life as a developer easier? Enter the world of Makefiles.

What is Makefile? And How Is It Useful?

A Makefile is a text file that contains a list of commands to be executed, along with rules that specify when those commands should be executed. Makefiles are used to automate the process of building software projects. We need to use the command make <target_name> to execute our makefile.

Consider a common scenario in software development: before committing any changes, you want to ensure that all tests pass and that no build failures exist. In such a case, a Makefile can become an invaluable tool. This file should contain all the necessary commands related to testing and building your project.

To automate this process, you simply need to invoke your targets using the make <target_name> command within your git hooks. This action triggers the commands specified in the Makefile, executing your tests and checking for build errors.

The beauty of this approach lies in its automation. Instead of manually running tests and checking for build failures every time you commit changes, the process becomes a part of your git workflow, which means it’s going to run your tests and builds every time before committing the changes. This not only makes the development process more efficient, but also ensures consistent quality checks before any changes are committed to your codebase.

Write your first Makefile

Let's start by writing the classic 'Hello, World!' program. Begin by creating a new file named Makefile. Inside this file, insert the following code:



hello:
    echo "hello world 👋"

Now, open your terminal and execute the make command. You'll be greeted with the familiar output, as shown in the screenshot below:

Congratulation 🎉 you just created your first make file. Now, let's break down what we just did and understand how the syntax of makefile works.

Understanding Makefile Syntax

In makefile, we have the following syntax structure



target: prerequisites
    recipe

Let’s see what each of these parts does

target can be thought of as a task or a goal that you want to accomplish, Typically, a target is the name of a file that is generated by a program, like an executable or object file. However, a target can also be the name of an action to carry out, such as clean. Like in the previous example, hello was a target.
prerequisites this basically says what file if needed to be run before running the target
recipe this is the command you want to run One thing that you must have noticed that whenever you run the target it outputs the recipe before running it this gets a bit annoying so to stop this from happening you need to add @ before the command ```makefile

hello:
@echo "hello world 👋"


 > Important: If you simply run make without specifying a target, it defaults to executing the first target listed in the Makefile.

## Let's See This in Action
The best way to solidify our understanding is through practical examples. So, let's apply our knowledge by creating a small Go program. Firstly, make a file and name it `main.go` and add this code inside it
```go


package main

import "fmt"

func add(x, y int) int {
   return x + y
}

func main() {
   fmt.Println(add(1, 2))
}

Next, let's write a test to verify if this code functions correctly. Create a new file named main_test.go and add the following code:



package main

import (
   "testing"
)

func TestAdd(t *testing.T) {

   originalOutput := add(1, 2)

   if originalOutput == 3 {
       t.Log("1 + 2 = 3")
   } else {
       t.Fatalf("Expected 3, got %d instead", originalOutput)
   }


}

Now, let's automate the building and testing process using a Makefile. Create a new file named Makefile and add the following contents:



FILENAME=main.go


all: run build test


run:build
    @./bin/main


build:
    @go build -o bin/ $(FILENAME)


test:
    @go test -v ./...


clean:
    @rm -rf bin/


.PHONY: all run build test clean

Let's break down how the Makefile works, line by line. The FILENAME variable is used to store the name of our Go file.

all: The default target. It depends on the targets run, build, and test, which will be executed in sequence.
run: The target responsible for running our program. It depends on the build target and executes the ./bin/main command to run the compiled executable.
build: This target compiles our Go code into an executable. The -o bin/ option specifies the output directory for the binary file.
test: The target to run our tests. It executes go test -v ./... to run all tests in the current directory and its subdirectories.
clean: The target to clean up the generated files. It removes the bin/ directory.
.PHONY: This special target declares other targets as phony, meaning they are not actual files but rather commands or actions. Now you're ready to run make in your terminal, and it will automate the build, test, and run processes for your Go program.

TIPS: If you wanna change your default target then you have to use .DEFAULT_GOAL := <target_name>
Example, if you add .DEFAULT_GOAL := build to the makefile we just created and run then command make then it’s gonna run build and not the all target

Some Advance Stuffs

If you're ready to dive deeper into the world of Makefiles, this section is for you. Here, we'll explore some more advanced techniques and concepts to help you tackle complex scenarios.

Change Default Shell

To change the default shell used in a Makefile, you can specify the desired shell by setting the SHELL variable. For instance, if you want to use Bash as the default shell, you can define it as follows:



SHELL=/bin/bash

myshell:
    echo $0

In this example, we set the SHELL variable to /bin/bash. Now, when you run themyshell target, it will execute the echo $0 command using Bash as the default shell.

By adjusting theSHELL variable, you can customize the shell environment to suit your preferences or meet specific requirements for your Makefile.

Conditional Statement

Conditional statements in Makefiles provide a powerful mechanism for executing different commands based on specific conditions. They enable you to tailor the build process according to the environment, variables, or user-defined values. Let's explore an example of how to write conditional statements in a Makefile:



foo = ok

all:
ifeq ($(foo), ok)
    echo "foo equals ok"
else
    echo "nope"
endif

In this example, we have a variable foo with the value ok. The ifeq statement checks if the value of $(foo) is equal to ok. If the condition is true, the command echo "foo equals ok" is executed. Otherwise, the command echo "nope" is executed.

When you run make all in the terminal, it will evaluate the conditional statement and execute the appropriate command based on the value of foo. In this case, it will print foo equals ok.

Functions in Makefile

Functions in Makefiles play a crucial role in writing modular and reusable code. They allow you to encapsulate commands and parameters into named functions, promoting code organization and reducing duplication. Here's how functions are structured in Makefiles:



define <function_name>
    # Function body ...
    echo "$(1) $(2) $(3) ..." # Parameters passed
endef

funcCall:
    $(call <function_name>, <param1>, <param2>, ...)

Here, we define a user-defined function with the name using the define directive. The function body consists of the desired commands or operations. Within the function body, you can reference parameters passed to the function using $(1), $(2), $(3), and so on.

To invoke the user-defined function, you use the call directive followed by the function name and its respective parameters.

Let's see an example that demonstrates the usage of user-defined functions and their invocation:



define foo
    echo "launch 🚀"
endef

define uff
    echo “hey $(1) 👋”
endef

 fooCall:
    @$(call foo)
uffCall:
    @$(call uff, “John Doe”)

In this example, we define two user-defined functions: foo and uff. The uff function takes a parameter, which we pass as "John Doe". To call these functions, we use the call directive followed by the function name. Running this code will produce the following output:

You can also import functions from other makefile using include directive, the syntax is include <fille1> <fille2> <fille3> …

Conclusion

We have learned the power of Makefiles in automating testing and building processes in software development. By utilizing Makefiles, developers can streamline their workflows, save time, and ensure consistent quality checks.

If you want to explore further and dive deeper into the world of Makefiles, I recommend referring to the official GNU Make manual available at https://www.gnu.org/software/make/manual/make.pdf. This comprehensive resource provides in-depth information on Makefile syntax, advanced techniques, and best practices.

Feel free to connect with me on social media LinkedIn to stay updated on the latest software development tips, tricks, and insights.

Happy coding 👨‍💻