Javascript

Applitools — The Automated Visual Regression Testing Framework

Published Oct 28, 2019

Updated Feb 14, 2023

15 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.

Applitools is a fully-packed automation framework for visual UI regression testing. Whether you’re already serious about visual UI testing and looking for an easy way to automate this type of testing for your web and mobile applications, or you’ve just started looking into visual UI testing techniques, you may want to give Applitools a try to discover the advantages this tool provides in terms of automating your visual UI tests with regression-testing at the core!

In this post, we introduce the features of Applitools. In particular, we explain how Applitools can be used with a variety of programming languages and technologies, and we shed light on the importance of visual regression testing. You will learn the unique ways Applitools facilitates the process of running regression tests, and how Applitools easily reports test results including visual discrepancies, which is something very difficult to automate effectively without the AI engine provided by Applitools.

UI Testing

With UI testing, you test the function of your web app via simulated user inputs. For instance, by using the Cypress.io testing framework, you can simulate user actions of opening a web browser, locating and clicking a button on the page, or even inputting some text into an input field. This works perfectly and can be a great aid to help test the UI side of your application by verifying the function of the pages and how they will perform in production.

However, UI functional testing is only one aspect of testing, and this alone is not enough to do a full visual test of your application. We must consider things such as changes in the layout, size, or location of the components on the page, changes in the text formatting or content, and many other visual changes that are more difficult to detect with traditional functional testing. This is especially true with responsive web applications that change layout based on the size of their viewport.

Hence, visual UI testing is inevitable and a must! Otherwise, unintended UI changes (change in CSS, content, etc.) will go unnoticed in your testing and affect your users.

Visual UI Testing

Automated visual UI testing is a form of regression testing that follows certain steps in order to validate that screens or pages have not changed unexpectedly from one test run to another. The figure below depicts a typical test case simulating a user’s actions for opening the “Wikipedia” website and searching for “Software” as a keyword.

The process of doing visual UI testing starts by creating a typical integration test case using the same tools and test suites you would normally use in executing such integration tests. An integration test is a series of actions executed on the app screens/pages, simulating an actual user.

With visual UI testing, you follow the same steps as above but with a twist:

Open a browser and navigate to the “Wikipedia” website.
The step above creates a new state of a “Browser opening Wikipedia website”.
Take a snapshot of this state. If this is the first time the test case is running, then you will save this snapshot as a “baseline” for this step within the test case. This is also true for the other snapshot steps below.
Entering the “Software” keyword into the Search-box.
The step above creates a new state of “Wikipedia English website and the search-box field populated with the keyword Software”.
Take a snapshot of this state.
“Wikipedia” Software page opens.
The steps above create a new state of “Wikipedia Software page displayed for user”.
Take a snapshot of this state.

The next time you run the same test case again, upon taking a snapshot, you would compare the snapshot to the baseline and report the results. The results could be:

No change: In this case, the new snapshot is equivalent to the baseline snapshot.
Change: In this case, the new snapshot has some UI changes compared to the baseline snapshot.

The visual UI tester is now responsible for comparing the snapshots, analyzing them and deciding how to address any differences. They may accept the differences, save the new snapshot as the baseline and use it for the coming regression tests. Or, they may reject the differences and inform the developers of the bugs and issues noted by the results.

How Applitools works

Applitools uses the same approach as above by providing the tools that you can use to take snapshots, send snapshots to the Applitools cloud and run AI logic to compare the snapshots with their corresponding baselines.

Applitools provides a rich set of Software Development Kits (SDKs) for well-known test suites. For instance:

SDK for Cypress.io end-to-end testing framework (recently launched)
SDKs for Storybook with React, Angular and Vue (recently launched)
SDKs for almost all of the Selenium flavors (JavaScript, Java, C#, Ruby, etc.).
SDKs for almost all of the Appium flavors (Native C#, Native Java, Native PHP, etc.).

For instance, Applitools for Selenium SDK wraps the Selenium WebDriver and provides a new and enhanced WebDriver that you can use to simulate a user’s actions on a screen or page. The only difference is that Applitools is now aware of each and every action you execute on the Selenium WebDriver. This makes it easy for Applitools to capture snapshots of the results of an action executed against the WebDriver.

When using Applitools SDK in your test cases, you can ask the SDK to capture the state of the application whenever you want. This process is as follows:

The SDK takes a snapshot of the browser
The resultant snapshot is sent to the Applitools Server
If there is no previous baseline image, the Server stores the image as the baseline for comparison in future test runs
If there was a previous baseline image, the Server runs its AI engine to compare the baseline image to the new snapshot. The engine reports whether the images match, or the engine reports any discrepancies between the two images.
Upon completion of the tests, a detailed report is generated on the differences between the various snapshots and their corresponding baselines.

With the recent launch of Cypress.io and Storybook SDKs, Applitools took a new and enhanced approach to visual testing — the Applitools Visual Grid. Instead of snapshot images, DOM Snapshots are uploaded to the Applitools Servers, and these snapshots are now analyzed in parallel. The result is up to 30x improvement in the speed of your visual testing suite.

Applitools Test Manager

In addition, Applitools provides a rich Test Manager dashboard to help you manage all the tests you run. You can run multiple test cases within a single batch.

For each test case, you get a list of all the snapshots taken throughout the execution of the test case. The dashboard will notify you of any test cases that are unresolved, meaning the snapshots generated by the test case might be different from those stored as baselines. The dashboard provides the tools to mark those changes as accepted and updates them as the new baseline snapshot, or rejects the differences and marks those changes as bugs for the developers to address.

The Test Manager provides a variety of features to make the process of checking and validating test case results an easy one.

The powerful AI engine behind Applitools can use one of four pattern matching algorithms to compare the snapshots to their corresponding baselines. The algorithms are:

Exact: This is a pixel-to-pixel matching technique which is generally not recommended due to its strictness.
Strict: This matching technique compares everything including content (text), fonts, layout, colors and position of each of the elements. This mode ignores the rendering changes that are not visible to the human. You will generally get the best results with this mode of comparison.
Content: This option is similar to the strict option above except that it only performs content (text) comparisons.
Layout: This option is similar to the strict option above except that it only performs layout comparisons.

You can specify the matching strategy within the test case code itself or through the Test Manager when viewing the comparison results between the snapshots.

Screenshot API

In addition to selecting and using one of the available SDKs, Applitools provides the Screenshots API in a variety of programming languages that can help you in taking snapshots of anything in your application and sending those snapshots to the Applitools Server to process and generate comparison results.

The Screenshots APIs available are:

With a Snapshots API, you can easily send snapshots to the Applitools Server, run comparisons on the snapshots, and generate comparison results. Hence, the Snapshots API could be used as a general purpose gateway to access the AI engine sitting behind the Applitools Server.

Demo

Now let’s switch gears and get our hands dirty developing a simple test case making use of the Applitools SDK for Cypress.io.

In this test case, we will simulate the process of navigating to the “Wikipedia.com” website, clicking to the English version of the website, typing “Software” in the search-box field, and finally navigating to the “Software” page on Wikipedia.

Initialize NPM on a new folder

I will start by creating a new folder and initializing it with NPM to access the package.json file. Issue the following command and follow the steps required to generate the file:

npm init

Install Cypress package

The next step is to install the Cypress NPM package with its files and start testing your source code with Cypress. Issue the following command:

npm install cypress --save-dev

This command installs Cypress package as a dev dependency onto your project.

Now open Cypress and run it locally. Issue the following command:

npx cypress open

The first time you run this command, Cypress prompts you with a warning message that it is about to add some configuration files and sample tests to help you get started. It will appear like this.

Click on Ok, got it! button to proceed and run Cypress locally. Two things happened here:

A new folder named cypress was created inside your project root folder with a few sub-folders inside following the structure of a typical Cypress folder-configuration system that is used to run your tests.
The Cypress Test Runner is now open and you can start playing around with the sample tests and run them.

Click on any of the tests and familiarize yourself on how Cypress runs tests in the browser.

Create our first test case

Let’s go ahead and create our first test case with Cypress. In the context of this article, I will assume you know how to write Cypress test cases. If for some reason you require additional information, you can visit the Cypress website and explore their detailed documentation by clicking on this link: Cypress Getting Started.

Let’s get going!

Add a new folder named Wikipedia under the cypress/integration folder.
Add a new JavaScript file named searching.spec.ts under the new folder you created.
Include the following source code inside the new file

/// <reference types=”Cypress” />

    context(‘Wikipedia’, () => {
      beforeEach(() => {
        // Go to Wikipedia website
        cy.visit(‘https://www.wikipedia.org/')
      });

      it(‘Go to Software page by searching for “Software”’, () => {
        // Find the “English” link and click it
        cy.get(‘#js-link-box-en’).click();

        // Find the search-box control and type “Software”
        cy.get(‘#searchInput’)
          .type(‘Software’) // Type “Software”
          .should(‘have.value’, ‘Software’) // Check for correct value
          .type(‘{enter}’); // press enter

        // check if the element has a class  
        cy.get(‘#firstHeading’).should(‘have.class’, ‘firstHeading’);
      })
    })

Before each test case run, the code is instructing Cypress to visit the “Wikipedia” website. Our test case for this article verifies that when searching for “Software” on Wikipedia, the user is directed to the Software page there.

Notice, the code starts by finding the English link on the Wikipedia website and clicking it. Now, Wikipedia is in a state where the English version of its website is displayed to the user.

The test case locates the search-box input control, on the page, by its ID. Then, by using the powerful chaining/fluent Cypress API, it issues a command to type the text “Software” into the search-box input control. Then it makes sure the input control now holds the text of “Software”. Finally, it issues an Enter command to actually submit the search form.

The last line of code assumes that the user has been transferred to the English page on Wikipedia. It locates an HTML DIV by its ID and verifies that it has a CSS class of firstHeading.

The test case is fairly simple yet it gives you an idea on how you may use Cypress to write your functional/UI tests for your application.

Let’s run the tests by issuing the following command:

npx cypress open

On the Cypress Test Runner, locate the searching.spec.ts file and click on it.

Cypress runs the selected test and open a new instance of the Chrome (headless) browser to run all the commands in the test case.

You may go through the test case steps on the left-hand side of the page and try replaying individual steps and watch how they get executed on the fly on the right-hand side of the page.

Now let’s add some visual UI testing with Applitools.

Add Applitools Cypress SDK to the mix

Let’s start by installing the Applitools Cypress SDK into our project. For that purpose, you can issue the following command:

npm install @applitools/eyes.cypress --save-dev

The npm command above installs the Applitools eyes.cypress plugin as a dev dependency on your project. (Eyes is the name of Applitools’ product.)

The next step is to configure the eyes.cypress plugin by issuing the following command:

npx eyes-setup

The npx command above adds the necessary imports to your cypress plugins and support files. You may read additional information on how to setup eyes.cypress in full detail by clicking on this link: @applitools/eyes.cypress.

In brief, the command added the following line of code to the plugins/index.js file:

require(‘@applitools/eyes.cypress’)(module);

In addition, the following line of code was also added to the support/index.js file:

import ‘@applitools/eyes.cypress/commands’

With these packages now installed on the project, you may start enjoying visual UI testing!

Let’s amend the test case with a few calls to the eyes.setup plugin to save snapshots for the different test case states and send them to the Applitools Servers.

    /// <reference types=”Cypress” />

    context(‘Wikipedia’, () => {
      beforeEach(() => {
        // Go to Wikipedia website
        cy.visit(‘https://www.wikipedia.org/')

        // Open a connection with Applitools Servers
        cy.eyesOpen({
          appName: ‘Intro to Applitools Cypress SDK’,
          testName: ‘Searching Wikipedia’,
          browser: { width: 800, height: 600 }
        });

        // Take a snapshot after the browser opens Wikipedia page
        cy.eyesCheckWindow(‘Wikipedia home page’);
      });

      afterEach(() => {
        // Close the connection with Applitools Servers
        cy.eyesClose();
      });

      it(‘Go to Software page when searching for “Software”’, () => {
        // Find the “English” link and click it
        cy.get(‘#js-link-box-en’).click();

        // Take a snapshot of Wikipedia English Page
        cy.eyesCheckWindow(‘Wikipedia English Page’);

        // Find the search-box control and type “Software”
        cy.get(‘#searchInput’)
          .type(‘Software’) // Type “Software”
          .should(‘have.value’, ‘Software’) // Check for correct value
          .type(‘{enter}’); // press enter

        // Take a snapshot of the Software Page on Wikipedia
        cy.eyesCheckWindow(‘Software Page on Wikipedia’);

        // check if the element has a class
        cy.get(‘#firstHeading’).should(‘have.class’, ‘firstHeading’);
      })
    })

The test case opens a connection to the Applitools Servers before running each and every test case using the following line of code:

    cy.eyesOpen({
      appName: ‘Intro to Applitools Cypress SDK’,
      testName: ‘Searching Wikipedia’,
      browser: { width: 800, height: 600 }
    });

The call to the eyesOpen() method specifies the name of the application, the name of the test case and the browser dimensions. You have plenty of properties to include on this method, and you may check them all by clicking on this link: @applitools/eyes.cypress.

The code then issues a command to the eyes.cypress plugin to take a snapshot of the current state of the test case.

    // Take a snapshot after the browser opens Wikipedia page
    cy.eyesCheckWindow(‘Wikipedia home page’);

The eyesCheckWindow() function takes as input the name of the snapshot and sends it instantaneously to the Applitools Servers.

After running each and every test case the code also closes the connection with the Applitools Servers:

    afterEach(() => {
      // Close the connection with Applitools Servers
      cy.eyesClose();
    });

In the body of the test case, I include several calls to the cy.eyesCheckWindow() function to collect a few snapshots for the different states of the test case.

As you can see, the process of using the eyes.cypress is fairly straightforward.

Let’s run the tests again by issuing the following command:

npx cypress open

You can follow on Cypress while it is running the test case.

Let’s review the results in the Applitools Test Manager.

Review the results in the Applitools Test Manager

Now that we run our visual/UI test case with Applitools Cypress SDK, let’s explore the Applitools Eyes Test Manager and see what happened here.

To log into the Test Manager sign-in at the Applitools website.

The image shown above is what you see when you log in to the Applitools Test Manager.

You notice a single batch on the left-hand side. This is the test case that we performed. Applitools can run multiple test cases in a single batch. In this case, we only have a single test case in the batch.

By clicking on the batch the Test Manager displays the test case(s) inside this batch on the right side of the screen.

The status of the test case is “New”, meaning this is the first time the test case was executed. Therefore, there are no previous baseline snapshots to compare against.

By clicking on the test case you can see all the snapshots that Applitools Cypress SDK took during the running of the test case.

Clicking on the third snapshot, the dashboard expands the image so you can review it carefully.

In general, when viewing a snapshot in the zoomed-mode, you get the chance to see the current snapshot on the right-hand side and the baseline (if any) on the left-hand side.

If you cannot see both snapshots, then you need to instruct the Test Manager to display both as shown in this figure:

Let’s run the test case once again, except this time, before running the test, we will change the search term in our test from “Software” to something else like “Applitools”. This will imitate the effect of having a visual regression in our test results that we would like Applitools to detect.

Run the tests and then visit the Test Manager and notice the following results.

Now we can see the two batches that we ran. However, the second run of the same batch has a status of “Unresolved”. This means that the snapshots that were taken in the second batch have some differences compared to the baseline snapshots taken in the first run.

By clicking on the test case on the right-hand side of the screen you can see the following:

The Test Manager displays all of the snapshots in the test case. The third snapshot shows a difference between this one and the baseline snapshot. You may click on the third snapshot and view the differences.

You can notice the Not Equal sign surrounded by a red rectangle (The rectangle added on the snapshot above to highlight this section). The sign clearly shows that the new snapshot is different from the baseline snapshot taken in a previous run for the test case. This demonstration simulates a regression testing cycle where things change (content or anything else) and with Applitools Test Manager you can detect the changes and report them.

This was just the tip of the iceberg in exploring the Test Manager. You may learn more about Applitools and the Test Manager by visiting the Applitools website.

Conclusion

In this article you have explored writing a UI/integration test case, converting the test case into a visual/UI test case using Applitools Cypress SDK, and using the Test Manager to study and analyze the results.

There is plenty of information about Applitools that I recommend you check on their website if you are really serious about adding visual UI testing to your projects.

Happy Applitooling!

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)

Bilal Haidar
Author, Developer, and Mentor: Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB | A Complete Guide to VueJS
@bhaidar @bhaidar

Making sense of Multiple v-model Bindings in Vue 3

This article is one of a series of articles on what’s new in Vue 3. If you haven’t checked that series yet, you can do so by visiting the links below: - Take your App to the Next Level with Vue 3 - Async Components in Vue 3 - Teleporting in Vue 3 - Your first Vue 3 app using TypeScript - Vue 3 Composition API, do you really need it? In this installment, I will introduce the new v-model in Vue 3 and go through a new feature that allows you to use multiple v-model on the same component! By design, the v-model directive allows us to bind an input value to the state of an app. We use it to create a two-way data binding on the form input, textarea, and select elements. It handles updates in two opposite directions: When the input value changes, it reflects the value onto the state inside the Component. When the Component state changes, it reflects the changes onto the form input elements. The core concept of v-model remains the same in Vue 3 with more enhancements and features. Let’s dig in! Vue 2: v-model Vue 2 supports a single v-model on any given Component. In Vue 2, to build a complex Component that supports two-way data binding, it utilizes a single v-model with one full-blown payload. The Component handles the state internally for all the input elements. It generates a single payload object representing the state of the Component. Finally, it emits an event to the parent Component with the payload attached. This method had several pitfalls, especially for creating Vue UI Libraries. Of these pitfalls is the vagueness of the payload interface. It’s unclear what’s being included in the payload. A developer had to loop through the payload object in order to uncover what properties were there. Another is the need to write the logic inside the Component to handle the internal state and the generation of the payload object. Shortly, we will uncover what has been improved in this regard with Vue 3. However, before this, let’s review some basics on how Vue 2 handles implementing two-way data binding in Components. Vue 2: Two-way Data Binding As mentioned, Vue 2 uses the v-model directive to support two-way data binding on Components. Internally, it follows certain steps and rules in order to support the v-model directive. By default, the v-model directive uses different properties and emits different events for different input elements: Text and Textarea elements use the value property and the input event Checkboxes and Radio buttons use the checked property and the change event Select fields use the input property and the change event. Building a Component with a single input element will internally use something similar to the snippet below: ` The custom Component above defines a single prop named value as follows: ` Then, in the parent Component, you use the new custom Component as follows: ` The v-model directive assumes that the CustomComponent defines an internal property named value and emits a single event named input. What if the CustomComponent has to handle multiple inputs? How do we accomplish that in Vue 2? Well, there is no official solution. However, there are two methods that you can use: The CustomComponent defines a single property named value of type Object. Internally, it parses the object into data fields and does the mapping manually on the template. On every change of any of the fields, it prepares a payload for all the fields and emits a single input event, and attaches the payload. That’s a lot of code to write for such a custom component. The other option is to skip using the v-model directive and instead utilize individual input/event pairs. I will illustrate this in a moment. Assuming you have a custom Component to handle the user’s first name and last name, you would employ something similar: ` As for the properties, the Component defines the following: ` Finally, the parent Component uses the new component as follows: ` We are not using the v-model anymore and providing multiple two-way data bindings on the new component. Further your understanding by reading the official docs on Using v-model on Components Vue 3: v-model In Vue 3, the v-model directive has had an overhaul to give developers more power and flexibility when building custom components that support two-way data binding. The v-model directive now supports new defaults. The default v-model property is renamed to modelValue instead of the old name of value. The default v-model event is renamed to update:modelValue instead of the old name of input. You might be thinking that's more typing when using the new v-model directive. The Vue team are one step ahead and have given you a shorthand to use instead. Let’s rebuild the custom component using it. ` The custom component defines a single prop named modelValue as follows: ` Then, in the parent component, use the new custom component as follows: ` The new v-model directive offers the new shorthand that is used like this: ` The v-model directive assumes that the CustomComponent defines an internal property named modelValue and emits a single event named update:ModelValue. In case you don’t want to use the default naming convention, feel free to use another name. Just remember to be consistent when naming properties. Here’s an example of using a custom name for the modelValue property. ` The custom component above defines a single prop named modelValue as follows: ` Then, in the parent component, you use the new custom component like so: ` Notice the use of the property fullName instead of the default property name. Vue 3: Multiple v-model directive bindings I hope the Vue 3 shorthand form of the v-model directive has given you a "hand up". With this, the v-model gives the flexibility to use multiple v-model directives on a single component instance. The modelValue can be renamed to whatever you want, allowing you to do this! This great new feature eliminates the previous two solutions I offered up on handling complex custom components for Vue 2. Let's jump in and go through an example demonstration! Demo - Multiple v-model directive bindings Let’s build a custom Address component that can be embedded in any form to collect a user’s address. > You can play with the example live on: vue3-multiple-v-model. > You can check the source code for the example on: vue3-multiple-v-model. Figure 1 below shows the final app in action. Let’s start by building the HTML template of the new component. Figure 1 shows that all the fields used are of type input elements. Except for the last one which is a checkbox element. Therefore, it’s suffice to focus on a single input field that will eventually be replicated for the rest of fields. ` The address-line input field binds the :value directive and the @input event as per the new v-model directive specifications in Vue 3. The component defines the following property: ` The other fields follow the same structure and naming convention. Let’s look at the checkbox field and see how it’s defined: ` In the case of a checkbox field element, we bind to the :checked directive instead of the :value directive. Also, we use the @change event instead of the @input event as in the case of input field elements. The event name follows the same standard way of emitting events in the new v-model directive. The component defines the following property: ` Let’s now embed the new custom Address component into the App component: ` For each and every property on the custom component, we bind using the v-model:{property-name} format. The modelValue was replaced with the specific property names we have in hand. When there was a single input binding, the shorthand format was so much easier. However, when there are multiple input elements, the modelValue is in a league of its own! Now, let’s define the properties inside the App component using the new Composition API setup() function: ` You create a new reactive property with an object payload. Finally, you return the reactive property to the component and use it to set bindings on the custom Address component as follows: ` That’s it! Conclusion Vue 3 has many new features and improvements. Today, we saw how we use multiple v-model directives on a single component instance. There is so much more to learn and uncover in Vue 3. The coming installments of this series will continue to look at different features to help you move from Vue 2 to Vue 3. Happy Vueing!...

Nov 6, 2020

6 mins

Vue

Increasing development velocity with Cursor

If you’re a developer, you’ve probably heard of Cursor by now and have either tried it out or are just curious to learn more about it. Cursor is a fork of VSCode with a ton of powerful AI/LLM-powered features added on. For around $20/month, I think it’s the best value in the AI coding space. Tech giants like Shopify and smaller companies like This Dot Labs have purchased Cursor subscriptions for their developers with the goal of increased productivity. I have been using Cursor heavily for a few months now and am excited to share how it’s impacted me personally. In this post, we will cover some of the basic features, use cases, and I’ll share some tips and tricks I’ve learned along the way. If you love coding and building like me, I hope this post will help you unleash some of the superpowers Cursor’s AI coding features make possible. Let’s jump right in! Cursor 101 The core tools of the Cursor tool belt are Autocomplete, Ask, and Agent. Feature: Autocomplete The first thing that got me hooked was Autocomplete. It just worked so much better than the tools I had used previously, like GitHub Copilot. It was quicker and smarter, and I could immediately notice the amount of keystrokes that it was saving me. This feature is great because it doesn’t really require any work or skilled prompting from the user. There are a couple of tricks for getting a little bit more out of it that I will share later, but for now, just enjoy the ride! Feature: Ask If you’ve interacted with AI/LLMs before, like ChatGPT - this is what the Ask feature is. It’s just a chat feature you can easily provide context to from your code base and choose which Model to chat with. This feature is best suited for just asking more general questions that you might have queried Google or Stack Overflow for in the past. It’s also good for planning how to implement a feature you’re working on. After chatting or planning, you can switch directly to Agent mode to pick up and take action on something you were cooking up in Ask mode. Here’s an example of planning a simple tic-tac-toe game implementation using the Ask feature: Feature: Agent Agent mode lets the AI model take the wheel and write code, make edits, or take other similar actions on your code base. The goal is that you can write prompts and give instructions, and the Agent can generate the code and build features or even entire applications for you. With great power comes great responsibility. Agents are a feature where the more you put into them, the more you get out. The more skilled you become in using them by providing better prompts and including the right context, you will continue to get better results. The AI doesn’t always get it right, but the fact that the models and the users are both getting better is exciting. Throughout this post, I will share the best use cases, tips, and tricks I have found using Cursor Agent. Here’s an example using the Agent to execute the implementation details of the tic-tac-toe game we planned using Ask: Core Concept: Context After understanding the features and the basics of prompting, context is the most important thing for getting the best results out of Cursor. In Cursor and in general, whenever you’re prompting a chat or an agent, you want to make sure that it has all the relevant information that it needs to provide an answer or result. Cursor, by default, always has some context of your code. It indexes your code base and usually keeps the open buffer in the context window at the very least. At the top left of the Ask or Agent panel, there is an @ button, and next to that are badges for all the current items that have been explicitly added to the context for the current session. The @ button has a dropdown that allows you to add files, folders, web links, past chats, git commits, and more to the context. Before you prompt, always make sure you add the relevant content it needs as context so that it has everything it needs to provide the best response. Settings and Rules Cursor has its own settings page, which you can access through Cursor → Settings → Cursor Settings. This is where you log in to your account, manage various features, and enable or disable models. In the General section, there is an option for Privacy Mode. This is one setting in particular I recommend enabling. Aside from that, just explore around and see what’s available. Models The model you use is just as important as your prompt and the context that you provide. Models are the underlying AI/LLM used to process your input. The most well-known is GPT-4o, the default model for ChatGPT. There are a lot of different models available, and Cursor provides access to most of them out of the box. Model pricing A lot of the most common models, like GPT-4o or Sonnet 3.5/3.7, are included in your Cursor subscription. Some models like o1 and Sonnet 3.7 MAX are considered premium models, and you will be billed for usage for these. Be sure to pay attention to which models you are using so you don’t get any surprise bills. Choosing a Model Some models are better suited for certain tasks than others. You can configure which models are enabled in the Cursor Settings. If you are planning out a big feature or trying to solve some complex logic issue, you may want to use one of the thinking models, like o1, o3-mini, or Deep Seek R1. For most coding tasks and as a good default, I recommend using Sonnet 3.5 or 3.7. The great thing about Cursor is that you have the options available right in your editor. The most important piece of advice that I can give in this post is to keep trying things out and experimenting. Try out different models for different tasks, get a feel for it, and find what works for you. Use cases Agents and LLM models are still far from perfect. That being said, there are already a lot of tasks they are very good at. The more effective you are with these tools, the more you will be able to get done in a shorter amount of time. Generating test cases Have some code that you would like unit tested? Cursor is very good at generating test cases and assertions for your code. The fewer barriers there are to testing a piece of code, the better the result you will get. So, try your best to write code that is easily testable! If testing the code requires some mocks or other pieces to work, do your best to provide it the context and instructions it needs before writing the tests. Always review the test cases! There could be errors or test cases that don’t make sense. Most of the time, it will get you pretty close to where you want to be. Here’s an example of using the Agent mode to install packages for testing and generate unit tests for the tic-tac-toe game logic: Generating documentation This is another thing we know AI models are good at - summarizing large chunks of information. Make sure it has the context of whatever you want to document. This one, in particular, is really great because historically, keeping documentation up to date is a rare and challenging practice. Here’s an example of using the Agent mode to generate documentation for the tic-tac-toe game: Code review There are a lot of up-and-coming tools outside of Cursor that can handle this. For example, GitHub now has Copilot integrated in pull requests for code reviews. It’s never a bad idea to have whatever change set you’re looking to commit reviewed and inspected before pushing it up to the remote, though. You can provide your unstaged changes or even specific commits as context to a Cursor Ask or Agent prompt. Getting up to speed in a new code base Being able to query a codebase with the power of LLM’s is truly fantastic. It can be a great help to get up to speed in a large new codebase quickly. Some example prompts: > Please provide an overview of this project and how to get started developing with it > I need to make some changes to the way that notifications are grouped in the UI, please provide a detailed analysis and pseudo code outlining how the grouping algorithm works If you have a question about the code base, ask Cursor! Refactoring Refactoring code in a code base is a much quicker process in Cursor. You can execute refactors depending on their scope in a couple of distinct ways. For refactors that don’t span a lot of files or are less complex, you can probably get away with just using the autocomplete. For example, if you make a change to something in a file and there are several instances of the same pattern following, the autocomplete will quickly pick up on this and help you tab through the changes. If you switch to another file, this information will still be in context and can be continued most of the time. For larger refactors spanning several files, using the Agent feature will most likely be the quickest way to get it done. Add all the files you plan to make changes to the Agent tab’s context window. Provide specific instructions and/or a basic example of how to execute the refactor. Let the Agent work, if it doesn’t get it exactly right initially, you can always give it corrections in a follow-up prompt. Generating new code/features This is the big promise of AI agents and the one with the most room for mixed results. My main recommendation here is to keep experimenting. Keep learning to prompt more effectively, compare results from different models, and pay attention to the results you get from each use case. I personally get the best results building new features in small, focused chunks of work. It can also be helpful to have a dialog with the Ask feature first to plan out the feature's details that the Agent can follow up on and implement. If there are existing patterns in your codebase for accomplishing certain things, provide this information in your prompts and make sure to add the relevant code to the context. For example, if you’re adding a new form to the web page and you have other similar forms that handle validation and making back-end calls in the same way, Cursor can base the code for the new feature on this. Example prompt: Generate a form for creating a new post, follow similar patterns from the create user profile form, and look to the post schema for the fields that should be included. Remember that you can always follow up with additional prompts if you aren’t quite happy with the results of the first.. If the results are close but need to be adjusted in some way, let the agent know in the next prompt. You may find that for some things, it just doesn’t do well yet. Mentally note these things and try to get to a place where you can intuit when to reach for the Agent feature or just write some of the code the old-fashioned way. Tips and tricks The more you use Cursor, the more you will find little ways to get more out of it. Here are some of the tips and patterns that I find particularly useful in my day-to-day work. Generating UI with screenshots You can attach images to your prompts that the models can understand using computer vision. To the left of the send button, there is a little button to attach an image from your computer. This functionality is incredibly useful for generating UI code, whether you are giving it an example UI as a reference for generating new UI in your application or providing a screenshot of existing UI in your application and prompting it to change details in reference to the image. Cursor Rules Cursor Rules allow you to add additional information that the LLM models might need to provide the best possible experience in your codebase. You can create global rules as well as project-specific ones. An example use case is if your project has some updated dependency with newer APIs than the one on which the LLM has been trained. I ran into this when adding Tailwind v4 to a project; the models are always generating code based on Tailwind v3 or earlier. Here’s how we can add a rules file to handle this use case: ` If you want to see some more examples, check out the awesome-cursorrules repository. Summary Learn to use Cursor and similar tools to enhance your development process. It may not give you actual superpowers, but it may feel like it. All the features and tools we’ve covered in this post come together to provide an amazing experience for developing all types of software and applications....

Apr 18, 2025

11 mins

AICursor

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.

Applitools — The Automated Visual Regression Testing Framework

UI Testing

Visual UI Testing

How Applitools works

Applitools Test Manager

Screenshot API

Demo

Initialize NPM on a new folder

Install Cypress package

Create our first test case

Add Applitools Cypress SDK to the mix

Review the results in the Applitools Test Manager

Conclusion

Bilal Haidar

You might also like

Making sense of Multiple v-model Bindings in Vue 3

Increasing development velocity with Cursor

Let's innovate together!

You might also like

Making sense of Multiple v-model Bindings in Vue 3

Increasing development velocity with Cursor