DEV Community: Utkarsh

🚀 APIs Made Simple: The Secret Language of the Web

Utkarsh — Thu, 05 Feb 2026 17:58:00 +0000

🚀 APIs Made Simple: The Secret Language of the Web

Have you ever received a 404 Not Found or a 500 Internal Server Error and wondered what the server was trying to tell you?

In reality, APIs are not mysterious at all. Every API call is a simple two-way conversation:

The client asks the server to do something
The server replies with a status code explaining what happened

Once you understand this conversation, APIs become much easier to debug, test, and design.

To understand APIs clearly, you only need to focus on two core ideas:

HTTP Methods – What action you are asking the server to perform
HTTP Status Codes – How the server responds to that action

Let’s break both of these down in simple terms.

🛠 HTTP Methods – What You Are Asking the Server to Do

HTTP methods describe the action you want the server to take.
Think of them as verbs in a sentence.

📖 GET – “Fetch the data”

Used for reading data only
Does not change anything on the server

Example:
Fetching an employee profile from an HR system or viewing product details in an app.

Use GET when you only want information.

✍️ POST – “Create something new”

Used to send data to the server
Creates a new resource

Example:
User registration, submitting a form, or placing a new e-commerce order.

Use POST when something new needs to be created.

🔁 PUT – “Replace the whole thing”

Used to update an existing resource completely
You send the entire object, not just the changed fields

Example:
Replacing a full user profile including name, email, and address.

Use PUT when you want to overwrite the existing data.

✂️ PATCH – “Update just a piece”

Used for partial updates
Only the fields that need to change are sent

Example:
Updating only a user’s email address without sending the full profile.

Use PATCH for small, targeted updates.

❌ DELETE – “Remove it”

Used to delete a specific resource

Example:
Removing a cart item or deleting a user account.

🩺 HEAD & OPTIONS – “The Check-Up”

These methods are not about data changes but validation and safety.

HEAD: Fetches headers only (no response body) Useful for health checks and performance testing.
OPTIONS: Shows which HTTP methods are allowed Essential for CORS and browser security checks.

🔄 The Concept of Idempotency (Why It Matters)

In API terms, idempotency means:

Repeating the same request multiple times gives the same result.

Idempotent Methods

GET
PUT
DELETE
HEAD
OPTIONS

Example:
Deleting the same user twice still results in the user being deleted — nothing new happens.

Non-Idempotent Methods

POST
PATCH

Example:
Sending the same POST request multiple times may create duplicate records (such as multiple identical orders).

Understanding idempotency is important for retries, error handling, and automation testing.

📬 HTTP Status Codes – How the Server Replies

After processing a request, the server responds with a status code that explains the outcome.

✅ 2xx – Success (The Green Light)

These codes mean the request was successful.

200 OK – Request succeeded and data was returned
201 Created – A new resource was created successfully
204 No Content – The action worked, but there is no data to return (common for DELETE)

🔁 3xx – Redirection (The Detour)

These codes indicate the resource is located elsewhere or cached.

301 Moved Permanently – Used during API version changes
304 Not Modified – Cached data is still valid, improving performance

⚠️ 4xx – Client Errors (Check Your Request)

These mean the client sent something wrong.

400 Bad Request – Invalid data or malformed request
401 Unauthorized – Authentication failed or missing
403 Forbidden – Authenticated, but not allowed
429 Too Many Requests – Rate limit exceeded

🔥 5xx – Server Errors (Server Failure)

These indicate problems on the server side.

500 Internal Server Error – Unhandled exception or bug
502 / 504 – Communication failures or timeouts between services

These errors usually require developer or infrastructure fixes.

🧠 The Golden Rule of API Testing

Always validate the status code first.

It is the primary contract between the client and the server.

2xx → It worked
4xx → Fix the request
5xx → Server problem

Once you understand this flow, API debugging becomes logical problem-solving instead of guesswork.

Final Thought

APIs don’t fail randomly — they explain exactly what happened.
Learning to read HTTP methods and status codes is the first step toward mastering backend systems, API testing, and modern software development.
🚀

Day 04 - 🧩 Building a Complete Selenium Java Framework - Base Class Refactoring & TestNG Suite Integration

Utkarsh — Wed, 04 Feb 2026 18:01:00 +0000

Day 04 – Base Class Refactoring & TestNG Suite Integration

By Day 03, we had a working Base Class that could:

Launch a browser
Read configuration values
Open the application
Close the browser

On Day 04, we make this code production-ready.

Today is about:

Refactoring (cleaning and modularising code)
Optimising TestNG lifecycle usage
Introducing TestNG XML for suite-level execution

This is the point where our framework starts to feel professional.

🎯 Why Refactoring Is Necessary

As frameworks grow:

One long method becomes hard to debug
Changes in one place can break others
Reusability drops

Refactoring helps us:

Split responsibilities
Improve readability
Prepare for parallel execution later

👉 Rule of thumb:
Small methods, single responsibility.

Step 1: Refactoring the Base Class (Modern Approach)

🔧 Key Improvements from Day 03

✔ Load configuration once per suite
✔ Separate browser launch and configuration
✔ Avoid unnecessary static waits
✔ Prepare for cross-browser and parallel execution

📁 Updated File Location

src/main/java
 └── com.orangehrm.base
     └── BaseClass.java

✅ Refactored `BaseClass.java` (Industry Standard)

package com.orangehrm.base;

import java.io.FileInputStream;
import java.time.Duration;
import java.util.Properties;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.edge.EdgeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;

import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.BeforeSuite;

public class BaseClass {

    protected static Properties prop;
    protected WebDriver driver;

    // Load configuration only once before suite execution
    @BeforeSuite
    public void loadConfig() {
        try {
            prop = new Properties();
            FileInputStream fis = new FileInputStream(
                System.getProperty("user.dir") + "/src/main/resources/config.properties"
            );
            prop.load(fis);
        } catch (Exception e) {
            throw new RuntimeException("Failed to load config.properties", e);
        }
    }

    // Runs before every test method
    @BeforeMethod
    public void setup() {
        launchBrowser();
        configureBrowser();
    }

    // Browser initialization
    private void launchBrowser() {
        String browser = prop.getProperty("browser").toLowerCase();

        switch (browser) {
            case "chrome":
                driver = new ChromeDriver(); // Selenium Manager handles driver
                break;

            case "firefox":
                driver = new FirefoxDriver();
                break;

            case "edge":
                driver = new EdgeDriver();
                break;

            default:
                throw new RuntimeException("Unsupported browser: " + browser);
        }
    }

    // Browser configuration
    private void configureBrowser() {
        driver.manage().window().maximize();
        driver.manage().timeouts().implicitlyWait(
            Duration.ofSeconds(Integer.parseInt(prop.getProperty("implicit_wait")))
        );
        driver.get(prop.getProperty("url"));
    }

    // Runs after every test method
    @AfterMethod
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

🔍 Important Corrections & Best Practices

❌ Why We Removed `LockSupport` / Static Waits

Hard waits are not recommended in modern frameworks
They block execution unnecessarily
We will rely on explicit waits inside the Action Driver (Day 05)

👉 Static waits should only be used for debugging, not framework design.

✅ Why `@BeforeSuite` Is Used for Config

Configuration data is global
Loading it once improves performance
Prevents repeated file I/O operations

⚠ Why WebDriver Is NOT Static

Static WebDriver breaks parallel execution
Causes session conflicts
Modern frameworks use instance-level drivers

Parallel execution will be introduced later using ThreadLocal.

Step 2: Introducing TestNG XML (Suite Control Center)

So far, we ran tests by right-clicking test classes.
In real projects, this is never done.

Instead, we use TestNG XML to:

Group tests
Control execution order
Enable parallel runs
Integrate with CI/CD

📄 Create `testng.xml`

Location (recommended):

src/test/resources/testng.xml

🧾 `testng.xml` (Clean & Correct)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">

<suite name="OrangeHRM Automation Suite">

    <test name="Smoke Tests">
        <classes>
            <class name="com.orangehrm.tests.DummyTest"/>
        </classes>
    </test>

</suite>

Step 3: Running Tests Using TestNG XML

▶ How to Run

Right-click testng.xml
Select Run As → TestNG Suite

✅ Expected Flow

Config loads once
Browser launches before each test
Application opens
Test executes
Browser closes cleanly

This is exactly how CI tools like Jenkins run tests.

📌 Day 04 Summary

Today, you:

Refactored the Base Class for scalability
Applied TestNG lifecycle correctly
Introduced suite-based execution
Prepared the framework for future growth

Your framework is no longer “basic automation” —
it is now architected.

🧠 Day 04 Task

Refactor your BaseClass as shown
Create testng.xml
Add DummyTest to the suite
Run tests using TestNG Suite, not individual classes

🚀 What’s Coming Next (Day 05)

Next, we will build the Action Driver:

click()
sendKeys()
explicit waits
element visibility handling

This will make test scripts:
✔ Smaller
✔ Cleaner
✔ Easier to read

You’ve officially crossed into framework engineering territory 👏

Day 03 - Building a Complete Selenium Java Framework - The Backbone: Base Class and Configuration

Utkarsh — Tue, 03 Feb 2026 17:56:00 +0000

Day 03 – The Backbone: Base Class and Configuration

On Day 01, we planned the framework.
On Day 02, we created the project and structure.

Now on Day 03, we build the most important part of the framework—the Base Class.

If this framework were a building, the Base Class would be the foundation.
Every test we write later will stand on top of it.

🎯 Why Do We Need a Base Class?

In automation testing, almost every test does the same starting work:

Launch the browser
Navigate to the application URL
Apply waits
Close the browser after execution

If we write this logic inside every test, our code becomes:

Repetitive
Hard to maintain
Error-prone

The Base Class solves this problem by:

Centralising browser setup and teardown
Loading configuration values
Ensuring all tests behave consistently

Every test class will simply extend the Base Class.

Step 1: Understanding `config.properties`

Hard-coding values like browser name or URL inside Java code is a bad practice.

Instead, we use a configuration file:

Easy to change
No recompilation needed
Supports multiple environments

📄 `config.properties` (Initial Version)

This file lives inside:
src/main/resources/config.properties

# Application Settings
url=https://opensource-demo.orangehrmlive.com/
browser=chrome
implicit_wait=10

🔍 What Each Property Means

url → Application under test
browser → Which browser to launch
implicit_wait → Global wait time for element search

Later, we’ll add more values as the framework grows.

Step 2: Creating the Base Class

Now we write the Base Class, which will:

Load the configuration file
Launch the browser
Apply waits
Navigate to the application
Close the browser after execution

📁 File Location

Create the file here:

src/main/java
 └── com.orangehrm.base
     └── BaseClass.java

🧩 BaseClass.java – Complete Implementation

package com.orangehrm.base;

import java.io.FileInputStream;
import java.util.Properties;
import java.time.Duration;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.edge.EdgeDriver;

import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;

public class BaseClass {

    protected static Properties prop;
    protected static WebDriver driver;

    // Load configuration from config.properties
    public void loadConfig() {
        try {
            prop = new Properties();
            FileInputStream fis = new FileInputStream(
                System.getProperty("user.dir") + "/src/main/resources/config.properties"
            );
            prop.load(fis);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    @BeforeMethod
    public void setup() {
        loadConfig();

        String browserName = prop.getProperty("browser");

        // Browser selection
        if (browserName.equalsIgnoreCase("chrome")) {
            driver = new ChromeDriver();
        } else if (browserName.equalsIgnoreCase("firefox")) {
            driver = new FirefoxDriver();
        } else if (browserName.equalsIgnoreCase("edge")) {
            driver = new EdgeDriver();
        }

        // Browser management
        driver.manage().window().maximize();
        driver.manage().timeouts().implicitlyWait(
            Duration.ofSeconds(Integer.parseInt(prop.getProperty("implicit_wait")))
        );

        // Launch application
        driver.get(prop.getProperty("url"));
    }

    @AfterMethod
    public void tearDown() {
        if (driver != null) {
            driver.quit();
        }
    }
}

Step 3: Important Concepts You Used Today

🔹 Selenium Manager (Selenium 4)

You’ll notice we did not use:

System.setProperty("webdriver.chrome.driver", "path");

Selenium 4 introduces Selenium Manager, which:

Automatically downloads drivers
Manages driver paths internally
Reduces setup headaches

🔹 Implicit Wait

Applied globally for the entire session
Selenium waits up to the defined time before throwing NoSuchElementException

driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));

🔹 Access Modifiers

We used protected for:

protected static WebDriver driver;
protected static Properties prop;

Why?

Child classes (test classes) can access them
Still protected from outside misuse

🔹 TestNG Annotations

@BeforeMethod
Runs before every test method
→ Browser always starts fresh
@AfterMethod
Runs after every test method
→ Browser always closes cleanly

This guarantees test isolation.

Step 4: Validating the Backbone (Very Important)

Before moving forward, we must confirm:
👉 The Base Class actually works.

🧪 Create a Dummy Test

Create this file:

src/test/java
 └── DummyTest.java

import org.testng.annotations.Test;
import com.orangehrm.base.BaseClass;

public class DummyTest extends BaseClass {

    @Test
    public void testBaseSetup() {
        // No code needed
        // Browser should open and close automatically
    }
}

✅ Expected Behaviour

When you run this test:

Browser opens
Navigates to Orange HRM login page
Maximises window
Waits applied
Browser closes after execution

If this happens → Day 03 is successful 🎉

📌 Day 03 Summary

Today, you built:

A centralised Base Class
Configuration-driven browser setup
Clean startup and shutdown logic
Selenium 4-ready WebDriver initialization

This Base Class will be reused by every test going forward.

🚀 What’s Next?

On Day 04, we will:

Create the Action Driver
Centralise reusable actions like:
- click
- sendKeys
- waits

This will make test scripts short, clean, and readable.

You’ve just completed the core backbone of the framework 💪

🛠️ Day 02 - Building a Complete Selenium Java Framework – Project Initiation and Structure

Utkarsh — Mon, 02 Feb 2026 17:48:00 +0000

Day 02 – Project Initiation and Structure

On Day 01, we designed the blueprint of our Selenium Java framework.
On Day 02, we finally move from planning to action.

Today is about setting up the foundation of the project—the part you build once and rely on throughout the framework’s lifetime. If this step is done correctly, everything that comes later becomes easier, cleaner, and more scalable.

🎯 What We Will Do Today

By the end of Day 02, you will have:

A Maven-based Selenium project
All required dependencies configured
A clean, industry-standard folder structure
A central configuration file for global settings

This setup works the same way in real-world automation projects.

Step 1: Creating the Maven Project

We use Maven because it automatically:

Downloads required libraries
Manages versions
Integrates easily with CI/CD tools like Jenkins

You can use Eclipse or IntelliJ IDEA—both are widely used.

▶ Option 1: Create Maven Project in Eclipse

Open Eclipse IDE
Go to File → New → Maven Project
Click Next
Select:

Archetype: maven-archetype-quickstart
Version: 1.4 or 1.5
1. Click Next
2. Enter:
Group Id: com.orangehrm
Artifact Id: OrangeHRM_Project
1. Finish the setup
2. Ensure the project is using Java 17:
Right-click project → Properties → Java Compiler → Set to 17

Eclipse will create a basic Maven project with a pom.xml file.

▶ Option 2: Create Maven Project in IntelliJ IDEA

Open IntelliJ IDEA
Click New Project
Select Maven
Click Next
Enter:
- GroupId: com.orangehrm
- ArtifactId: OrangeHRM_Project
Select JDK 17
Finish

IntelliJ will automatically download Maven dependencies in the background.

Step 2: Configuring Dependencies (pom.xml)

The pom.xml file is the heart of a Maven project.
This is where we define all external libraries our framework needs.

For now, we add:

Selenium WebDriver
TestNG

📌 Why these?

Selenium → Browser automation
TestNG → Test execution, grouping, reporting, and parallel runs

🔧 pom.xml – Essential Dependencies

Add the following inside the <dependencies> section:

<dependencies>

    <!-- Selenium WebDriver -->
    <dependency>
        <groupId>org.seleniumhq.selenium</groupId>
        <artifactId>selenium-java</artifactId>
        <version>4.27.0</version>
    </dependency>

    <!-- TestNG Framework -->
    <dependency>
        <groupId>org.testng</groupId>
        <artifactId>testng</artifactId>
        <version>7.10.2</version>
        <scope>compile</scope>
    </dependency>

</dependencies>

Once saved:

Eclipse → Right-click project → Maven → Update Project
IntelliJ → Maven reload happens automatically

If there are no errors, your dependencies are set correctly.

Step 3: Designing the Folder Structure

The default Maven structure is good, but not enough for a scalable automation framework.

We now create a clean, logical package hierarchy.

🚨 First Step

Delete any default packages created under:

src/main/java
src/test/java

We’ll build our own structure.

📁 Packages Under `src/main/java`

Create the following packages:

Package	Purpose
`com.orangehrm.base`	Browser setup and teardown
`com.orangehrm.actiondriver`	Common Selenium actions
`com.orangehrm.pages`	Page Object classes
`com.orangehrm.utilities`	Excel, reporting, helpers
`com.orangehrm.listeners`	TestNG listeners

This separation ensures:

Clean code
Easy maintenance
Better scalability

📁 Resources Folder Setup

Under src/main/resources, create:

config.properties
log4j2.xml

We will use these files throughout the framework.

Step 4: Global Configuration Using config.properties

Hardcoding values like URLs and browsers is a bad practice.
Instead, we store them in a configuration file.

This makes switching environments easy (QA, UAT, Production).

📝 config.properties – Initial Setup

Create this file in src/main/resources:

# Application Settings
url=https://opensource-demo.orangehrmlive.com/
browser=chrome

# Timeout Settings
implicit_wait=10
explicit_wait=30

# Test Credentials
username=admin
password=admin123

Later, our framework will read these values dynamically.

✅ Day 02 Summary

By the end of today, you have:

A Maven-based Selenium project
Selenium and TestNG fully configured
A professional folder structure
A central configuration system

This is the backbone of the automation framework.

📌 Day 02 Task

Create the Maven project (Eclipse or IntelliJ)
Add Selenium and TestNG dependencies
Create all required packages
Validate the setup:

Maven dependencies resolve successfully
No build errors

🚀 What’s Next?

On Day 03, we will:

Create the Base Class
Configure WebDriver using Selenium Manager
Launch the browser dynamically

The real automation begins next 🚦

🚗 Day 01: Building a Selenium Java Framework — The Blueprint

Utkarsh — Sun, 01 Feb 2026 17:35:51 +0000

A Small Story to Begin…

Imagine you’re about to build a race car, not a toy one, but a real machine that must run fast, safely, and reliably on different tracks.
You wouldn’t just start welding parts together randomly, right?

First, you’d:

Decide the design
Choose the engine
Pick the tools
Set up the garage

That’s exactly what we’re doing on Day 01 of building a Selenium Automation Framework.

Today is all about planning and preparation.

🤖 What Is an Automation Framework?

An automation framework is like a rulebook and toolbox combined.

Instead of writing messy test scripts again and again, a framework:

Tells you how to write code
Decides where things should live
Manages test data
Keeps tests easy to reuse and easy to fix

👉 The result?

Less duplicate work
Easier maintenance
Tests that work on different systems
Happy testers 😄

🧰 Our Toolbelt (Technology Stack)

To build a strong and modern framework, we’ll use trusted tools—just like choosing good materials for a house.

Here’s what we’re working with:

🔹 Core Engine

Selenium WebDriver 4 – the heart of browser automation

🔹 Language & IDE

Java 17 – our programming language
Eclipse/ IntelliJ IDE – where we write and run code

🔹 Build Tool

Maven – manages libraries and dependencies automatically

🔹 Testing Framework

TestNG – organizes tests, controls execution, and handles reports

🔹 Reporting

Extent Spark Reports – beautiful, visual test reports

🔹 Version Control

Git & GitHub – track code changes and collaborate like pros

🔹 CI/CD & Containers

Jenkins – automate test execution
Docker – run tests inside containers

Don’t worry if some of these sound new—we’ll meet them properly later.

🌟 What Makes This Framework Special?

This isn’t a “hello world” framework. It’s designed for real-world projects.

Some cool features we’ll build:

🚀 Selenium Manager – no need to manually download drivers
📸 Screenshots in Base64 format – directly embedded in reports
🖍️ Element highlighting – elements get a border when tests fail
⚡ Parallel execution – run tests faster
🌍 Cross-browser testing
🔗 API and Database testing support

Basically, this framework is ready for industry-level automation.

🏗️ Framework Structure (The Building Blocks)

Think of the framework like a well-organized office.

1️⃣ Base Class

This is the foundation.

Opens the browser
Closes the browser
Handles setup and teardown

2️⃣ Action Driver Class

This is your helper.

Clicks elements
Types text
Waits for elements Reusable methods live here.

3️⃣ Page Classes (POM)

Each web page gets its own class.

Login page
Dashboard page
Employee page

This follows the Page Object Model, which keeps tests clean and readable.

4️⃣ Utility Classes

These handle the behind-the-scenes work:

Reading data from Excel
Database connections
Report configuration

📂 Project Folder Structure

We’ll follow a professional layout:

src/main/java
👉 Base classes, page objects, utilities
src/test/java
👉 Actual test cases and validations

This separation keeps logic and tests nicely organized.

✅ Day 01 Task: Get Your Environment Ready

Before driving the car, we prepare the road.

🔍 What You Should Already Know

Basic Java (variables, data types, operators)
Selenium WebDriver basics
TestNG annotations

📝 Today’s Checklist

Install and verify:

☑️ Java
☑️ Eclipse IDE/ IntelliJ
☑️ Maven

Once these are ready, your system becomes our automation garage 🛠️

🚦 What’s Next?

The next day:

We’ll create the Maven project
Set up pom.xml
Start automating real test cases on the Orange HRM application

For now, relax—you’ve completed Day 01: The Blueprint 🎉
The journey has officially begun.

API Testing: A Beginner’s Guide

Utkarsh — Wed, 19 Feb 2025 19:26:03 +0000

APIs (Application Programming Interfaces) are the backbone of modern software, enabling apps to communicate and share data. Thus API Testing ensures that these interactions can occur when expected. This beginner-friendly guide gives an overview of API testing, its importance, types, tools, and best practices.

What is API Testing?

API testing is a sort of software testing to check an application programming interface (API) against functional, reliability, performance, and security parameters. Unlike UI testing, which focuses on the front end, API testing checks the business logic relevant to data response and communication between various software components.

The Importance of API Testing

Guarantees data integrity and seamless intercommunication between systems
Spells vulnerability to security before time
Aids in faster releases with automation integration
Reduces UI dependency while accelerating the whole process of testing and increasing efficiency

Types of API Testing

API Testing can be divided into further types, including:

Functional Testing: Verifying input and output whether the API works as intended.
Performance Testing: The tests API under different loads for speed, responsiveness, and stability.
Load Testing: Checks whether the API responds or not against heavy requests.
Security Testing: Testing for vulnerabilities such as unauthorized access, data breaches, and injection attacks.
Integration Testing: Verifying the performance of APIs in collaboration with other services or applications.
Negative Testing: Verifying how the API responds to inputs that are invalid or unexpected.

How API Testing Works

API testing consists of dispatching requests to an API endpoint and validating the responses. A basic workflow consists of the following activities:

API Documentation Understanding: An overview of available endpoints, request methods (GET, POST, PUT, DELETE), parameters, and authentication procedures.
Test Case Setup: Input data, expected output, and validation criterion established.
Sending API Requests: Tools used may include Postman, Curl, or automated scripts.
Response Validation: Status codes (200 OK, 404 Not Found, etc.), response times, and returned data.
API Tests Automation: Implementing automation by means of Rest Assured/Postman/Karate, etc.

Common API Testing Tools

The list below names some popular API testing tools:

Postman: A user-friendly tool for manual and automated API testing.
Rest Assured: Java library for API automation.
SoapUI: Best for SOAP and REST API testing.
Karate: Combines API testing, UI automation, and performance testing.
JMeter: Mainly for performance and load testing.

Best Practices for API Testing

Read the API documentation carefully before preparing test cases.
Check the response status codes, headers, and data against what is expected.
Check for authentication mechanisms (OAuth, API key, JWT, etc.) in place.
**Test various scenarios, with an emphasis on testing edge cases and negative inputs.
Build automation for any repetitive API tests** to save time and extend coverage.
API performance should be monitored to meet the required SLA.

Conclusion

API testing is central to guaranteeing seamless integration and functionality in the domain of modern applications. With an understanding of different types, tools, and best practices, you can efficiently carry out API testing and contribute to software quality.

What’s Next?

💬 Got questions about API testing? Drop them in the comments!
📌 What topic should we cover next? Let us know!

My First Steps with Playwright 🎭: A Tester’s Journey from Selenium

Utkarsh — Wed, 01 Jan 2025 21:26:15 +0000

A Little About Me

Hi! I’m Utkarsh, a software tester and automation enthusiast who has experience with the software known as Selenium. I still remember the first time I discovered this gem of a tool – I was absolutely in awe that there was a tool that could automate browsers, manipulate user actions, and handle testing all at once. It was like finding a secret passage in a video game!🎮

Fast forward a couple of days and I came across Playwright, and since then I’ve been trying out this tool. I’m still working my way around it, but I’ve already discovered some incredible functionalities that provide terrific support to Playwright as a browser automation tool. Today, I’ll share with you what I’ve learned so far and guide you through my journey. So grab your coffee ☕️ and let’s dive in.
Here's a glimpse of what we’ll be covering:

Auto-Waiting for Elements ⏳
Speed and Performance ⚡️
Handling Modern Web Interactions 🖱️
Headless Mode 👻
Simplicity & Reporting (Traces, Screenshots) 📸 - Aww, this one's a keeper!

My First Playwright Test: Automating Login Form

Okay, so now let's just get down and dirty, for the first time let's touch code. My first trial with Playwright was simple: go to a site, fill out a login form, if something goes wrong, take a screenshot. You know, a classic "let's see if this stuff works" type of test.

Prerequisites:

To get things flowing before the wand-waving magic starts, here is what you must have to get started:

Install Node.js (obviously the engine behind everything)
Install NPM (so your project can work)
Install any editor (but I recommend Visual Studio Code for fact)
Basic JavaScript Knowledge (or at least the ability to Google "what is a callback?")

Setting Up the Project:

Alright, let’s not waste time. You’ve installed Node.js and NPM on your machine? Okay fine-no outdated stuff around here, my friend! Now open your editor, create a new folder (or directory), and fire up the terminal in that folder.

Next, here comes the magic: type in the command below.
npm init playwright

Just that? Really? Yes, really! It is so simple that I feel like cheating. 😎 After you run this, Playwright will ask you few things: "What language are you comfortable with? JS or TypeScript?" and "Where should the test files go?" And, voila-yay! You’re done, now you are ready to roll!

No more manual downloading dependencies, JAR files, and so on complicated things. One command and you are ready! 🎩✨

On successful setup, your project structure should look somewhat like this:

At the present moment, there's no need to keep worrying about all those file obligations; focus at the present with:

tests folder: This is where all your test files go. Simple.
playwright.config.js file: Now, this is where the magic happens. Seriously, the config file is like the control room of your automation spaceship. 🛸
The config file lets you do a ton of stuff, like generating reports, taking screenshots, setting auto-wait for elements, switching between browsers, and much more. But, let’s keep it simple for now, just like I learned (and still learning) 😜.

This is a really simple configuration for your config file under module.exports. Just keep this and for now, comment out the rest of the code in the file (but please, don't touch the braces - they're sacred! Seriously, I've learned them the hard way. 😬).

module.exports = defineConfig({
  testDir: './tests',
  timeout: 30 * 1000,
  expect:{
    timeout:5000
  },
  reporter: 'html',
  use:{
    browserName: 'chromium',
    screenshot: 'only-on-failure',
    trace: 'retain-on-failure'
  }

You can explore example files and run tests to get an idea of how things work. But now, let’s get to the fun part: writing some test cases!

Let’s Write a Test: Automating Login Form

Here’s a simple test script that goes to the login page, enters credentials, clicks the login button, and hopefully logs you in (or breaks the page and takes a screenshot – whichever comes first 😉)

const {test, expect} = require('@playwright/test');
test.only('Login Test Case',async({page})=>{
    await page.goto('https://rahulshettyacademy.com/client');
    await page.locator('#userEmail').fill('rajusin675@gmail.com');
    await page.locator('#userPassword').fill('Abc@12345');
    await page.locator('#login').click();
});

Let me explain this:

const { test, expect } = require('@playwright/test') – This imports the test and expect functions, which are used to define and run your tests.
test.only('Login Test Case', async ({ page }) => {...}) – This defines the test case. The only(optional) method makes sure that this is the test that runs, and the async({page}) part tells Playwright that we're working with a browser page.
await page.goto('https://rahulshettyacademy.com/client') – This navigates to the login page.
await page.locator() - This locates the required field and fill() method enter values into the field, just like findElement() and sendkeys() in selenium respectively.
The click() method does exactly what its name promises—it clicks on the element.

Pretty simple, right? Just a few lines, and your automation test is ready to go. 💥

Running the Test: Headless vs. Headed Mode

Now let’s run the test, and there are two modes you can try:

Headless mode (no browser window shows up, it runs in the background):

npx playwright test

Headed mode (browser window pops up, so you can watch the magic unfold):

npx playwright test --headed

And that’s it! You’ve just run your first automation test using Playwright. How cool is that? 🧑‍💻✨

Conclusion: Automation = Magic + Fun

It is always a thrill to write the first automation script using Selenium, Playwright, or Cypress. There is something really satisfying when it sees your browser performs all your tasks for you. And of course, brag to everyone-including relatives-about your awesome coding skills and keeping that “tech guru” aura around your gang. You know the thing.😎
So, go ahead, try it out, and feel free to share your experiences with me! Let’s continue to automate our way to a better world – one test at a time.🛠️🎉

DEV Community: Utkarsh

🚀 APIs Made Simple: The Secret Language of the Web

🚀 APIs Made Simple: The Secret Language of the Web

🛠 HTTP Methods – What You Are Asking the Server to Do

📖 GET – “Fetch the data”

✍️ POST – “Create something new”

🔁 PUT – “Replace the whole thing”

✂️ PATCH – “Update just a piece”

❌ DELETE – “Remove it”

🩺 HEAD & OPTIONS – “The Check-Up”

🔄 The Concept of Idempotency (Why It Matters)

Idempotent Methods

Non-Idempotent Methods

📬 HTTP Status Codes – How the Server Replies

✅ 2xx – Success (The Green Light)

🔁 3xx – Redirection (The Detour)

⚠️ 4xx – Client Errors (Check Your Request)

🔥 5xx – Server Errors (Server Failure)

🧠 The Golden Rule of API Testing

Final Thought

Day 04 - 🧩 Building a Complete Selenium Java Framework - Base Class Refactoring & TestNG Suite Integration

Day 04 – Base Class Refactoring & TestNG Suite Integration

🎯 Why Refactoring Is Necessary

Step 1: Refactoring the Base Class (Modern Approach)

🔧 Key Improvements from Day 03

📁 Updated File Location

✅ Refactored BaseClass.java (Industry Standard)

🔍 Important Corrections & Best Practices

❌ Why We Removed LockSupport / Static Waits

✅ Why @BeforeSuite Is Used for Config

⚠ Why WebDriver Is NOT Static

Step 2: Introducing TestNG XML (Suite Control Center)

📄 Create testng.xml

🧾 testng.xml (Clean & Correct)

Step 3: Running Tests Using TestNG XML

▶ How to Run

✅ Expected Flow

📌 Day 04 Summary

🧠 Day 04 Task

🚀 What’s Coming Next (Day 05)

Day 03 - Building a Complete Selenium Java Framework - The Backbone: Base Class and Configuration

Day 03 – The Backbone: Base Class and Configuration

🎯 Why Do We Need a Base Class?

Step 1: Understanding config.properties

📄 config.properties (Initial Version)

🔍 What Each Property Means

Step 2: Creating the Base Class

📁 File Location

🧩 BaseClass.java – Complete Implementation

Step 3: Important Concepts You Used Today

🔹 Selenium Manager (Selenium 4)

🔹 Implicit Wait

🔹 Access Modifiers

🔹 TestNG Annotations

Step 4: Validating the Backbone (Very Important)

🧪 Create a Dummy Test

✅ Expected Behaviour

📌 Day 03 Summary

🚀 What’s Next?

🛠️ Day 02 - Building a Complete Selenium Java Framework – Project Initiation and Structure

Day 02 – Project Initiation and Structure

🎯 What We Will Do Today

Step 1: Creating the Maven Project

▶ Option 1: Create Maven Project in Eclipse

▶ Option 2: Create Maven Project in IntelliJ IDEA

Step 2: Configuring Dependencies (pom.xml)

📌 Why these?

🔧 pom.xml – Essential Dependencies

Step 3: Designing the Folder Structure

🚨 First Step

📁 Packages Under src/main/java

📁 Resources Folder Setup

Step 4: Global Configuration Using config.properties

📝 config.properties – Initial Setup

✅ Day 02 Summary

📌 Day 02 Task

🚀 What’s Next?

🚗 Day 01: Building a Selenium Java Framework — The Blueprint

A Small Story to Begin…

🤖 What Is an Automation Framework?

✅ Refactored `BaseClass.java` (Industry Standard)

❌ Why We Removed `LockSupport` / Static Waits

✅ Why `@BeforeSuite` Is Used for Config

📄 Create `testng.xml`

🧾 `testng.xml` (Clean & Correct)

Step 1: Understanding `config.properties`

📄 `config.properties` (Initial Version)

📁 Packages Under `src/main/java`