General

Mocking API on Storybook using MSW

Published Nov 2, 2022

Updated Feb 13, 2023

5 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

In this blog, you will learn how to mock APIs on Storybook using MSW. This blog will assume you have your project setup with either GraphQL, or a REST API like Axios or Fetch API and also will assume you have Storybook installed in your project. We will be covering how to mock for both GraphQL and REST API.

In this project, we will use Vue and our UI tool. But don't worry. The sample code will work for whichever framework you choose.

What is MSW?

MSW(Mock Service Worker) is an API mocking library that uses Service Worker API to intercept actual requests.

Why Mock?

Mocking helps us avoid making an actual HTTP request by using a mock server and a service worker. This, in turn, prevents any form of break in case something goes wrong with the server you would have sent a request to.

What is a Mock Server?

A mock server is simply a fake server that works as a real server to help users test and check APIs . It imitates a real API server by returning the mock API responses to the API requests. You can ream more here.

What is a Service Worker?

A Service worker enable communication between the application, the browser, and the networks (if netwrok is available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests, and take appropriate action based on whether the network is available or not.

You can learn more about Service Worker API here.

Use Cases

Enough of all the stories 😃. Now we will be looking at two use cases:

GraphQL
REST API

We will need to install some pulig ins to maximize what msw has to offer by running one of these commands in the root directory of the project:

Installing MSW and the addon


# With npm
npm i msw msw-storybook-addon -D

# With yarn
yarn add msw msw-storybook-addon -D

Generate a service worker for MSW in your public folder.

npx msw init <PUBLIC_DIR>

Replace the <PUBLIC_DIR> placeholder with the relative path to your server's public directory. For example, the Vue command will be:

npx msw init public/

You can check here to see what path your framework will use.

Note: If you already use MSW in your project, you have likely done this before, so you can skip this step.

Configuring Storybook

In your .storybook/preview.js file, add this:

import {
  initialize,
  mswDecorator
} from 'msw-storybook-addon';

// Initialize MSW
initialize();

// Provide the MSW addon decorator globally
export const decorators = [mswDecorator];

You also want to ensure that your GraphQL set up is initialized in this .storybook/preview.js file if you are using Apollo Client.

Creating our mock API

Lets create where our mocking will be happening by first creating mock folder in the src folder.

Create a data.ts file in the mock folder, and add this code, which will serve as our fake response.

export const userDetails = {
  user: {
    name: "Jerry Hogan",
    login: "hdJerry",
    bio: "I am a Front-End Developer with about 3 years plus of experience and with a very good knowledge of JavaScript, Vue, React, Tailwind, Styled component",
    company: null,
    avatarUrl:
      "https://avatars.githubusercontent.com/u/28502531?u=c0598241c0ca3dba90aff9d21790cb330952fd94&v=4",
    followers: {
      totalCount: 19,
    },
  },
};

export const posts = [
  {
    userId: 1,
    id: 1,
    title:
      "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    body: "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto",
  },
  {
    userId: 1,
    id: 2,
    title: "qui est esse",
    body: "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla",
  },
  {
    userId: 1,
    id: 3,
    title: "ea molestias quasi exercitationem repellat qui ipsa sit aut",
    body: "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut",
  },
  {
    userId: 1,
    id: 4,
    title: "eum et est occaecati",
    body: "ullam et saepe reiciendis voluptatem adipisci\nsit amet autem assumenda provident rerum culpa\nquis hic commodi nesciunt rem tenetur doloremque ipsam iure\nquis sunt voluptatem rerum illo velit",
  },
];

Create a mockedPost.ts file and add this code.

import { rest } from "msw";
import { posts } from "./data";

export const mockedPostFetch = rest.get(
  "https://jsonplaceholder.typicode.com/posts",
  (_, response, context) => {
    return response(context.json(posts));
  }
);

Create a mockedUserProfile.ts file and add this code.


import { graphql } from "msw";
import { userDetails } from "./data";

export const mockedUserProfileQuery = graphql.query(
  "UserProfile",
  (_, res, ctx) => {
    return res(ctx.data(userDetails));
  }
);

The concept of interception comes into place with these mocked files. For example, if there is any request outside of the mocked request, msw won't mock it. So every API url or query we want to mock must correspond to the component that's data you are trying to mock, regardless of if the API url is authentic or not.

Create a handlers.ts file and add this code. Handlers allow us to have multiple request, no matter its method [POST, GET]...

import { mockedPostFetch } from "./mockedPosts";
import { mockedUserProfileQuery } from "./mockedUserProfile";

export const graphQlHandlers = [mockedUserProfileQuery];
export const apiHandlers = [mockedPostFetch];

How do we make use of the Handler?

I created two components to test for our two use cases

Card
Posts

Card component

Create a Card folder in your component folder.
Create a Card.vue and add this snippet

<template>
  <div v-if="!loading" class="card">
    <div class="dp">
      <img :src="data.avatarUrl" alt="dp" />
    </div>
    <div class="user">{{ data.name }} 😎</div>
    <div class="bio">{{ data.bio }}</div>
    <div>Followers: {{ data.followers.totalCount }}</div>
  </div>
  <div v-else class="card loading">Loading...</div>
</template>

<script lang="ts">
import { USER_QUERY } from "@/graphql/user.query";
import { useQuery } from "@vue/apollo-composable";
import { defineComponent, computed } from "vue";
export default defineComponent({
  name: "UserCard",
});
</script>

<script lang="ts" setup>
const { result, loading } = useQuery(USER_QUERY, {
  username: "hdjerry",
});
const data = computed(() => result.value?.user ?? []);
</script>

<style scoped>
.card {
  width: 20rem;
  padding: 1rem;
  box-shadow: 0 0 20px 2px #ccc;
  border-radius: 6px;
  color: #333;
  min-height: 30rem;
}

.loading {
  display: flex;
  justify-content: center;
  align-items: center;
  font-weight: 500;
}
.dp {
  width: 20rem;
  height: 20rem;
  border-radius: 100%;
  overflow: hidden;
  margin: 0 0 1rem;
}

.dp > img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.user {
  font-size: 1.2rem;
  font-weight: medium;
  color: #2c3e50;
}
.bio {
  border-left: 4px solid rgb(154, 28, 179);
  padding: 0.2rem 0.5rem 0.2rem 1rem;
  margin: 1rem 0;
  background-color: #eee;
}
</style>

create an index.ts and add this code

import Card from "./Card.vue";
export default Card;

create Card.stories.ts and add this code

import { graphQlHandlers } from "@/mock/handles";
import Card from "./Card.vue";

export default {
  title: "Components/Card",
  component: Card,
  argTypes: {},
};

type Templates = {
  bind: (arg: unknown) => {
    parameters: unknown;
  };
};

const Template: Templates = () => ({
  components: { Card },
  template: "<Card />",
});

export const Default = Template.bind({});

Default.parameters = {
  msw: {
    handlers: graphQlHandlers,
  },
};

below is the UI expectation Card component

Posts component

Create a Posts folder in your component folder.
Create a Posts.vue and add this snippet

<template>
  <div v-if="!loading" class="posts">
    <div v-for="{ id, title, body } in data" :key="id" class="card">
      <h4 class="title">{{ title }}</h4>
      <div class="body">{{ body }}</div>
    </div>
  </div>
  <div v-else class="card loading">Loading...</div>
</template>

<script lang="ts">
import { defineComponent, ref } from "vue";
export default defineComponent({
  name: "UserPosts",
});
</script>

<script lang="ts" setup>
const loading = ref(true);
const data = ref(null);

fetch("https://jsonplaceholder.typicode.com/posts")
  .then((data) => data.json())
  .then((res) => {
    data.value = res.slice(0, 4);
    loading.value = false;
  });
</script>

<style>
.posts {
  width: 100%;
  padding: 0.5rem;
}
.card {
  flex: 1;
  min-height: 5rem;
  padding: 1rem;
  display: flex;
  flex-direction: column;
  align-items: flex-start;
  text-align: justify;
}
.loading {
  display: flex;
  justify-content: center;
  align-items: center;
  font-weight: 500;
}
.card > .body {
  font-size: 1rem;
  font-weight: 200;
  line-height: 1.2;
  color: rgb(117, 114, 114);
  word-wrap: break-word;
}
.card > .title {
  text-transform: capitalize;
  color: #2c3e50;
}
.card:not(:last-child) {
  border-bottom: 1px solid #ccc;
}
</style>

create an index.ts and add this code

import Posts from "./Posts.vue";
export default Posts;

create Posts.stories.ts and add this code

import Posts from "./Posts.vue";
import { apiHandlers } from "@/mock/handles";

export default {
  title: "Components/Posts",
  component: Posts,
  argTypes: {},
};

type Templates = {
  bind: (arg: unknown) => {
    parameters: unknown;
  };
};
const Template: Templates = () => ({
  components: { Posts },
  template: "<Posts />",
});

export const Default = Template.bind({});
Default.parameters = {
  msw: {
    handlers: apiHandlers,
  },
};

below is the UI expectation Posts component

Code Explanation

We created a card and posts component that is making use of certain query/API call to get data.

msw has a property handlers which accepts an array of requests, giving us the ability to add as many requests as we want provided that they are in the component.

Overview Of the UI

Below is an overview of the UI, which brings together the components:

Whewww!!! 😌

Why mock?

You want test without hitting the actual API
Yhe API isn't yet avaible from the backend team.
During development to reduce dependencies between teams.
To accelerate third parties API integration.
during functional and integration testing.
to test various advanced scenarios more easily.
for demonstration purposes.

Conclusion

If you have any issues, we provided a repo which you can use as a template if you want to start a new project with the setup and use it to practice.

Please let me know if you have any issues or questions, and also contributions are welcome.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Jerry Hogan
Passionate developer, super fan of Vue, a singer, writer and musician.
@iamjerry_hogan @hdjerry

Quick Guide to Playwright Fixtures: Enhancing Your Tests

Introduction Following our recent blog post on migrating E2E tests from Cypress to Playwright, we've identified opportunities to enhance our test scripts further. In this guide, we'll delve into the basics of Playwright fixtures, demonstrating their utility and flexibility in test environments. Playwright fixtures are reusable components that set up and tear down the environment or conditions necessary for tests. They are crucial for writing clean, maintainable, and scalable tests. Fixtures can handle tasks like opening a browser, initializing a database, or logging into an application—actions you might need before running your tests. As a practical example, we'll revisit one of the tests from our previous post, enhancing it with a new fixture to streamline the testing process and significantly improve maintainability. This post is designed to provide the foundational skills to integrate fixtures into your testing workflows effectively, giving you the confidence to manage and maintain your test scripts more efficiently. Creating Our First Fixture To illustrate the power of fixtures in Playwright, let’s consider a practical example from a test scenario in our project. Below is a snippet of a test case from our newsletter page: ` This test scenario navigates to the newsletter page, fills in an email, submits the form, and checks for a success message. To optimize our test suite, we'll refactor common actions like navigation, form completion, and submission into reusable fixtures. This approach makes our tests cleaner and more maintainable and reduces redundancy across similar test scenarios. Implementing the Fixture Here’s how the fixture looks: ` This fixture encapsulates the actions of navigating to the page, filling out the email field, and submitting the form. By abstracting these actions, we simplify and focus our test cases. Refactoring the Test With the fixture in place, let’s see how it changes our original test file: ` A beforeEach method to reset the state of the NewsletterPage fixture ensures a clean and consistent environment for each test scenario. This practice is crucial for maintaining the integrity and reliability of your tests. By leveraging the NewsletterPage fixture, each test within the "Newsletter page" suite starts with a clean and pre-configured environment. This setup improves test clarity and efficiency and aligns with best practices for scalable test architecture. Conclusion As we've seen, fixtures are powerful tools that help standardize test environments, reduce code redundancy, and ensure that each test operates in a clean state. By abstracting common setup and teardown tasks into fixtures, we can focus our testing efforts on what matters most, verifying the behavior and reliability of the software we're developing. Remember, the key to successful test management is choosing the right tools and using them wisely to create scalable, maintainable, and robust testing frameworks. Playwright fixtures offer a pathway towards achieving these goals, empowering teams to build better software faster and more confidently....

Jul 26, 2024

2 mins

Testing

How to test React custom hooks and components with Vitest

Introduction In this guide, we'll navigate through the process of testing React hooks and components using Vitest—a powerful JavaScript unit testing framework. Discover how Vitest simplifies testing setups, providing an optimal solution for both Vite-powered projects and beyond. Vitest is a javascript unit testing framework that aims to position itself as the Test Runner of choice for Vite projects and as a solid alternative even for projects not using Vite. Vitest was built primarily for Vite-powered projects, to help reduce the complexity of setting up testing with other testing frameworks like Jest. Vitest uses the same configuration of your App (through vite.config.js), sharing a common transformation pipeline during dev, build, and test time. Prerequisites This article assumes a solid understanding of React and frontend unit testing. Familiarity with tools like React Testing Library and JSDOM will enhance your grasp of the testing process with Vitest. Installation and configuration Let’s see how we can use Vitest for testing React custom hooks and components. But first, we will need to create a new project with Vite! If you already have an existing project, you can skip this step. ` Follow the prompts to create a new React project successfully. For testing, we need the following dependencies installed: Vitest as the unit testing framework JSDOM as the DOM environment for running our tests React Testing Library as the React testing utilities. To do so, we run the following command: ` Once we have those packages installed, we need to configure the vite.config.js file to run tests. By default, some of the extra configs we need to set up Vitest are not available in the Vite config types, so we will need the vite.config.ts file to reference Vitest types by adding /// reference types=”vitest” /> at the top of the file. Add the following code to the vite.config.ts ` We set globals to true because, by default, Vitest does not provide global APIs for explicitness. So with this set to true, we can use keywords like describe, test and it without needing to import them. To get TypeScript working with the global APIs, add vitest/globals to the types field in your tsconfig.json. ` The environment property tells Vitest which environment to run the test. We are using jsdom as the environment. The root property tells Vitest the root folder from where it should start looking for test files. We should add a script for running the test in package.json ` With all that configured, we can now start writing unit tests for customs hooks and React components. Writing test for custom hooks Let’s write a test for a simple useCounter hook that takes an initial value and returns the value, an increment function and a decrement function. ` We can write a test to check the default return values of the hook for value as below: ` To test if the hook works when we increment the value, we can use the act() method from @testing-library/react to simulate the increment function, as shown in the below test case: ` Kindly Note that you can't destructure the reactive properties of the result.current instance, or they will lose their reactivity. Testing hooks with asynchronous logic Now let’s test a more complex logic that contains asynchronous logic. Let’s write a useProducts hook that fetches data from an external api and return that value ` Now, let’s see what the test looks like: ` In the above example, we had to spy on the global fetch API, so that we can mock its return value. We wrapped that inside a beforeAll so that this runs before any test in this file. Then we added an afterAll method and called the mockRestore() to run after all test cases have been completed and return all mock implementations to their original function. We can also use the mockClear() method to clear all the mock's information, such as the number of calls and the mock's results. This method is handy when mocking the same function with different return values for different tests. We usually use mockClear() in beforeEach() or afterEach() methods to ensure our test is isolated completely. Then in our test case, we used a waitFor(), to wait for the return value to be resolved. Writing test for components Like Jest, Vitest provides assertion methods (matchers) to use with the expect methods for asserting values, but to test DOM elements easily, we will need to make use of custom matchers such as toBeInTheDocument() or toHaveTextContent(). Luckily the Vitest API is mostly compatible with the Jest API, making it possible to reuse many tools originally built for Jest. For such methods, we can install the @testing-library/jest-dom package and extend the expect method from Vitest to include the assertion methods in matchers from this package. ` After installing the jest-dom testing library package, create a file named vitest-setup.ts on the root of the project and import the following into the project to extend js-dom custom matchers: ` Since we are using typescript, we also need to include our setup file in our tsconfig.json: ` In vite.config.ts, we need to add the vitest-setup.ts file to the test.setupFiles field: ` Now let’s test the Products.tsx component: ` We start by spying and mocking the useProducts hook with vi.spyOn() method from Vitest: ` Now, we render the Products component using the render method from @testing-library/react and assert that the component renders the list of products as expected and also the product has the title as follows: ` In the above code, we use the render method from @testing-library/react to render the component and this returns some useful methods we can use to extract information from the component like getByTestId and getByText. The getByTestId method will retrieve the element whose data-testid attribute value equals product-list, and we can then assert its children to equal the length of our mocked items array. Using data-testid attribute values is a good practice for identifying a DOM element for testing purposes and avoiding affecting the component's implementation in production and tests. We also used the getByText method to find a text in the rendered component. We were able to call the toBeInTheDocument() because we extended the matchers to work with Vitest earlier. Here is what the full test looks like: ` Conclusion In this article, we delved into the world of testing React hooks and components using Vitest, a versatile JavaScript unit testing framework. We walked through the installation and configuration process, ensuring compatibility with React, JSDOM, and React Testing Library. The comprehensive guide covered writing tests for custom hooks, including handling asynchronous logic, and testing React components, leveraging custom matchers for DOM assertions. By adopting Vitest, developers can streamline the testing process for their React applications, whether powered by Vite or not. The framework's seamless integration with Vite projects simplifies the setup, reducing the complexities associated with other testing tools like Jest....

Mar 15, 2024

5 mins

ViteReactTesting

How To Authenticate Your SolidJS Routes With Solid Router

In this post, we will talk about how we can authenticate our SolidJS route with Solid Router. By the end of this article, we will understand what authentication is, and how it is used to guard routes in SolidJS using the Solid Router. Overview Route authentication has been around for a while, and is now a fundamental part of many applications like Facebook, Gmail, and Instagram. At this point, it’s about as ubiquitous as entering a password into a phone. Authentication through route guards in SolidJS can be achieved in two different ways. The first that we are going to cover in this app is the use of a Solid Router. The second is provided by Solid Start, which is more like a folder-based routing. It is a meta-framework (a framework built on another framework). At its core, it's powered by SolidJS and Solid Router. This article assumes that you have already set up a SolidJS project, and will not walk through that part of the process. If you have not yet spun up a project, you can find tutorials and instructions at SolidJS. What is Authentication? Authentication is a process of verifying the identity of the user. It provides access control to check if the user is authenticated. Authentication enables organizations to keep their networks secure by permitting only authenticated users or processes to gain access to their protected resources which, in our case, is the route in the application. To learn more about authentication, you can check out the following; - Authentication By Mary E. Shacklett - Authentication By Auth0 - Authentication By Wiki What is a route guard? A route guard helps to prevent unauthenticated users from accessing certain routes/parts in an application. For example, an app lock on a mobile phone can be seen as a guard. You may be able to access the phone and some apps, but you can’t access other apps. We can also use parental controls on the phone, internet, and so on as a type of guard. You can read more about route guard. Get Started If you haven't installed the Solid Router in your project, run the command below: ` Solid Router is a universal router for SolidJS which works whether you're rendering on the client or the server. It was inspired by and combines the paradigms of React Router and the Ember Router. To read more, check out Solid Router Having installed @SolidJS/router, we will be creating the following files; - Home: *src/pages/Home.jsx* - Signin: *src/pages/Signin.jsx* - Pricing: *src/pages/Pricing.jsx* - RouteGuard: *src/RouteGuard/index.jsx* - Header: *src/components/Header/index.jsx* - Header styles: *src/components/Header/Header.module.css* Terminologies - useNavigate: a library provided to us by SolidJS Router that is used to navigate. - createEffect: creates a listener, which calls it's first argument when attached signals change. - Outlet: serves as the children associated with RouteGuard wrapper - NavLink: used to navigate between pages just like a tag which takes a property href for the page route path. Home page Below is the code we will paste in our home page file. But if you already have a content for this, you don't have to change it. ` This is just a simple page component with a style imported at the top. Signin page This is the content of our sign in page, but if have a content already, that's fine. The most important contents are the logIn function and the createEffect. ` The logIn function will be called when the login button is clicked. When clicked, a hardcoded token is saved in the session storage. The user is then navigated to the home page, which by default, can only be accessed if the user has been authenticated. The createEffect ensures the authenticated user won't access the sign in page. Pricing page This is just another page which, in this project, represents another protected page that could only be accessed by an authenticated user. ` This is just a simple page component with a style imported at the top. RouteGuard Component ` This serves as the wrapper for routes you want to protect from unauthenticated users. If there is no token in the session storage, the user will be routed to the signin page. Header component If you already have the content for the header file, you don't have to change it. All you need is the logOut function. ` Above, we have styles imported from the header CSS module, and we have a logOut function that is used to remove the token from the session storage and also navigate the user to the signin page. Header styles This is the style for the header component. ` Updates for src/App.jsx This file is where the route is managed, and where we grouped certain routes we wanna guard or protect from unauthenticated users. ` Update for src/App.module.css ` Updates for src/index.jsx We have to update this file by wrapping our App with Router ` Update for src/index.css ` Conclusion In this article, we were able to understand what authentication is, and how to create a route guard which is very important when trying to prevent certain users from accessing certain routes in our application. I hope we have been able to help you see the possibilities of making use of SolidJS and Solid Router to build a well-authenticated application. If you are having issues, you can check out the repo for SolidJS-route-guard. Don't forget that you can see, in detail, how this was maximized in one of This Dot's open source project starter.dev GitHub Showcases. Happy coding!...

Mar 6, 2023

4 mins

SolidJS

What Sets the Best Autonomous Coding Agents Apart?

Must-have Features of Coding Agents Autonomous coding agents are no longer experimental, they are becoming an integral part of modern development workflows, redefining how software is built and maintained. As models become more capable, agents have become easier to produce, leading to an explosion of options with varying depth and utility. Drawing insights from our experience using many agents, let's delve into the features that you'll absolutely want to get the best results. 1. Customizable System Prompts Custom agent modes, or roles, allow engineers to tailor the outputs to the desired results of their task. For instance, an agent can be set to operate in a "planning mode" focused on outlining development steps and gathering requirements, a "coding mode" optimized for generating and testing code, or a "documentation mode" emphasizing clarity and completeness of written artifacts. You might start with the off-the-shelf planning prompt, but you'll quickly want your own tailored version. Regardless of which modes are included out of the box, the ability to customize and extend them is critical. Agents must adapt to your unique workflows and prioritize what's important to your project. Without this flexibility, even well-designed defaults can fall short in real-world use. Engineers have preferences, and projects contain existing work. The best agents offer ways to communicate these preferences and decisions effectively. For example, 'pnpm' instead of 'npm' for package management, requiring the agent to seek root causes rather than offer temporary workarounds, or mandating that tests and linting must pass before a task is marked complete. Rules are a layer of control to accomplish this. Rules reinforce technical standards but also shape agent behavior to reflect project priorities and cultural norms. They inform the agent across contexts, think constraints, preferences, or directives that apply regardless of the task. Rules can encode things like style guidelines, risk tolerances, or communication boundaries. By shaping how the agent reasons and responds, rules ensure consistent alignment with desired outcomes. Roo code is an agent that makes great use of custom modes, and rules are ubiquitous across coding agents. These features form a meta-agent framework that allows engineers to construct the most effective agent for their unique project and workflow details. 2. Usage-based Pricing The best agents provide as much relevant information as possible to the model. They give transparency and control over what information is sent. This allows engineers to leverage their knowledge of the project to improve results. Being liberal with relevant information to the models is more expensive however, it also significantly improves results. The pricing model of some agents prioritizes fixed, predictable costs that include model fees. This creates an incentive to minimize the amount of information sent to the model in order to control costs. To get the most out of these tools, you’ve got to get the most out of models, which typically implies usage-based pricing. 3. Autonomous Workflows The way we accomplish work has phases. For example, creating tests and then making them pass, creating diagrams or plans, or reviewing work before submitting PRs. The best agents have mechanisms to facilitate these phases in an autonomous way. For the best results, each phase should have full use of a context window without watering down the main session's context. This should leverage your custom modes, which excel at each phase of your workflow. 4. Working in the Background The best agents are more effective at producing desired results and thus are able to be more autonomous. As agents become more autonomous, the ability to work in the background or work on multiple tasks at once becomes increasingly necessary to unlock their full potential. Agents that leverage local or cloud containers to perform work independently of IDEs or working copies on an engineer's machine further increase their utility. This allows engineers to focus on drafting plans and reviewing proposed changes, ultimately to work toward managing multiple tasks at once, overseeing their agent-powered workflows as if guiding a team. 5. Integrations with your Tools The Model Context Protocol (MCP) serves as a standardized interface, allowing agents to interact with your tools and data sources. The best agents seamlessly integrate with the platforms that engineers rely on, such as Confluence for documentation, Jira for tasks, and GitHub for source control and pull requests. These integrations ensure the agent can participate meaningfully across the full software development lifecycle. 6. Support for Multiple Model Providers Reliance on a single AI provider can be limiting. Top-tier agents support multiple providers, allowing teams to choose the best models for specific tasks. This flexibility enhances performance, the ability to use the latest and greatest, and also safeguards against potential downtimes or vendor-specific issues. Final Thoughts Selecting the right autonomous coding agent is a strategic decision. By prioritizing the features mentioned, technology leaders can adopt agents that can be tuned for their team's success. Tuning agents to projects and teams takes time, as does configuring the plumbing to integrate well with other systems. However, unlocking massive productivity gains is worth the squeeze. Models will become better and better, and the best agents capitalize on these improvements with little to no added effort. Set your organization and teams up to tap into the power of AI-enhanced engineering, and be more effective and more competitive....

Jun 3, 2025

4 mins

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Mocking API on Storybook using MSW

What is MSW?

Why Mock?

What is a Mock Server?

What is a Service Worker?

Use Cases

Installing MSW and the addon

Generate a service worker for MSW in your public folder.

Configuring Storybook

Creating our mock API

How do we make use of the Handler?

Card component

Posts component

Code Explanation

Overview Of the UI

Why mock?

Conclusion

Jerry Hogan

You might also like

Quick Guide to Playwright Fixtures: Enhancing Your Tests

How to test React custom hooks and components with Vitest

How To Authenticate Your SolidJS Routes With Solid Router

What Sets the Best Autonomous Coding Agents Apart?

Let's innovate together!

You might also like

Quick Guide to Playwright Fixtures: Enhancing Your Tests

How to test React custom hooks and components with Vitest

How To Authenticate Your SolidJS Routes With Solid Router

What Sets the Best Autonomous Coding Agents Apart?