DEV Community: S Chathuranga Jayasinghe

Comet Browser: The Revolutionary AI-Powered Browser That Actually Does Your Work

S Chathuranga Jayasinghe — Wed, 27 Aug 2025 21:25:22 +0000

Remember when browsers were just glorified document viewers? You'd click links, fill forms manually, and navigate through websites one laborious step at a time. Well, those days just became ancient history with Comet Browser and trust me, once you experience what this thing can do, going back to Chrome feels like using a stone tablet.

I recently put Comet through its paces with some real-world scenarios, and the results left me genuinely stunned. We're not talking about incremental improvements here; this is a fundamental reimagining of what a browser can be.

What Makes Comet Different

Comet is an AI-powered browser that acts as a personal assistant and thinking partner, featuring the Comet Assistant that can automate routine tasks, summarize emails and calendar events, manage tabs, and navigate web pages on behalf of users. But that description barely scratches the surface of what this browser actually accomplishes.

Comet Browser is the first truly agentic browser, meaning you can not only talk to the built-in Assistant (powered by Perplexity), but you can have it interact with your tabs, emails, calendar, and even navigate the web for you as if an assistant took over your screen.

The key word here is "agentic." What separates Comet from traditional browsers is its "agentic" architecture instead of acting only when prompted, the Comet Assistant can proactively understand page content, follow your browsing history, and offer to complete multi-step tasks across tabs.

The Magic in Action: Real-World Testing

Let me paint you a picture of just how mind-blowing this technology is. I decided to test Comet with a practical e-commerce scenario that anyone who's done online shopping can relate to.

Scenario 1: Text-Based Automation

For my first test, I simply typed out a scenario: "Log into saucedemo.com and sort the items by price." That's it. No step-by-step instructions, no detailed navigation commands just a plain English description of what I wanted to accomplish.

What happened next felt like magic. Comet Browser took over completely, navigating to the website, finding the login elements, entering the credentials, locating the sorting options, and organizing the products by price, all without any input from me. Every click, every form field, every navigation decision was handled autonomously.

Watch as Comet Browser transforms a simple text instruction into a fully automated browsing session, handling every interaction seamlessly from login to product sorting.

Scenario 2: Voice-Powered Web Automation

The second test pushed the boundaries even further. Instead of typing, I used Comet's voice feature to verbally describe the same scenario. The browser didn't just understand my speech, it comprehended the intent, processed the multi-step workflow, and executed everything flawlessly.

Speaking to your browser and watching it perform complex tasks feels like something straight out of a sci-fi movie, except it's happening right now on your desktop.

Experience the future of web browsing as voice commands translate directly into sophisticated web interactions, eliminating the need for manual clicking and typing.

Note: I even generated the banner image for this article using Comet Assistent. I wrote the article, then opened the Assistant on the side and asked to create a banner image for this article. It just went through the article and generated this banner image!

Why This Represents a Paradigm Shift

Launched in July 2025, Comet represents Perplexity AI's attempt to fundamentally change how users interact with the web. Rather than relying on tabs, bookmarks, or search bars, users can now simply ask questions, issue commands, or request tasks, all within a conversational interface.

This isn't just a browser with AI features bolted on it's a complete reconceptualization of web interaction. Here's why it's such a massive leap forward:

From Manual to Conversational

Traditional browsers require you to think like a computer: click here, type there, navigate through menus, remember URLs. Comet lets you think like a human. You describe what you want to accomplish, and it figures out how to do it.

Context-Aware Intelligence

At its core is the Comet Assistant, a contextual AI that can read and interact with whatever is on your screen. This isn't a chatbot living in a search bar. The assistant understands not just what you're asking, but the context of what you're currently doing, where you are on the web, and what logical next steps make sense.

Multi-Step Task Automation

Most AI assistants can answer questions or provide information. Comet actually performs work. It can handle complex, multi-step workflows that typically require dozens of manual interactions, reducing them to simple natural language requests.

The Technical Innovation Behind the Magic

What makes Comet possible is a convergence of several breakthrough technologies:

Agentic AI Architecture: Unlike traditional AI that waits for prompts, Comet's system proactively analyzes web pages, understands their structure, and can interact with any element it encounters.

Natural Language Processing: The browser doesn't just recognize words, it understands intent, context, and can translate conversational requests into precise web actions.

Computer Vision Integration: Comet can "see" web pages the way humans do, identifying buttons, forms, links, and interactive elements regardless of how they're coded or styled.

Voice Recognition and Processing: The voice interface isn't just speech-to-text — it's speech-to-action, bypassing the need for any manual interaction entirely.

Implications for the Future

We're witnessing the birth of what might be called "invisible computing" technology so intuitive that the interface disappears entirely. When you can accomplish complex web tasks through simple conversation, the traditional barriers between human intention and digital execution start to dissolve.

Think about the implications:

Accessibility: Complex web tasks become available to users regardless of their technical proficiency
Productivity: Time spent on routine web interactions drops dramatically
User Experience: The cognitive load of remembering how to navigate different websites vanishes
Automation: Personal web workflows can be as simple as having a conversation

A Word of Caution!

It's worth noting that recent security audits by Brave and Guardio have revealed vulnerabilities in the AI-powered Comet browser, reminding us that cutting-edge technology often comes with growing pains. As with any powerful tool, users should stay informed about security updates and best practices.

The Bottom Line

After experiencing Comet Browser firsthand, I can confidently say we're looking at a genuine inflection point in web technology. This isn't just a better browser, it's a fundamentally different way of interacting with the internet.

Comet is Perplexity's new AI-powered Chromium browser that automates tasks from booking reservations to managing emails, making browsing productive. But even that description undersells what you actually experience when using it.

The web has always been about information and interaction. Comet makes both effortless. When you can simply speak or type what you want to accomplish and watch it happen automatically, you realize how much friction we've been accepting in our daily digital lives.

We're still in the early days of agentic browsing, but the foundation is solid and the potential is staggering. If you get a chance to try Comet Browser, take it. You'll never look at web browsing the same way again.

The future of the internet isn't just about faster connections or better websites, it's about browsers smart enough to be true partners in getting things done. And that future is available to try right now.

From 1-Hour Nightmares to 7-Minute Dreams: Our Cypress Cloud Journey

S Chathuranga Jayasinghe — Wed, 23 Jul 2025 06:00:46 +0000

How we transformed our testing workflow at TrackMan and why Cypress Cloud became our testing superhero

Picture this: It’s 3 PM on a Friday, you’ve just pushed what you think is a small fix, and now you’re staring at your terminal watching Cypress tests crawl by at a snail’s pace. One test… two tests… still going… Your weekend plans are slowly evaporating as you realize you’ve got another 45 minutes to wait before you know if your code actually works.

Note: Don’t deploy on Fridays!

Sound familiar? That was our reality at TrackMan not too long ago.

The Dark Ages: When Testing Felt Like Punishment

Let me paint you a picture of how things used to be. Our Cypress test suite had grown into this massive beast that took nearly an hour to complete. An entire hour! We were running everything sequentially, watching tests execute one by one like we were back in the dial-up internet era.

The worst part? When something broke (and trust me, things broke), debugging was an absolute nightmare. You’d get a cryptic failure message, maybe a screenshot if you were lucky, and then you’d have to play detective, trying to figure out what went wrong. It was like trying to solve a murder mystery with half the clues missing.

We were using Cypress Custom Commands, which seemed like a good idea at the time, but as our test suite grew, maintaining and understanding the flow became increasingly difficult. The whole experience was just… painful.

The Lightbulb Moment: Enter Cypress Cloud

After months of frustration and countless hours lost to slow test runs, we finally decided enough was enough. We’d heard whispers about Cypress Cloud, but like many teams, we were hesitant to make the switch. “Another tool to learn? Another service to manage?” But honestly, we were desperate.

Best decision we ever made!

The Transformation: From Hours to Minutes

Here’s where things get exciting. Remember that nearly 1-hour test suite I mentioned? After moving to Cypress Cloud and implementing parallelization, it now runs in just 7 minutes.

Let me repeat that: 7 minutes.

I’m not exaggerating. We went from grabbing coffee, checking emails, and sometimes even taking walks during test runs to barely having time to refill our water bottles.

What Made the Magic Happen

Smart Test Orchestration: The Brain Behind the Operation

Cypress Cloud’s Smart Test Orchestration is like having a really smart project manager for your tests. Instead of running tests in some random order, it analyzes your test history and intelligently distributes them across multiple machines. Tests that typically take longer get started first, while quicker tests fill in the gaps. It’s beautiful to watch in action.

Parallelization: Divide and Conquer

We’re currently running with parallelization enabled, and it’s a game-changer. Instead of one machine plodding through all our tests, we have multiple machines working simultaneously. Think of it like having multiple checkout lanes at a grocery store instead of making everyone wait in one long line.

With around 44,000 test results per month (yes, we test a lot!), this parallel execution saves us countless hours every single month.

Page Object Model: A Much-Needed Architectural Shift

While we were at it, we also moved from Cypress Custom Commands to the Page Object Model (POM). This wasn’t directly related to Cypress Cloud, but it complemented our new setup perfectly.

Custom Commands felt scattered and hard to maintain as our test suite grew. With POM, everything is organized, reusable, and much easier to understand. Each page has its own class with methods that represent the actions you can perform on that page. It’s clean, it’s logical, and it makes onboarding new team members so much smoother.

Test Replay: The Debugging Superhero We Never Knew We Needed

Now, let’s talk about the feature that has truly saved our sanity: Test Replay.

Remember those debugging nightmares I mentioned earlier? They’re basically extinct now. When a test fails, Test Replay captures everything. And I mean everything. Every click, every hover, every network request, every DOM change it’s all there, recorded and ready to be analyzed.

You can literally watch your test execution step by step, like you’re sitting right next to the browser as it runs. You can see exactly where things went wrong, what the page looked like at that moment, and what data was flowing through your application.

Test Analytics: Your Personal Test Performance Detective

But Test Replay is just the tip of the iceberg. Cypress Cloud’s Test Analytics dashboard has become our command-center for test optimization. Here’s where things get really interesting.

The Slowest Tests view is pure gold. It shows you exactly which tests are dragging down your entire suite. We discovered that three specific tests were accounting for nearly 40% of our total execution time! Once we optimized those, we shaved off another couple of minutes from our already improved 7-minute runtime.

The Failure Reasons analytics helped us identify patterns we never would have caught manually. Turns out, we had several tests failing due to timing issues that only happened when running in parallel. The dashboard made it crystal clear which tests were problematic and why.

Flaky Test Detection: No More “It Works on My Machine”

Here’s something that used to drive us absolutely crazy: flaky tests. You know, those tests that pass 90% of the time and then randomly fail, usually right before an important release.

Cypress Cloud’s Flaky Test Detection is like having a data scientist dedicated to analyzing your test stability. It tracks your test results over time and flags tests that show inconsistent behavior. We can now see exactly how flaky a test is (like “passes 85% of the time”) and prioritize which ones to fix first.

The best part? It gives you insights into what might be causing the flakiness. Network timeouts? Element loading issues? Race conditions? The data helps you pinpoint the root cause instead of just crossing your fingers and hoping for the best.

Cypress Cloud AI: The Future is Here

And then there’s the newest addition that honestly feels like magic: Cypress Cloud AI. When a test fails, it doesn’t just show you what happened it analyzes the failure and suggests what might have gone wrong.

I’m talking about actual AI-powered suggestions like “This test appears to be failing due to a network timeout. Consider increasing the timeout or mocking this network request.” It’s like having a senior QA engineer looking over your shoulder, except this one never gets tired or takes coffee breaks.

The level of detail you get across all these features is incredible. Network timings, console logs, screenshots at every step it’s like having X-ray vision for your tests, but with a smart assistant helping you interpret what you’re seeing.

The Real-World Impact: Beyond Just Speed

Sure, going from 1 hour to 7 minutes is impressive, but the real benefits go much deeper:

Developer Happiness: Our team actually looks forward to running tests now. No more dreading that pre-deployment test run.

Faster Feedback Loops: We can iterate much quicker. Push a fix, wait 7 minutes, know if it works. The faster feedback makes us more confident and more productive.

Better Test Coverage: When tests run quickly, you’re more likely to write more of them. We’ve actually expanded our test coverage because the pain of long execution times is gone.

Easier Onboarding: New team members can understand our test failures quickly thanks to Test Replay. No more spending hours explaining “what probably went wrong.”

Predictable Releases: With reliable, fast tests and amazing debugging tools, our releases became much more predictable and less stressful.

The Numbers Don’t Lie

Let me put this in perspective with some real numbers:

Test execution time: From ~60 minutes to 7 minutes (88% reduction)
Monthly test results: 44,000+ tests handled smoothly
Debugging time: Reduced by approximately 70% thanks to Test Replay
Developer productivity: Immeasurably better (seriously, the mood in our standups improved!)

What We Learned Along the Way

It’s Not Just About the Tools

While Cypress Cloud provided the technical foundation for our improvement, we learned that success also required some process changes:

Embrace parallelization thinking: We had to restructure some tests that were inadvertently dependent on each other.
Invest in good test data management: With parallel execution, you need to be more careful about test data isolation.
Monitor and optimize continuously: The analytics provided by Cypress Cloud help us continuously improve our test suite.

The ROI is Real

Yes, Cypress Cloud is a paid service, but the time savings alone justify the cost. When you factor in developer productivity, faster release cycles, and reduced debugging time, it’s honestly a no-brainer.

Looking Forward

Moving to Cypress Cloud wasn’t just a technical upgrade — it was a complete transformation of how we approach testing. We went from viewing tests as a necessary evil to treating them as a competitive advantage.

If you’re sitting there reading this while waiting for your own slow test suite to finish, or if you’re tired of spending hours debugging mysterious test failures, I can’t recommend Cypress Cloud enough. The combination of Smart Test Orchestration, parallelization, and Test Replay creates a testing experience that’s not just faster, but genuinely enjoyable.

Trust me, your experience will thank me!

Have you made the switch to Cypress Cloud, or are you still on the fence? I’d love to hear about your testing experiences in the comments below. And if you decide to give Cypress Cloud a try, let me know how it goes, I’m always excited to hear about teams escaping the slow-test nightmare!

Stop Writing Messy Cypress Tests: This Boilerplate Plugin Saves Your Sanity

S Chathuranga Jayasinghe — Sat, 07 Jun 2025 17:29:33 +0000

You know that feeling when you open a Cypress test file and see selectors scattered everywhere like confetti? Yeah, me too. It's painful.

After dealing with this mess for way too long, I created cypress-bootstrap to bring some order to the chaos. And honestly? It will change everything about how you write tests.

The Problem We All Face

Let's be real here. Most Cypress tests look like this disaster if you write as raw code:

describe('Some test', () => {
  it('does something', () => {
    cy.get('[data-test="username"]').type('user');
    cy.get('[data-test="password"]').type('pass');
    cy.get('[data-test="login-button"]').click();
    cy.get('.inventory_item').should('have.length.greaterThan', 0);
    cy.get('#react-burger-menu-btn').click();
    cy.get('#logout_sidebar_link').click();
  });
});

What happens when that username selector changes? You hunt through 50 test files to update it. Fun times, right?

The Role Model: cypress-bootstrap

This plugin brings the Page Object Model (POM) to Cypress in the cleanest way possible. No complicated setup, no fancy configurations. Just clean, organized code that actually makes sense.

Here's the same test with cypress-bootstrap way:

import LoginPage from '../../pages/LoginPage';
import InventoryPage from "../../pages/InventoryPage";

describe('Inventory Page Test Suite', () => {
    it('should display products in the inventory page', () => {
        InventoryPage.checkPageURL(InventoryPage.url);
        InventoryPage.title().should('be.visible');
        InventoryPage.inventoryItems().should('have.length.greaterThan', 0);
    });

    it('should add specific item to cart', () => {
        InventoryPage.inventoryItem('Sauce Labs Backpack').should('be.visible');
        InventoryPage.addToCartButton('Sauce Labs Backpack').click();
        InventoryPage.shoppingCartButton().should('contain', '1');
    });

    it('should display hamburger menu functionality', () => {
        InventoryPage.hamburgerMenuButton().should('be.visible').click();
        InventoryPage.sideMenu.overlay().should('be.visible');
        InventoryPage.sideMenu.aboutButton().should('be.visible');
        InventoryPage.sideMenu.logOutButton().should('be.visible');
        InventoryPage.sideMenu.closeButton().should('be.visible').click();
        InventoryPage.sideMenu.overlay().should('not.be.visible');
    });
});

See the difference? You can actually read what the test is doing without deciphering cryptic selectors.

The Secret Sauce: Smart Locator Design

Here's where it gets really interesting. Let's look at how the page object is structured:

import { BasePage } from '../testbase/BasePage';

class InventoryPage extends BasePage {
  url = '/inventory.html';
  title = () => cy.get('[data-test="title"]');
  hamburgerMenuButton = () => cy.get('#react-burger-menu-btn');
  filterButton = () => cy.get('.select_container');
  filterSelector = () => cy.get('[data-test="product-sort-container"]');
  activeFilterOption = () => cy.get('[data-test="active-option"]');
  shoppingCartButton = () => cy.get('[data-test="shopping-cart-link"]');
  inventoryItems = () => cy.get('[data-test="inventory-item"]');
  inventoryItem = (name: string) => cy.get('[data-test="inventory-item-name"]').contains(name);
  inventoryItemNameLabel = () => cy.get('[data-test="inventory-item-name"]');
  inventoryItemDescription = (itemName: string) =>
    cy
      .get('[data-test="inventory-item-name"]')
      .contains(itemName)
      .closest('div[data-test="inventory-item-desc"]');
  inventoryItemPrice = (itemName: string) =>
    cy
      .get('[data-test="inventory-item-name"]')
      .contains(itemName)
      .closest('div[data-test="inventory-item-price"]');
  addToCartButton = (itemName: string) =>
    cy
      .get('[data-test="inventory-item-name"]')
      .contains(itemName)
      .closest('div[data-test*="add-to-cart-sauce-labs-"]');
  sideMenu = {
    overlay: () => cy.get('.bm-menu'),
    closeButton: () => cy.get('#react-burger-cross-btn'),
    allItemsButton: () => cy.get('[data-test="inventory-sidebar-link"]'),
    aboutButton: () => cy.get('[data-test="about-sidebar-link"]'),
    logOutButton: () => cy.get('[data-test="logout-sidebar-link"]'),
    resetAppStateButton: () => cy.get('[data-test="reset-sidebar-link"]'),
  };
}
export default new InventoryPage();

Notice something special here? Every locator is defined as an arrow function. This isn't just a style choice — it's actually crucial for how Cypress works.

Why Arrow Functions Are Your Best Friend

Here's the thing about Cypress: it's all about that command queue. When you define locators as arrow functions like title = () => cy.get('[data-test="title"]'), you're not executing the command immediately. You're creating a function that returns a Cypress command when called.

This means:

Lazy evaluation: The element lookup happens when you call the function, not when you define it
Fresh queries: Each time you call InventoryPage.title(), you get a fresh query to the DOM
No stale references: You never have to worry about elements that were found earlier but changed

Trust me, I learned this the hard way. My first attempt at this plugin used direct assignments, and it was a nightmare of stale element references.

Dynamic Locators: The Game Changer

But here's where things get really cool. Look at this locator:

inventoryItem = (name: string) => cy.get('[data-test="inventory-item-name"]').contains(name);

This is a dynamic locator. Instead of hardcoding which inventory item you want or using replace statements in the test script, you can pass the name as a parameter. So in your test, you can do:

InventoryPage.inventoryItem('Sauce Labs Backpack').should('be.visible');
InventoryPage.inventoryItem('Sauce Labs Bike Light').click();

Same locator function, different items. No more copy-pasting selectors for every single product in your inventory.

And it gets even better with complex dynamic locators:

inventoryItemPrice = (itemName: string) =>
  cy
    .get('[data-test="inventory-item-name"]')
    .contains(itemName)
    .closest('div[data-test="inventory-item-price"]');

This locator finds a specific item by name, then navigates to its price element. One function, endless possibilities.

The Singleton Pattern Magic

Here's where the architecture really shines. The plugin uses the Singleton design pattern, but not in the way you might expect.

Instead of the traditional constructor approach, your page objects extend a base class and get exported as pre-instantiated singletons:

export default new InventoryPage(); // This is the magic line

That last line? That's your singleton right there.

Why Singleton is Perfect Here

The Singleton pattern solves several problems that are unique to Cypress testing:

Memory efficiency: You get exactly one instance of each page object across your entire test suite. No matter how many times you import InventoryPage, you're always working with the same instance.
Consistent state: Since it's the same instance everywhere, you don't have weird issues with different instances having different behaviors.
Clean imports: You just import and use. No new InventoryPage() scattered throughout your tests.
Shared functionality: All your page objects can extend BasePage and inherit common methods while maintaining their singleton nature.

Organizing Complex UI Components

The framework really shines when dealing with complex UI components. You can organize them as nested objects:

sideMenu = {
  overlay: () => cy.get('.bm-menu'),
  closeButton: () => cy.get('#react-burger-cross-btn'),
  allItemsButton: () => cy.get('[data-test="inventory-sidebar-link"]'),
  aboutButton: () => cy.get('[data-test="about-sidebar-link"]'),
  logOutButton: () => cy.get('[data-test="logout-sidebar-link"]'),
  resetAppStateButton: () => cy.get('[data-test="reset-sidebar-link"]'),
};

Now your tests can access complex UI elements in a logical way: InventoryPage.sideMenu.logOutButton() or InventoryPage.sideMenu.closeButton().

This organization makes your tests incredibly readable. Anyone on your team can look at the test and immediately understand what's happening.

The Readability Game-Changer

Let's talk about readability because this is where the framework really pays off. Your tests become self-documenting. Look at this test:

it('should add specific item to cart', () => {
    InventoryPage.inventoryItem('Sauce Labs Backpack').should('be.visible');
    InventoryPage.addToCartButton('Sauce Labs Backpack').click();
    InventoryPage.shoppingCartButton().should('contain', '1');
});

You don't need comments. The code tells the story: find the backpack, click its add to cart button, verify the cart shows 1 item.

Compare that to selector soup, and there's no contest.

Real-World Benefits You'll Actually Notice

Maintenance becomes painless: When a selector changes, you update it in one place. Done.
Dynamic testing gets easy: Want to test 20 different products? Use the same dynamic locator with different parameters.
New team members onboard faster: They can read and understand your tests without playing "guess the selector."
Tests become reusable: Common actions and element interactions get written once and used everywhere.
Debugging gets easier: When a test fails, you know exactly which page object method to check.
Code reviews become productive: Reviewers focus on test logic instead of deciphering what selectors do.

Getting Started Takes 2 Minutes

First, initiate a new Node.js project if you haven't already:

npm init -y

Then install the package:

npm install cypress-bootstrap

Here's the magic part — run the setup script and let it do all the heavy lifting:

# Option 1: Run the setup script directly
npx cypress-bootstrap-setup

# Option 2: Use the npm script
npm run setup

That's it! The setup script automatically creates your entire folder structure, copies all configuration files, and installs dependencies. You'll get:

├── cypress/
│   ├── pages/           # Your page objects go here
│   ├── tests/ui/        # Your test files
│   ├── testbase/        # Base classes
│   ├── testdata/        # Test data JSON files
│   ├── support/         # Cypress support files
│   └── reports/         # Test reports
├── cypress.config.ts    # Main Cypress config
├── .prettierrc          # Code formatting rules
└── package.json         # Updated with all the scripts you need

The framework even sets up Prettier and Husky for automatic code formatting on commits. No more arguing about semicolons with your team!

NOTE: This will include some execution-ready template test cases when you install and setup. Give it a run, study them and follow the style ❤

The Bottom Line

I was tired of messy, unmaintainable tests. I came up with this framework and I saw many people writing messy Cypress tests. So I though I should share the way I work with Cypress ❤

The Singleton pattern combined with smart locator design and the Page Object Model creates a testing framework that's actually enjoyable to work with. Your tests become readable, maintainable, and reliable. Dynamic locators mean you can test complex scenarios without writing repetitive code.

Your team can onboard faster and contribute more effectively. And you spend less time hunting down broken selectors and more time building features.

Try it in your next project. I think you'll be surprised at how much cleaner your test suite becomes. And trust me, your future self will thank you when you need to test that entire product catalog without writing 50 different locators.

Highly appreciate your thoughts about this in the comment section below..

Stop Your Users From Cringing: How to Add Grammar and Spell-Check to Your Cypress Tests

S Chathuranga Jayasinghe — Sat, 31 May 2025 16:09:48 +0000

You know that feeling when you're browsing a website and suddenly hit a glaring typo? It's like nails on a chalkboard, right? Your users feel the same way. But here's the thing – as developers, we're so focused on making sure our buttons click and our forms submit that we sometimes forget about the words themselves.

I learned this the hard way when a client called me up, slightly panicked, because their brand new marketing page had "recieve" instead of "receive" plastered across the hero section. It had been live for three days. Three whole days of potential customers seeing that typo.

That's when I discovered the beautiful marriage of Cypress and LanguageTool API – a combination that'll save you from those cringe-worthy moments and keep your content looking professional.

Why LanguageTool + Cypress is a Match Made in Heaven

LanguageTool isn't just another spell checker. It's like having that really smart friend who catches your grammar mistakes AND explains why they're wrong. It supports over 20 languages, catches context-sensitive errors, and has a generous free tier that's perfect for testing.

Cypress, on the other hand, is already crawling through your pages, clicking buttons, and checking functionality. Why not have it proofread while it's there?

Setting Up Your Grammar Police

First things first – let's talk about the LanguageTool API. The good news? There's a free public API at https://api.languagetool.org/v2/check that doesn't require an API key for basic usage. The limits are generous for testing: 20 requests per IP per minute and up to 20KB of text per request.

Installing the Dependencies

bashnpm install --save-dev axios

That's it! We'll use axios to make our API calls, but you could just as easily use fetch or your HTTP client of choice.

Creating Your Custom Cypress Command

Here's where the magic happens. We're going to create a custom Cypress command that grabs text from your page and sends it to LanguageTool for analysis.

Create or update your cypress/support/commands.js file:

javascriptimport axios from 'axios';

Cypress.Commands.add('checkGrammar', (selector, options = {}) => {
  const { 
    language = 'en-US',
    skipWords = []
  } = options;

  cy.get(selector).then(($element) => {
    // Extract text from the element
    const text = $element.text().trim();

    if (!text) {
      cy.log('No text found in element');
      return;
    }

    // Make API call to LanguageTool
    cy.request({
      method: 'POST',
      url: 'https://api.languagetool.org/v2/check',
      form: true,
      body: {
        text: text,
        language: language
      }
    }).then((response) => {
      const errors = response.body.matches;

      if (errors.length > 0) {
        // Filter out words we want to skip (like brand names)
        const filteredErrors = errors.filter(error => {
          const errorText = text.substring(error.offset, error.offset + error.length);
          return !skipWords.some(word => 
            errorText.toLowerCase().includes(word.toLowerCase())
          );
        });

        if (filteredErrors.length > 0) {
          // Create a readable error message
          const errorMessages = filteredErrors.map(error => {
            const errorText = text.substring(error.offset, error.offset + error.length);
            return `"${errorText}": ${error.message}`;
          });

          cy.log('Grammar/Spelling errors found:');
          errorMessages.forEach(msg => cy.log(msg));

          // Fail the test if errors are found
          throw new Error(`Grammar/Spelling errors found:\n${errorMessages.join('\n')}`);
        }
      }

      cy.log(`Text checked: "${text.substring(0, 50)}..." - No errors found`);
    });
  });
});

No More API Key Management!

Good news – you don't need to sign up for anything or manage API keys for basic usage. The public LanguageTool API is free and ready to use right out of the box.

Writing Your First Grammar Test

Now for the fun part – let's write a test that actually uses this new superpower:

javascriptdescribe('Content Quality Tests', () => {
  it('should have error-free content on the homepage', () => {
    cy.visit('/');

    // Check the main heading
    cy.checkGrammar('h1');

    // Check the hero description
    cy.checkGrammar('[data-testid="hero-description"]');

    // Check all paragraph text, but skip our brand name "TechnoWiz"
    cy.checkGrammar('main p', { 
      skipWords: ['TechnoWiz', 'API'] 
    });
  });

  it('should validate blog post content', () => {
    cy.visit('/blog/latest-post');

    // Check the title and content
    cy.checkGrammar('article h1');
    cy.checkGrammar('article .content', {
      skipWords: ['JavaScript', 'React', 'npm']
    });
  });
});

Getting Fancy: Batch Checking Multiple Elements

Here's a neat trick I discovered after running this on a content-heavy site. Instead of making individual API calls for each element, you can batch them together:

javascriptCypress.Commands.add('checkMultipleElements', (selectors, options = {}) => {
  const texts = [];
  const elementMap = new Map();

  // Collect all text first
  selectors.forEach(selector => {
    cy.get(selector).then(($element) => {
      const text = $element.text().trim();
      if (text) {
        elementMap.set(texts.length, selector);
        texts.push(text);
      }
    });
  });

  // Then check all at once
  cy.then(() => {
    if (texts.length === 0) return;

    const combinedText = texts.join('\n\n');

    cy.request({
      method: 'POST',
      url: 'https://api.languagetool.org/v2/check',
      form: true,
      body: {
        text: combinedText,
        language: options.language || 'en-US'
      }
    }).then((response) => {
      const errors = response.body.matches;

      if (errors.length > 0) {
        // Map errors back to their original elements
        const errorMessages = errors.map(error => {
          const errorText = combinedText.substring(error.offset, error.offset + error.length);
          return `"${errorText}": ${error.message}`;
        });

        throw new Error(`Content errors found:\n${errorMessages.join('\n')}`);
      }
    });
  });
});

Real-World Tips and Gotchas

After using this setup on several projects, here are some lessons I've learned:

Watch Your API Limits: The free public API allows 20 requests per IP per minute and up to 20KB of text per request. That's actually quite generous for testing, but keep an eye on your usage if you're running lots of tests.

Handle Dynamic Content: If your content changes frequently (like user-generated content), you might want to be more selective about what you check. Focus on static content like headers, navigation, and marketing copy.

Brand Names and Technical Terms: Always use the skipWords option for your brand names, technical jargon, and industry-specific terms that LanguageTool might flag incorrectly.

Different Languages: If you're building a multilingual site, you can easily switch the language parameter:

javascriptcy.checkGrammar('.spanish-content', { language: 'es' });
cy.checkGrammar('.french-content', { language: 'fr' });

Making It Part of Your CI/CD Pipeline

Here's where this really shines – imagine catching content errors before they go live. Add this to your CI pipeline:

javascript// In your cypress/e2e/content-quality.cy.js
describe('Pre-deployment Content Check', () => {
  const criticalPages = [
    '/',
    '/pricing',
    '/about',
    '/contact'
  ];

  criticalPages.forEach(page => {
    it(`should have quality content on ${page}`, () => {
      cy.visit(page);

      // Check all headings and main content
      cy.checkGrammar('h1, h2, h3');
      cy.checkGrammar('main p, .content p');
      cy.checkGrammar('[class*="hero"], [class*="cta"]');
    });
  });
});

The Bottom Line

Look, perfect grammar won't make your app faster or more secure, but it will make your users trust you more. And trust, my friend, is everything in business.

This Cypress + LanguageTool combo has saved me from more embarrassing typos than I care to admit. It's like having a really pedantic proofreader who never gets tired and works for free (well, mostly free).

The best part? Once you've set it up, it just runs. Every time you deploy, every time you test, your content gets a quality check. Your marketing team will love you, your users will respect you, and you'll sleep better knowing that "recieve" will never make it to production again.

So go ahead, give your content the same attention you give your code. Your future self (and your users) will thank you for it.

Let’s Sync Cypress Tests with Azure Like a Pro (No More Manual Linking!)

S Chathuranga Jayasinghe — Mon, 19 May 2025 18:26:03 +0000

Cypress tests + Azure Test Plans + a ton of manual clicks & types? Nah. Let’s automate that boring part..

You know this drill:

You write some beautiful Cypress tests, your coverage is solid, you push everything to your repo and then…
You have to manually go to Azure Test Plans, update test cases.
Mark them as Automated.
Then again come back to your Cypress script and update the each test title with the test case Id.

Ugh! I’ve been there. Too many times! So I decided to fix it!

Introducing my new Cypress plugin: cypress-azure-sync

This tiny yet mighty plugin lets you sync your Cypress test cases with Azure Test Plans like a breeze, no more tedious updates, no more forgetting to change the test status, and definitely no more grumbling at the screen.

Let me walk you through what it does, how it works, and how you can get started in just a few minutes!

What does `cypress-azure-sync` do?

Simply put, it reads your Cypress spec files, extracts the test case IDs based on a pattern you define (like TC1234or [1234]), and automatically updates your Azure Test Plan test cases:

Marks them as Automated if they’re not.
If the Cypress test case title does not have a test case id, it creates a new test case in Azure Test Plans:

- In the defined Area Path.- With the test case title.

- Adding the tags mentioned in the test case too.
If a new test case created, retrieves the test case id and updates the Cypress test case title with the id in the spec file.

Magic? Nah. Just good automation ❤

⚠️ Note: This plugin currently does not publish test results to Azure Test Plans. That feature is on the roadmap!

How does it identify and map tests?

The plugin uses a simple naming convention. In your Cypress test case title, include the Azure test case ID in the following format:

it('1234: should successfully login with valid credentials', { tags: ['tagOne', 'tagTwo'] }, () => {
  // test steps
});

Quick Setup — How to use it in your project

Install the Plugin

Install the plugin using a simple command: npm install cypress-azure-sync --save-dev

Configure the Plugin

As usual in Cypress, you need to configure the plugin in the cypress.config.ts file as follows:

import { defineConfig } from 'cypress';
import { initAzureSync } from 'cypress-azure-sync';

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      return initAzureSync()(on, config);
    },
  },
});

Define the Azure Configurations

You can define the Azure Configurations in different ways. For local executions, you can add a .env file to define the configurations as below and add it to .gitignore file.

# Azure DevOps Configuration
AZURE_DEVOPS_ORG=YOUR_ORG_NAME
AZURE_DEVOPS_PROJECT=YOUR_PROJECT_NAME
AZURE_DEVOPS_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
AZURE_DEVOPS_API_VERSION=7.0
AZURE_AUTOMATION_STATE_FIELD=Custom.AutomationState

# Test Plan Configuration
AZURE_TEST_PLAN_ID=YOUR_TEST_PLAN_ID
AZURE_TEST_SUITE_ID=YOUR_TEST_SUITE_ID

# Cypress Configuration
CYPRESS_SPEC_PATTERN=cypress/e2e/**/*.spec.ts

Defining the Test Plan Configuration is optional here, you will know why below. The other ways of configuring this can be found in the plugin page here.

Set the MetaData on Spec Files

If we being rational, in most cases the tests in one Spec file should go to one Area Path in Azure Test Plans and another set of tests in another Spec should go some other Area Path. So the plugin uses metadata to map this accordingly.

On each of your Spec file, define the Test Plan ID, Test Suite ID and Area Path as a JSDoc comment (or as a regular comment, i prefer this).

/**
 * TestPlanId = 170880
 * TestSuiteId = 170921
 * AreaPath = 'Project XYZ\Application XYZ\Cache Service'
 */

All done! Now it’s time to see the magic happen (sorry not the magic! see the automation in action!)..

Execute the Sync Process

There are two ways execute the Sync. You can decide what you prefer!

Use a Hook: You can add this simple command in a before() or after() hook (I prefer in a before() hook defined in the commands.ts file 😉):

after(() => {
    cy.task("syncWithAzure");
});

2. Execute a NPX Command (CLI):

You can also run npx cypress-azure-sync in your terminal/command-prompt to start the Sync.

Why I Built This Plugin (a mini behind-the-scenes)

So here’s the story…

I was happily cruising along with Cypress and Azure DevOps pipelines, until I hit a familiar bump — one that always made me sigh:

“Why is there no easy way to sync test cases & metadata in Azure?”

Then came the rock. One of our API projects landed with 500+ test cases. Yep, you read that right. And guess what? All of them needed to be created in Azure Test Plans. Manually.

Not just that — after creating them, we had to go back and update every test script to include the corresponding Azure Test Case ID. That whole thing screamed “manual pain”.

That’s when I knew enough was enough. I rolled up my sleeves and started building a plugin that would take care of the annoying bits: mapping, syncing, updating metadata. Basically, everything that wastes our time and energy.

And thus, cypress-azure-sync was born. Built from frustration, refined by passion. I hope it saves you the hours it’s already saving me! Now it’s open-source, and I hope it helps you too!

What’s Next for the Plugin?

Here’s what I have in mind:

Publishing test results directly to Azure Test Runs (yep, it’s coming! Hooray!!!)
Support for multiple test case ID formats in a single test title
Handle custom fields in Azure test cases

Your ideas are welcome too! Just drop a comment below!

So go ahead, give cypress-azure-sync a try. Let magic do the heavy lifting — while you focus on writing awesome tests.

Until next time, keep Testing Smart!

Why Linking your Test Scripts with the Test Management Tool is a Game-Changer!

S Chathuranga Jayasinghe — Sun, 18 May 2025 10:53:25 +0000

Let’s talk about something that often gets overlooked in the hustle of automation, syncing your automated test scripts with your test management system!

You might think, “Eh, my tests run fine. I’ve got my green ticks on the pipeline. Why bother?”

Well, hold onto that thought, because today I’m going to show you why this link is not just a nice-to-have but a superpower for your test automation efforts!

What do I mean by Linking?

At its core, linking means there’s a direct connection between the test cases you’ve written in your test management tool (like TestRail, Azure Test Plans, XRay, etc.) and the actual automation scripts you’ve coded up in your framework (Cypress, Playwright, Selenium — you name it).

This sync can be manual (you link test IDs in your scripts) or fully automated. What do I mean by automated:

Your test report magically updates the test case in the management system with results
Execution history is maintained
Even the “Test Automation Status” is updated
Creates the missing test cases in the test management tool which automated in your scripts

Sounds sweet, right?

Why Is It So Important?

You know that moment during a sprint review when someone asks,

“Hey, are all the acceptance criteria for this feature automated?”

Or worse:

“Why did this test fail? Was it even tested in the first place?”

Without a proper link between your test management system and your scripts, you’re stuck searching through commit histories, spec files, and pipelines. Not fun!!!

But with a well-established link?

You instantly know which test case maps to which automated script.
You can track test coverage accurately.
You bring full traceability into the QA lifecycle.

Benefits of Having the Link

Alright, let me hit you with the real juice — the benefits.

1. Traceability from Requirement to Automation:
You can trace back from a Jira ticket -> to the test case -> to the automated script -> to the pipeline result. This full-circle view is gold when debugging, reporting, or auditing.

2. Real-Time Test Reporting:
Imagine your nightly CI/CD run finishes, and boom! your test case statuses are updated automatically in the management tool. PMs and stakeholders can view the latest status without bugging you on Slack.

3. Better Test Planning:
You get a bird’s-eye view of what’s automated, what’s still manual, and what’s not covered at all. This makes sprint planning and regression suite grooming way easier.

4. Smarter CI/CD Pipelines:
With test case IDs linked, you can selectively run only impacted tests based on what’s changed.

5. Effortless Audits and Compliance:
In domains like finance or healthcare, traceability isn’t just a bonus, it’s a requirement. Having this sync helps you sleep better during audits.

6. Team Collaboration Superpowers:
Your non-technical team members, like BAs or Product Owners can actually understand which scenarios are covered by automation without diving into code. That’s a win for everyone? ❤

So… How Do You Set This Up?

Good news — you don’t have to manually update test case statuses or keep a spreadsheet of which test case is automated (ugh!). Most modern test management systems like TestRail, Azure Test Plans, and Xray come with powerful APIs that let you do all this in a breeze!

Let’s break it down:

Test Rail

TestRail has a well-documented REST API that lets you do all the cool stuff — fetch test cases, post test results, update automation status, and more.

Here’s a simple flow:

Include the test case ID in your test name or metadata (like [C1234]).
After your tests run, parse the results and extract test case IDs.
Use the TestRail API to:

Mark test case as automated.
Push the result of each test execution.

🔗 TestRail API Documentation

Azure Test Plans

Azure DevOps (Test Plans) exposes a robust API under the TestManagement namespace. With it, you can:

Search for test cases using queries or IDs
Update test case fields (e.g., Automation Status)
Create test runs and push results
Link your automation to a test case using “Automated test name”

Here’s what a typical setup looks like:

Parse your test reports (JUnit or custom).
Match test case IDs in the name or tags.
Call Azure DevOps REST API to update:

AutomationStatus to “Automated”
AutomatedTestName to your test script name
Push results into a test run

🔗 Azure DevOps Test API Docs

🔌 TestRail Plugins & Integrations

Xray (Jira)

Xray works beautifully with REST APIs and even supports GraphQL. It’s great for syncing automation results directly into Jira.

With Xray API, you can:

Search and update test cases
Submit results via the “Import Execution Results” endpoint
Link tests to test executions automatically

Here’s the flow:

Add your test issue key (e.g., XRAY-123) in your test title or tag.
Generate a test result file (Xray supports JUnit, Cucumber, etc.).
Use the API to:

Import the result
Create a test execution issue
Link the execution to your test plan

🔗 Xray REST API Docs

🧩 Xray also has official CI/CD plugins for Jenkins, GitHub Actions, and more!

Note: I’m currently working on some Cypress plugins that makes this even easier, automatically parsing test scripts and updating the automation metadata in Azure Test Plans and creating Test Cases. Stay tuned if you’re into that kinda thing..

Final Thoughts

Test automation isn’t just about writing code and getting green check marks. It’s about creating visibility, trust, and confidence in the process.

By linking your test scripts with your test management system, you’re not just making your life easier, you’re building a bridge that connects testers, developers, product owners, and stakeholders. That bridge is what enables real quality engineering!

Have you already set this up in your team? Or struggling with how to start? Drop me a comment or connect with me on LinkedIn — let’s chat!

Until next time, Happy Testing!

Unlocking AI Superpowers in Test Automation: It All Starts with Your Framework

S Chathuranga Jayasinghe — Sun, 11 May 2025 19:32:05 +0000

Tried using AI agents to generate tests but ended up frustrated and ready to give up? Hold on — this might just change the game for you. Keep reading until the End!

Let’s talk about something that’s been buzzing for a while now, AI in test automation. Yep, it’s cool, powerful, and kind of magical when it works! But here’s the catch: most people assume AI is some all-knowing oracle that just writes perfect test scripts if you ask nicely.

Spoiler alert: It doesn’t‼️

In my experience, the real magic happens only when you pair AI with a well-structured test automation framework and a proper prompt. That’s when things start to click. So let’s unpack that a bit.

The AI Isn’t the Sole Hero Here

I’ve played around with AI agents like ChatGPT, GitHub Copilot, JetBrains Junie and a few custom LLM setups to help generate tests. And I’ll be blunt: the output varies wildly depending on ‘from-where’ you prompt. Which means the environment where you are in. Which means in this case, specifically, your test framework.

Let me explain..

If your test automation framework is a chaotic mess with test files dumped all over the place, no clear naming convention, or structure — AI has no idea what to do with that. It’ll guess. And most of the time, it guesses wrong.

But when the framework follows a clear architecture, like the Page Object Model (POM), or even better, a layered design with base test classes, reusable commands, and folder separation for different test types — AI can start making sense of it.

It’s kind of like giving the AI a map. Without it, it’s lost in the woods. With it? It can run a marathon blindfolded.

Share the Blueprint: Feed the Architecture to AI

Here’s something that works like a charm..

Before asking AI to generate any tests, I give it a basic overview of my framework architecture. Not a 20-page documentation dump, but something like:

- /tests: test specs go here
- /pages: all page objects live here
- /utils: helper functions
- We use TypeScript + Cypress

Note: Above is just a hint on how to give the information

Then I’ll follow up with a simple example test and page object file, so the AI can get the “pattern.”

After this little orientation tour, the AI becomes surprisingly accurate. It knows where to place new tests, how to reference page objects, how hooks work, and even when to reuse utility functions.

It’s like onboarding a new teammate. You don’t just throw them into the deep end, you show them around first.

The Prompt Is Your Steering Wheel

Okay, so now your framework is neat and structured, and you’ve handed over the blueprint. What’s next?

Prompting.

This part is half art, half science. If you say “Write a login test,” you’ll probably get something generic that may or may not fit your actual setup.

But if you say something like:

“Write a Cypress test in TypeScript to verify the login flow using the Page Object Model. Use the LoginPage class from /pages/LoginPage.ts. The test should check for successful login and redirection to the dashboard.”

Boom! Now you’re talking! ❤

Add test data examples, expected behaviors, or edge cases into your prompt, and AI will often generate tests that are eerily spot-on!

Real-World Result? AI Writes, You Refine

When the framework is well-organized and you guide the AI properly, the tests it generates aren’t just dummy scripts. They’re often 80–90% production-ready.

You still need to polish a few edges — naming, assertion tweaks, maybe a bit of test data handling — but the base is there. And that’s a massive time-saver.

I’ve even had AI generate test cases for new features on the same day they were developed — saving hours of manual work and letting me focus on edge case validation and exploratory testing instead.

Make AI Work with You, Not for You!

So yeah, AI can be a great assistant in test automation, but only if you do your part first:

Keep your test framework clean, modular, and structured
Share your framework structure with the AI agent
Write prompts that are clear, detailed, and contextual

The AI isn’t your silver bullet. But with the right setup, it’s a serious productivity booster!

Gift for the Finishers!

If you’ve made it this far, thank you! As a little treat, I’ve got something for you.

I recently worked on a Cypress boilerplate framework tailored for beginners and teams who want a clean, scalable starting point. It follows the Page Object Model, is structured for scalability & maintainability. And this will play well with AI agents when generating tests.

I’ve bundled it all up and published it as an npm package so you can kickstart your next project with ease.

Grab it here: cypress-bootstrap

Give it a spin, and let me know what you think!

Why JetBrains Junie is the Best AI Agent I’ve Ever Used So Far

S Chathuranga Jayasinghe — Sat, 03 May 2025 14:58:28 +0000

I’ve been there using lot of different tools with AI Agents: Trae IDE Builder, Cursor, JetBrains Junie.. And this is my opinion on them :)

What is Junie?

Junie isn’t just another AI assistant that suggests code snippets. Launched in January 2025 and now production-ready, Junie represents a leap from reactive code suggestions to proactive task execution. Unlike traditional tools like GitHub Copilot, which focus on autocompletion, Junie acts as a collaborative agent capable of planning, executing, and debugging multi-step workflows — saving hours of manual effort! It’s an autonomous coding agent that can take on entire tasks, from understanding your project structure to writing code, running tests, and even refactoring, all within your IDE.

As a tester who’s tested numerous AI tools, I found Junie’s ability to handle tasks like generating CRUD operations, writing tests, and even self-correcting code to be unparalleled. Let’s dive into what makes Junie a game-changer.

Junie’s Core Features: Why It Stands Out

Autonomous Task Execution

Junie doesn’t just suggest code — it executes tasks end-to-end. For example, when asked to “Implement CRUD operations for a Spring Boot app with Thymeleaf UI”. Junie:

Analyzes the project structure and dependencies.
Generates JPA entities, repositories, and controllers.
Writes integration tests and runs them automatically.

To do all the above, Junie first creates a descriptive plan to approach all the thing that needs to be done. It also documents & creates check-list of everything. Then start working on them one by one!

And most importantly, writes tests and run the tests after implementation. That’s not all, if the tests fail it keeps on trying to fix the application code recursively until all the tests are green!

Context-Aware Problem Solving

Junie leverages deep IDE integration to understand project-specific context, including coding guidelines and file structures. Developers can customize its behavior using a .junie/guidelines.md file, ensuring alignment with team standards (e.g., test framework preferences or directory conventions)

Human-in-the-Loop Control

While Junie operates autonomously with the “Brave mode”, still it maintains transparency:

Propose a step-by-step plan for tasks.
Require explicit approval for risky actions

Performance Metrics

According to the SWEBench Verified benchmark (500+ tasks), Junie solves 53.6% of tasks on the first attempt, a promising figure for early-stage AI agents.

Real-World Use Cases

Case 1: Building a Spring Boot Web App

In a tutorial for IntelliJ IDEA, Junie:

Created a Spring Boot project with Maven and Java 21.
Generated a Bookmark JPA entity and repository.
Implemented Thymeleaf templates for CRUD operations.
Wrote and ran integration tests — all within 30 minutes.

Case 2: Self-Correcting Code Errors

During a Django app test, Junie detected a failed compilation, identified missing dependencies, and updated requirements.txt without user intervention. This “Brave Mode” feature (optional) showcases its ability to recover from errors autonomously.

Final Thoughts

Let me start by saying, I’m a big fan of JetBrains IDEs (seriously, who isn’t? ❤). Sure, they come with a price tag, but the developer experience is just unmatched. Now with Junie baked right into the JetBrains ecosystem, things get even better. It goes beyond basic suggestions, Junie handles autonomous tasks inside your IDE so you can spend less time on repetitive coding and more time solving the fun, complex problems.

If you’re aiming to level up your productivity and smooth out your development flow, give Junie a spin, it’s absolutely worth it.

Just one piece of advice: as amazing as AI agents are, they’re still not perfect. So always review what’s generated, treat them like a junior dev with superpowers, not a replacement for your judgment.

How AI is Transforming Software Testing: From Manual to Mindful

S Chathuranga Jayasinghe — Sun, 27 Apr 2025 06:05:14 +0000

👋 It’s time to speak-up about the evolution in Software Testing..

Let’s have a little chat about a revolution that’s been sneaking up on u quietly at first, but now it’s banging on the door with a megaphone. Yes, I’m talking about how Artificial Intelligence is changing the game in software testing.

We’ve come a long way from the days when testing was all about clicking through UI elements manually and filling in endless Excel sheets with “Pass” and “Fail” tags. Now, with AI joining the party, we’re not just automating testing, we’re making it mindful. Let me explain what I mean.

From Click Monkeys to Smart Testers

Remember the term “click monkey”? That was the (unfair) label for testers stuck in repetitive manual testing loops. No shame — we’ve all been there. Writing out hundreds of test cases in test management tools, then executing them step-by-step, release after release. It was exhausting, and frankly, soul-crushing.

Then came automation tools — Selenium, Cypress, Playwright, you name it. Automation brought speed, reliability, and repeatability. But here’s the catch: it still required humans to write and maintain scripts. The minute your UI changed, your tests broke. And fixing them? Often harder than writing new ones.

That’s where AI comes in.
AI in Testing: What It Really Means

When we talk about AI in testing, we’re not just talking about some fancy buzzwords slapped onto a product. Real AI in testing does three core things:

Analyzes patterns
Predicts failures
Learns and adapts

Let’s break this down with real-world examples.

1. Self-Healing Tests: Tests That Fix Themselves

Let’s say you’ve got an automated UI test that clicks a button with the selector #submit-btn. Now imagine your dev team updates the app and that button becomes #submit-now. Boom! your test fails. Traditionally, you’d have to dig into logs, inspect the app, update the selector, and re-run the test.

But with AI-powered self-healing, the script can detect that #submit-now is most likely the updated version of #submit-btn, thanks to context clues like button text, location, or surrounding elements. It adapts and continues execution — without human intervention. Some frameworks (like Testim, Mabl, Functionize, or even plugins for Selenium and Cypress) already do this.

That’s not just automation. That’s automation with intuition. Or at least the AI version of it.

2. Predictive Test Selection: Only Run What Matters

In CI/CD pipelines, we often run the entire test suite regardless of what’s changed. That’s like taking your whole car to the mechanic when all you did was swap out the air freshener.

AI can analyze code changes, map them to relevant tests, and run only the impacted test cases. This technique called Predictive Test Selection or Test Impact Analysis which saves tons of time. Google does this. Facebook does this. And thanks to open-source tools and smart test orchestration platforms (hello, Launchable and GitHub’s ML-powered test selection), we can do it too.

Less noise! Faster pipelines! Happier Devs! ❤

3. Flaky Test Detection: AI is the Therapist for Your Tests

We’ve all been haunted by flaky tests. They fail randomly, pass when re-run, and break our trust in automation. AI tools are now analyzing test behavior over time to detect flaky patterns, things like:

Test passes/fails under similar conditions
Network or timing dependencies
Resource bottlenecks (like memory or CPU spikes)

Once identified, AI can either auto-quarantine the test or suggest fixes. Think of it as an early warning system that tells you, “Hey buddy, test number 54 is emotionally unstable. Might wanna talk to it.”

4. Natural Language Test Generation: Write Tests Like You Talk

Now this one is mind-blowing. Tools like Testim, Katalon, and even ChatGPT-based platforms allow testers to write test cases in plain English, like:

“Log in as admin, go to settings, and verify that dark mode is enabled.”

Then hola! it gets converted into actual automated scripts. Some tools even let you upload product documentation or user stories, and they auto-generate test cases. Yup, AI is now your junior test analyst.

It’s not perfect (yet), but it’s evolving fast and already super handy for fast prototyping or non-technical testers.

5. Visual AI Testing: Seeing is Believing

Traditional visual testing compares pixel by pixel. That means even a 1px shift could fail your test. But AI-powered visual testing (like Applitools Eyes) uses machine learning to understand layouts, context, and intent. It can tell the difference between meaningful changes (like a missing button) and ignorable ones (like a minor padding change).

It’s like giving your tests a pair of smart glasses. They see what really matters.

So, What Happens to Manual Testers?

Now, if you’re wondering whether all this means the end of manual testing — don’t panic.

AI is not replacing testers. It’s replacing repetition.

Manual testers are becoming exploratory thinkers, scenario designers, risk analysts, and yes, AI supervisors. We’ll be guiding the tools, validating the insights, and ensuring quality from a human perspective. That’s what I meant when I said testing is becoming more mindful.

My Take: AI + Testers = Super-powered Quality 🚀

I’ve seen first-hand how AI can reduce noise in pipelines, catch issues earlier, and give teams confidence in their releases. Whether you’re a startup or an enterprise, AI-backed testing can be your best ally when used smartly.

But it’s not plug-and-play magic. You still need a solid foundation, good test design, CI/CD discipline, and team collaboration. AI simply amplifies that.

So next time you’re setting up your test strategy, ask not just what you’re testing, but how intelligently you’re doing it.

Wrapping Up

AI in testing is here to stay and it’s only getting smarter. From self-healing to smart test selection, we’re moving toward a world where testing isn’t just faster, but smarter.

We’re not just shifting left. We’re shifting up, towards intelligent, mindful quality!

AI Code Reviewers: Can They Replace Your Teammates?

S Chathuranga Jayasinghe — Mon, 21 Apr 2025 06:17:07 +0000

Let’s be honest. We’ve all been there waiting for a teammate to finally review our PR while we nervously hover over the refresh button like it’s a game of Flappy Bird. Sometimes, it takes hours. Sometimes, days. And sometimes… it just gets merged without any feedback at all.

Now, imagine this: you open a PR, and within seconds, BOOM! — you get insightful, contextual code review suggestions. Not from your colleague who’s deep in meetings. But from an AI. Yup, GitHub Copilot Code Review is doing just that.

So, What Is GitHub Copilot Code Review?

It’s an AI-powered feature baked into GitHub that reviews your code when you open a pull request. It reads your changes, understands the context (pretty impressively, I might add), and drops inline suggestions and comments. It even tells you why it suggests something, like a real reviewer.

It’s Not Just About Catching Bugs

Here’s what I found surprisingly useful. Copilot doesn’t just act like a nitpicky teammate. It actually helps you GROW.

For instance:
I recently learned about the .closest() method in Cypress thanks to a Copilot Code Review suggestion. I had used cy.get(locator).find() chaining many times where I had to locate an element which is in a haystack without a unique identifier, but never realized I could chain it with .closest() to navigate up the DOM tree before finding something else.

If you too didn’t know about that, here is a simple example:

Back to the topic! It was a small tip, but one I hadn’t come across before and it genuinely improved how I write selectors..

It actually helps you grow. I've had it point out performance improvements, suggest better naming conventions, and even bring up edge cases I hadn't thought about.

You know that feeling when a teammate shares a cool new way of doing something and you’re like, “Oh! I didn’t know that!”. Copilot delivers that vibe, minus the Slack ping.

Apply Suggestions Directly from the PR Page

One of my favorite things? You can apply its suggestions right from the PR interface. No jumping between tools. Just click, commit, and go. It’s a smooth workflow booster. And yes, you can also edit the suggestions before applying them if you want to tweak them your way.

Can It Really Replace Teammates?

Okay, so let’s get to the spicy part.

Can it replace your teammates? Short answer: No!

Long answer: AI code reviewers are incredibly helpful for catching low-hanging fruit, providing consistency, and teaching you a few tricks. But they still can’t replace the full context your teammates bring. Product knowledge, architecture decisions, design trade-offs, that’s still human territory (for now!).

That said, AI reviewers can augment your team. They can take care of the boring stuff, speed up the review loop, and leave humans to focus on the deep stuff. And in that sense, it’s not a replacement, it’s a force multiplier.

What About Other AI Code Review Tools?

While GitHub Copilot Code Review is a standout tool, it’s not the only one in the game. Tools like CodiumAI, AWS CodeWhisperer, DeepCode (now Snyk Code), Tabnine, and ReviewPad are also helping developers get AI-driven insights on their code. Each of them brings something unique to the table, whether it’s test generation, security-focused reviews, or custom rule-based suggestions.

That said, this article is all about Copilot’s review feature, because honestly, it’s super tightly integrated into GitHub and feels natural in everyday workflows.

In Short

GitHub Copilot Code Review is like a supercharged teammate that never sleeps.
It gives smart, contextual suggestions and helps you learn better coding practices.
You can apply changes directly from the PR interface.
It won’t replace your team, but it sure can boost your productivity.

If you’re not already using it, give it a shot. Worst case? You’ll learn something new. Best case? You’ll wonder how you lived without it ❤

Level Up Your Cypress Game: Cypress Smart Tests Plugin

S Chathuranga Jayasinghe — Mon, 31 Mar 2025 05:00:00 +0000

A smart solution for dependant tests, conditional test execution on runtime and individual test-bound hooks and many more..

In the realm of test automation, ensuring that end-to-end tests are both efficient and maintainable is a continuous challenge. While Cypress has revolutionized the way we approach testing, there are scenarios where we wish our tests could be more… SMART!

Introducing the Cypress Smart Tests plugin

The plugin cypress-smart-tests is designed to elevate your test execution by introducing advanced control mechanisms directly into your Cypress tests. This plugin will solve common pain points in E2E test orchestration by:

Letting you define dependencies between tests
Running tests conditionally based on runtime logic
Enabling before/after hooks per test block

Okie dokie! Let’s explore how to install, configure, and use it effectively..

Setup and Configure

First things first, initiate a project and install Cypress. It does not matter whether it is JavaScript or TypeScript. Then install the plugin as a dev dependency:

npm install — save-dev cypress-smart-tests

Whenever you are writing a Spec file, import the helpers to your file:

import { cytest, defineTestDependencies, configure, cyVariables } from 'cypress-smart-tests';

Now, instead of using the usual it() block, use cytest() — a drop-in replacement with smart capabilities ❤

Features

Conditional Test Execution

If you’ve been in the test automation realm for sometime, you already know that you will come across lots of scenarios where you have to execute your test based on various conditions. Either based on environment variables/feature or runtime conditions. Some of these scenarios could be:

test only on mobile viewports
run only if a flag is enabled

It doesn’t matter whatever the condition is, you can define your condition with the cytest() block and execute your test based on the conditions met. Check this out:

Problem solved! 😉 Let’s move on to the next pain-point..

Dependant Tests

Well well well.. I know! The “Best practice is to avoid dependant tests!”, BUT we all know that sometimes — at least rarely we get to situation where we have to write dependant tests. So, this plugin is gonna solve that problem too.

First you have to define your test dependencies like this:

Hold on! Let’s consider kind of a complex scenario. We have 6 tests in our Spec file:

Test2 & Test3 depends on Test 1
Test5 depends only on Test4
Test6 is an independant test

Still you can achieve this with the plugin like this:

When test execution happens, it behaves this way:

If Test1 fails: Execution of the tests Test2 & Test3 will be skipped!
If Test4 fails: Execution of the test Test5 will be skipped!
Test6 will be executed no matter what happens with the other tests

What do we achieve through this? You might be thinking so WHAT? This makes a big difference, if you have dependant tests like this and you execute the tests in the traditional way, you will waste a lot of time! WHY? Because when the parent test fails, the dependant tests will obviously fail because the pre-condition of those are not met! Yet the dependant tests execute (with all the Cypress retries and default waiting times) and waste the time. Time is Gold!

So it’s important to fail-fast or skip-fast ❤ Here is a silly sample code with dependencies and tests:

import { cytest, defineTestDependencies, configure, resetState } from 'cypress-smart-tests';

describe('Cypress Smart Tests Plugin - Dependencies', () => {
    beforeEach(() => {
        resetState();
    });

    context('Simple Dependent Test Execution', () => {
        beforeEach(() => {
            // Configure failFast mode
            configure({ failFast: true });

            // Define dependencies
            defineTestDependencies({
                'Critical Test': ['Subsequent Test 1', 'Subsequent Test 2'],
            });
        });

        cytest('Critical Test', () => {
            // This test will fail
            cy.wrap(false).should('be.true');
        });

        cytest('Subsequent Test 1', () => {
            cy.log('This test should be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });

        cytest('Subsequent Test 2', () => {
            cy.log('This test should also be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });

        cytest('Subsequent Test 3', () => {
            cy.log('This test should not be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });
    });

    context('Complex Dependent Test Execution', () => {
        beforeEach(() => {
            // Define dependencies
            defineTestDependencies({
                'Critical Test': ['Subsequent Test 1', 'Subsequent Test 2'],
                'Other Critical Test': ['Subsequent Test 4'],
            });
        });

        cytest('Critical Test', () => {
            // This test will fail
            cy.wrap(false).should('be.true');
        });

        cytest('Subsequent Test 1', () => {
            cy.log('This test should be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });

        cytest('Subsequent Test 2', () => {
            cy.log('This test should also be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });

        cytest('Subsequent Test 3', () => {
            cy.log('This test should not be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });

        cytest('Other Critical Test', () => {
            // This test will fail
            cy.wrap(false).should('be.true');
        });

        cytest('Subsequent Test 4', () => {
            cy.log('This test should be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });
        cytest('Subsequent Test 6', () => {
            cy.log('This test should not be skipped in failFast mode');
            cy.wrap(true).should('be.true');
        });
    });
});

Individual Test Hooks

While global hooks are a staple in testing frameworks including Cypress, there are instances where individual tests require specific setup or cleanup operations. The Smart Tests Plugin allows you to define custom hooks for individual tests while having the global hooks! Yes, you read it right!

I’ll take a simple scenario and provide you the code for it. Let’s assume If you’re seeding a test DB for a specific test case:

Persistent Variables

Speaking of variables, it’s a very common scenario we want to share variable values between tests. But by default they reset after the execution of the it() block. The cypress-smart-tests plugin provides you with a solution to define and persist variables across tests (not across Spec files). You can store and retrieve test variables across cytest() blocks like this:

Here is a full code snippet where variables are defined and used across tests:

import { cytest, cyVariable, cyVariables, resetState } from 'cypress-smart-tests';

describe('Cypress Smart Tests Plugin - Persistent Variables', () => {
    beforeEach(() => {
        resetState();
    });

    context('Basic Variable Usage', () => {
        // Set up a variable before tests
        before(() => {
            cyVariable('testVar', 'initial value');
        });

        cytest('Set and get a variable', () => {
            // Set a variable
            cyVariable('username', 'testuser');

            // Get the variable
            const username = cyVariable('username');

            // Verify the variable was set correctly
            expect(username).to.equal('testuser');
        });

        cytest('Variable persists across tests', () => {
            // Get the variable set in the previous test
            const username = cyVariable('username');

            // Verify the variable still has the same value
            expect(username).to.equal('testuser');

            // Update the variable
            cyVariable('username', 'updateduser');

            // Verify the update worked
            expect(cyVariable('username')).to.equal('updateduser');
        });

        cytest('Variables can store different types', () => {
            // Store a number
            cyVariable('count', 42);
            expect(cyVariable('count')).to.equal(42);

            // Store an object
            const user = { id: 1, name: 'Test User', active: true };
            cyVariable('user', user);
            expect(cyVariable('user')).to.deep.equal(user);

            // Store an array
            const items = ['item1', 'item2', 'item3'];
            cyVariable('items', items);
            expect(cyVariable('items')).to.deep.equal(items);

            // Store a boolean
            cyVariable('isActive', true);
            expect(cyVariable('isActive')).to.be.true;
        });

        cytest('Variable set in before hook is available', () => {
            // Get the variable set in the before hook
            const testVar = cyVariable('testVar');

            // Verify the variable has the expected value
            expect(testVar).to.equal('initial value');
        });
    });

    context('Multiple Variables Management', () => {
        before(() => {
            // Reset variables to ensure a clean state
            resetState(true);
        });

        cytest('Add and get variables', () => {
            // Add variables
            cyVariables().add('username', 'testuser');
            cyVariables().add('userId', 123);
            cyVariables().add('userPreferences', { theme: 'dark', language: 'en' });

            // Get variables
            const username = cyVariables().get('username');
            const userId = cyVariables().get('userId');
            const userPreferences = cyVariables().get('userPreferences');

            // Verify variables were set correctly
            expect(username).to.equal('testuser');
            expect(userId).to.equal(123);
            expect(userPreferences).to.deep.equal({ theme: 'dark', language: 'en' });
        });

        cytest('Check if variables exist', () => {
            // Check existing variables
            expect(cyVariables().has('username')).to.be.true;
            expect(cyVariables().has('userId')).to.be.true;
            expect(cyVariables().has('userPreferences')).to.be.true;

            // Check non-existing variable
            expect(cyVariables().has('nonExistingVar')).to.be.false;
        });

        cytest('Get all variables', () => {
            // Get all variables
            const allVariables = cyVariables().getAll();

            // Verify all variables are returned
            expect(allVariables).to.deep.equal({
                username: 'testuser',
                userId: 123,
                userPreferences: { theme: 'dark', language: 'en' }
            });
        });

        cytest('Remove a variable', () => {
            // Remove a variable
            cyVariables().remove('username');

            // Verify the variable was removed
            expect(cyVariables().has('username')).to.be.false;

            // Other variables should still exist
            expect(cyVariables().has('userId')).to.be.true;
            expect(cyVariables().has('userPreferences')).to.be.true;
        });

        cytest('Clear all variables', () => {
            // Clear all variables
            cyVariables().clear();

            // Verify all variables were cleared
            expect(cyVariables().getAll()).to.deep.equal({});
            expect(cyVariables().has('userId')).to.be.false;
            expect(cyVariables().has('userPreferences')).to.be.false;
        });
    });

    context('Variables with resetState', () => {
        before(() => {
            // Set up some variables
            cyVariable('testVar1', 'value1');
            cyVariable('testVar2', 'value2');
        });

        cytest('Variables persist after normal resetState', () => {
            // Reset state without resetting variables
            resetState();

            // Variables should still exist
            expect(cyVariable('testVar1')).to.equal('value1');
            expect(cyVariable('testVar2')).to.equal('value2');
        });

        cytest('Variables are cleared with resetState(true)', () => {
            // Reset state and variables
            resetState(true);

            // Variables should be cleared
            expect(cyVariable('testVar1')).to.be.undefined;
            expect(cyVariable('testVar2')).to.be.undefined;
        });
    });

    context('Practical Examples', () => {
        before(() => {
            // Reset variables to ensure a clean state
            resetState(true);
        });

        cytest('Store user credentials for reuse', () => {
            // Store user credentials
            cyVariables().add('credentials', {
                username: 'testuser',
                password: 'password123'
            });

            // Verify credentials were stored
            const credentials = cyVariables().get('credentials');
            expect(credentials.username).to.equal('testuser');
            expect(credentials.password).to.equal('password123');

            // Simulate login
            cy.log(`Logging in with username: ${credentials.username}`);
        });

        cytest('Use stored credentials in another test', () => {
            // Get credentials from previous test
            const credentials = cyVariables().get('credentials');

            // Verify credentials are still available
            expect(credentials).to.not.be.undefined;
            expect(credentials.username).to.equal('testuser');

            // Simulate using credentials
            cy.log(`Using stored credentials for user: ${credentials.username}`);
        });

        cytest('Store and update test data', () => {
            // Store initial test data
            cyVariable('testData', { id: 1, status: 'pending' });

            // Simulate updating the data
            const testData = cyVariable('testData');
            testData.status = 'completed';
            cyVariable('testData', testData);

            // Verify the update
            expect(cyVariable('testData').status).to.equal('completed');
        });
    });
});

Keep in mind, that the variables are not persistent across Spec files. If you want variables that persist across Spec files, I highly recommend using the plugin ‘cypress-plugin-store’ by Lasitha Wijenayake!

Final Thoughts

The cypress-smart-testsplugin is a simple plugin I developed in my free-time ❤ This empowers you to write more smart and efficient tests by introducing mechanisms for defining dependencies, conditional execution, and custom hooks. By integrating this plugin into your Cypress test suite, you can enhance the maintainability and effectiveness of your end-to-end tests, ensuring that they remain robust and relevant as your application evolves.

Here is a full-demo code: https://github.com/s-chathuranga-j/cypress-smart-tests-demo-code

Let me know how it works for you and feel free to contribute or suggest improvements!

GitHub repo: https://github.com/s-chathuranga-j/cypress-smart-tests

Zero to Hero: Email Automation with Cypress & Mailosaur

S Chathuranga Jayasinghe — Sat, 29 Mar 2025 13:25:43 +0000

One of the trickiest parts of end-to-end testing has always been email verification.

Whether it’s account sign-ups, password resets, or email-based authentication flows, we often find ourselves writing hacky solutions or hitting a dead end altogether.

That’s where Mailosaur comes in! An awesome tool that helps test emails (and even SMS) in an automated way. What’s even better? There’s an official Cypress plugin that makes email testing a breeze for us, the Cypress fans.

In this article, let’s dive into how you can seamlessly integrate Cypress and Mailosaur to validate email flows like a pro ❤

The Setup

Before we jump into code, let’s make sure the basics are covered.

Install the plugin:

Run this command to install the package in your Cypress project

npm install — save-dev cypress-mailosaur
Configure Cypress support: In your cypress/support/e2e.ts or e2e.js, add:

import ‘cypress-mailosaur’;This adds custom commands to your Cypress chain like cy.mailosaurGetMessage()
Set your Mailosaur API key:

You can either set the API key in the Cypress environment configuration (cypress.config.ts) like this:

Or, if you’re keeping secrets out of code (highly recommended), pass them via environment variables when running Cypress.

Real-World Test: Email Verification Flow

Let’s say you have a sign-up form that sends a verification email with a link. Here’s how you can test it with Mailosaur:

Tip! You can validate plain text content or even attachments if your use case demands it. Mailosaur’s API gives you access to email bodies (email.text.body, email.html.body) and much more. ❤

Email Deliverability Validation

Mailosaur has some more Magic! The mailosaurGetSpamAnalysis() command runs a SpamAssassin test against an email, which scores the email based on some rules. The lower the score the better and, in most cases, a score higher then 5.0 will result in an email being seen as spam. The command will also return a list of rules that were triggered by the email. These rules are the same as those used by SpamAssassin itself and are based on a set of criteria that are common in spam emails. You can read more here. Here’s how you can test it:

Retry Logic Built In

No need to manually add cy.wait() or retry loops. cy.mailosaurGetMessage() automatically waits and polls for the email, up to the timeout you define (default is 10 seconds). You can customize this:

This is incredibly useful when your email service takes a few extra seconds to deliver.

Verifying OTPs and Tokens

For apps sending OTPs or verification codes, you can extract values directly:

Easy peasy 🍋! ❤

Bonus: Testing Edge Cases

Want to test that an email is not sent? You can use cy.mailosaurGetMessage() with a very short timeout and assert a failure:

Keep in mind this will cause the test to fail if the email is received!

Cleanup

Emails in Mailosaur are ephemeral, but if you want to delete them manually after each test:

Useful when your test suite runs in parallel or reuses the same inbox across tests.

Final Thoughts

I’ve used this setup in multiple real-world projects — especially when testing sign-up flows, password resets, and account recovery. It saves time, avoids flaky manual inbox checkers, and integrates cleanly with Cypress.

If you’re building quality into your apps with Cypress, don’t skip email verification. It’s an important part of the user journey — and now, testing it is super simple thanks to Mailosaur.

Happy Testing!

DEV Community: S Chathuranga Jayasinghe

Comet Browser: The Revolutionary AI-Powered Browser That Actually Does Your Work

What Makes Comet Different

The Magic in Action: Real-World Testing

Scenario 1: Text-Based Automation

Scenario 2: Voice-Powered Web Automation

Why This Represents a Paradigm Shift

From Manual to Conversational

Context-Aware Intelligence

Multi-Step Task Automation

The Technical Innovation Behind the Magic

Implications for the Future

A Word of Caution!

The Bottom Line

From 1-Hour Nightmares to 7-Minute Dreams: Our Cypress Cloud Journey

The Dark Ages: When Testing Felt Like Punishment

The Lightbulb Moment: Enter Cypress Cloud

The Transformation: From Hours to Minutes

What Made the Magic Happen

Smart Test Orchestration: The Brain Behind the Operation

Parallelization: Divide and Conquer

Page Object Model: A Much-Needed Architectural Shift

Test Replay: The Debugging Superhero We Never Knew We Needed

Test Analytics: Your Personal Test Performance Detective

Flaky Test Detection: No More “It Works on My Machine”

Cypress Cloud AI: The Future is Here

The Real-World Impact: Beyond Just Speed

The Numbers Don’t Lie

What We Learned Along the Way

It’s Not Just About the Tools

The ROI is Real

Looking Forward

Stop Writing Messy Cypress Tests: This Boilerplate Plugin Saves Your Sanity

The Problem We All Face

The Role Model: cypress-bootstrap

The Secret Sauce: Smart Locator Design

Why Arrow Functions Are Your Best Friend

Dynamic Locators: The Game Changer

The Singleton Pattern Magic

Why Singleton is Perfect Here

Organizing Complex UI Components

The Readability Game-Changer

Real-World Benefits You'll Actually Notice

Getting Started Takes 2 Minutes

The Bottom Line

Stop Your Users From Cringing: How to Add Grammar and Spell-Check to Your Cypress Tests

Why LanguageTool + Cypress is a Match Made in Heaven

Setting Up Your Grammar Police

Installing the Dependencies

Creating Your Custom Cypress Command

No More API Key Management!

Writing Your First Grammar Test

Getting Fancy: Batch Checking Multiple Elements

Real-World Tips and Gotchas

Making It Part of Your CI/CD Pipeline

The Bottom Line

Let’s Sync Cypress Tests with Azure Like a Pro (No More Manual Linking!)

What does cypress-azure-sync do?

How does it identify and map tests?

Quick Setup — How to use it in your project

Install the Plugin

Configure the Plugin

Define the Azure Configurations

Set the MetaData on Spec Files

Execute the Sync Process

Why I Built This Plugin (a mini behind-the-scenes)

What’s Next for the Plugin?

Why Linking your Test Scripts with the Test Management Tool is a Game-Changer!

What do I mean by Linking?

Why Is It So Important?

Benefits of Having the Link

So… How Do You Set This Up?

Test Rail

Azure Test Plans

Xray (Jira)

Final Thoughts

Unlocking AI Superpowers in Test Automation: It All Starts with Your Framework

The AI Isn’t the Sole Hero Here

Share the Blueprint: Feed the Architecture to AI

The Prompt Is Your Steering Wheel

What does `cypress-azure-sync` do?