Basics of Software Testing You Must Know

# login.feature — a test case written in Gherkin
# This is how testers describe behaviour before any code exists.
# Readable by developers, testers, and product owners alike.

Feature: User login
  As a registered user
  I want to log in with my credentials
  So that I can access my account

  Background:
    Given the login page is open

  Scenario: Successful login with valid credentials
    When I enter the email "user@example.com"
    And I enter the password "CorrectPass123"
    And I click the login button
    Then I should see the dashboard
    And I should see "Welcome back" in the header

  Scenario: Login fails with wrong password
    When I enter the email "user@example.com"
    And I enter the password "WrongPass"
    And I click the login button
    Then I should see the error "Invalid email or password"
    And I should remain on the login page

  Scenario: Login fails with an empty password
    When I enter the email "user@example.com"
    And I leave the password field empty
    And I click the login button
    Then I should see the error "Password is required"

  # Why this matters:
  # - The test case is written from the requirement, not the code
  # - Each scenario covers one path: happy path, wrong password, empty input
  # - A beginner tester's first job is writing these clearly
  # - These become the basis for manual runs AND automation scripts

# test_api.py — API testing with pytest and requests
# API testing is where most modern QA work happens.

import requests
import pytest

BASE_URL = "https://api.example.com"

def test_get_user_returns_200():
    response = requests.get(f"{BASE_URL}/users/1", timeout=10)
    assert response.status_code == 200

def test_get_user_has_expected_fields():
    response = requests.get(f"{BASE_URL}/users/1", timeout=10)
    body = response.json()
    assert "id" in body
    assert "email" in body
    assert body["id"] == 1

def test_create_user_requires_email():
    payload = {"name": "Test User"}  # email deliberately missing
    response = requests.post(f"{BASE_URL}/users", json=payload, timeout=10)
    assert response.status_code == 400
    assert "email" in response.json()["message"].lower()

def test_login_with_invalid_credentials_returns_401():
    payload = {"email": "user@example.com", "password": "wrong"}
    response = requests.post(f"{BASE_URL}/login", json=payload, timeout=10)
    assert response.status_code == 401

@pytest.mark.parametrize("email", ["", "not-an-email", "a@b"])
def test_login_rejects_invalid_email_formats(email):
    payload = {"email": email, "password": "CorrectPass123"}
    response = requests.post(f"{BASE_URL}/login", json=payload, timeout=10)
    assert response.status_code == 400

# What this teaches:
# - Check status codes, response bodies, and error messages
# - Test both the happy path and the failure paths
# - Parametrize to cover many inputs with one test
# - API tests are fast and stable — they belong in the middle
#   of the testing pyramid

// login.spec.ts — UI testing with Playwright
// End-to-end tests are slow and few. Use them for critical flows only.

import { test, expect } from "@playwright/test";

test.describe("Login flow", () => {
  test.beforeEach(async ({ page }) => {
    await page.goto("/login");
  });

  test("valid credentials log the user in", async ({ page }) => {
    await page.getByLabel("Email").fill("user@example.com");
    await page.getByLabel("Password").fill("CorrectPass123");
    await page.getByRole("button", { name: "Log in" }).click();

    await expect(page).toHaveURL(/\/dashboard/);
    await expect(page.getByText("Welcome back")).toBeVisible();
  });

  test("wrong password shows an error", async ({ page }) => {
    await page.getByLabel("Email").fill("user@example.com");
    await page.getByLabel("Password").fill("WrongPass");
    await page.getByRole("button", { name: "Log in" }).click();

    await expect(
      page.getByText("Invalid email or password")
    ).toBeVisible();
    await expect(page).toHaveURL(/\/login/);
  });

  test("empty password is blocked client-side", async ({ page }) => {
    await page.getByLabel("Email").fill("user@example.com");
    await page.getByRole("button", { name: "Log in" }).click();

    await expect(page.getByText("Password is required")).toBeVisible();
  });
});

// What this teaches:
// - Use accessible locators (labels, roles) instead of CSS selectors
// - Assert on outcomes users care about: URL change and visible text
// - Cover critical flows only — UI tests are the slowest layer
// - Keep each test independent so failures are easy to diagnose