Testing Tdd Practice Exam — LearnCoachAssist

Question 1 Testing Tdd

What are flaky tests?

Flaky tests pass or fail intermittently without code changes. Common causes:

Shared mutable state between tests
Timing/race conditions in async code
External dependency failures (network, DB)
Order-dependent tests

Remedies:

Isolate tests properly
Use deterministic waits instead of sleep()
Mock external services
Quarantine flaky tests and fix them

Snapshot testing captures the output of a component or function and compares it against a stored reference:

First run: saves output as a snapshot file
Subsequent runs: compares output to saved snapshot
If different, the test fails — developer must accept or reject changes

Common in React with Jest:
expect(render(<Button />)).toMatchSnapshot();
Useful for UI testing but can become brittle if overused. Test doubles replace real dependencies in tests:

Dummy: Passed around but never used (fills parameter lists)
Stub: Provides canned responses to calls
Spy: Records calls while executing real logic
Mock: Pre-programmed with expectations to verify behavior
Fake: Working implementation with shortcuts (e.g., in-memory database)

Term coined by Gerard Meszaros in xUnit Test Patterns. Load testing simulates expected concurrent users/requests to verify the system meets performance requirements:

Identifies bottlenecks under realistic conditions
Measures response time, throughput, and error rates
Establishes performance baselines

Example with k6:
export default function() {
http.get('https://api.example.com');
sleep(1);
}

Question 2 Testing Tdd

What is a spy in testing?

Gherkin is a structured language for writing BDD scenarios:
Feature: User login
  Scenario: Valid credentials
    Given a registered user
    When they enter valid credentials
    Then they should see the dashboard

Keywords: Feature, Scenario, Given, When, Then, And, But. It's human-readable and executable. Parameterized testing runs the same test logic with different input/output pairs:

Reduces code duplication for similar test cases
Each parameter set is a separate test case

Jest example:
test.each([
  [1, 2, 3],
  [0, 0, 0],
])('add(%i, %i) = %i', (a, b, expected) => {
  expect(add(a, b)).toBe(expected);
});
Also available in JUnit (@ParameterizedTest), pytest (@pytest.mark.parametrize). TDD is a development practice where you write tests before writing production code. The cycle is:

Red: Write a failing test for the desired behavior
Green: Write the minimum code to make the test pass
Refactor: Clean up the code while keeping tests green

Benefits: better design, fewer bugs, living documentation, and confidence in refactoring. A spy wraps a real function, allowing it to execute normally while also recording information about its calls:

Tracks call count, arguments, return values
Does not replace the implementation (unlike mocks/stubs)
Useful for verifying side effects without changing behavior

Example in Jest:
const spy = jest.spyOn(obj, 'method');
expect(spy).toHaveBeenCalledWith('arg');

Question 3 Testing Tdd

What is an end-to-end (E2E) test?

A test suite is a collection of related test cases grouped together:

Organized by feature, module, or test type
Can be nested (suites within suites)
Run as a unit for targeted testing

Example in Jest:
describe('UserService', () => {
  describe('createUser', () => {
    test('creates with valid data', ...);
    test('rejects invalid email', ...);
  });
}); An E2E test simulates real user workflows through the entire application stack. It validates the system from the user's perspective:

Uses tools like Playwright, Cypress, or Selenium
Tests full user journeys (login → action → logout)
Slowest and most brittle test type
Catches integration issues across the whole system

Code coverage measures the percentage of code exercised by tests. 100% can be misleading because:

Covered ≠ tested — code may execute without meaningful assertions
Doesn't test edge cases, error handling, or concurrency
Can incentivize writing trivial tests to hit targets
Misses logical errors in covered code

Better approach: aim for meaningful coverage (80-90%) with high-quality assertions, not 100% with weak tests. Snapshot testing captures the output of a component or function and compares it against a stored reference:

First run: saves output as a snapshot file
Subsequent runs: compares output to saved snapshot
If different, the test fails — developer must accept or reject changes

Common in React with Jest:
expect(render(<Button />)).toMatchSnapshot();
Useful for UI testing but can become brittle if overused.

Question 4 Testing Tdd

What is code coverage and why can 100% coverage be misleading?

Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests catch them:

Mutants: Change + to -, == to !=, remove statements
Killed mutant: A test fails (good — tests caught the bug)
Survived mutant: No test fails (bad — tests have gaps)

Mutation score = killed / total mutants.
Tools: Stryker (JS), PITest (Java), mutmut (Python). Code coverage measures the percentage of code exercised by tests. 100% can be misleading because:

Covered ≠ tested — code may execute without meaningful assertions
Doesn't test edge cases, error handling, or concurrency
Can incentivize writing trivial tests to hit targets
Misses logical errors in covered code

Better approach: aim for meaningful coverage (80-90%) with high-quality assertions, not 100% with weak tests. Performance testing evaluates how a system behaves under various conditions:

Load testing: Behavior under expected load
Stress testing: Behavior beyond normal capacity
Spike testing: Sudden large load increases
Endurance testing: Sustained load over time

Metrics: response time, throughput, resource utilization.
Tools: JMeter, k6, Gatling, Locust. A fake is a working implementation with simplified behavior used for testing:

Has real logic but takes shortcuts
Examples: in-memory database, fake file system, local email server
More realistic than stubs but lighter than real dependencies

Unlike mocks, fakes don't verify interactions. Unlike stubs, fakes have working business logic. Example: FakeUserRepository backed by a HashMap instead of a real database.

Question 5 Testing Tdd

What is smoke testing?

Test doubles replace real dependencies in tests:

Dummy: Passed around but never used (fills parameter lists)
Stub: Provides canned responses to calls
Spy: Records calls while executing real logic
Mock: Pre-programmed with expectations to verify behavior
Fake: Working implementation with shortcuts (e.g., in-memory database)

Term coined by Gerard Meszaros in xUnit Test Patterns. JUnit is the standard unit testing framework for Java:

JUnit 5 (Jupiter) is the latest version
Uses annotations: @Test, @BeforeEach, @AfterAll, @DisplayName
Supports parameterized tests with @ParameterizedTest
Integrated with Maven, Gradle, and all Java IDEs

Example:
@Test void shouldAdd() {
assertEquals(5, calc.add(2, 3));
} Test independence means each test can run in any order and produce the same result:

No shared state between tests
Each test creates its own data and cleans up
No reliance on test execution sequence

Violation example: Test B depends on data created by Test A. If A is skipped or runs after B, B fails.
Use beforeEach/afterEach hooks to ensure a fresh state. Smoke testing (aka build verification testing) is a quick, shallow test to check if the most critical functions work:

Runs before deeper testing begins
Answers: "Does the build even work?"
Checks basic operations: app starts, login works, main page loads
Named after hardware testing — "turn it on and see if smoke comes out"

If smoke tests fail, the build is rejected immediately.

Question 6 Testing Tdd

What is the difference between assertEquals and assertSame?

assertEquals checks value equality — do two objects have the same content?
assertSame checks reference equality — are they the exact same object in memory?

Example (Java):
String a = new String("hello");
String b = new String("hello");
assertEquals(a, b); // ✅ passes
assertSame(a, b); // ❌ fails (different objects)
In Jest: toBe ≈ assertSame, toEqual ≈ assertEquals. A fake is a working implementation with simplified behavior used for testing:

Has real logic but takes shortcuts
Examples: in-memory database, fake file system, local email server
More realistic than stubs but lighter than real dependencies

Unlike mocks, fakes don't verify interactions. Unlike stubs, fakes have working business logic. Example: FakeUserRepository backed by a HashMap instead of a real database. JUnit is the standard unit testing framework for Java:

JUnit 5 (Jupiter) is the latest version
Uses annotations: @Test, @BeforeEach, @AfterAll, @DisplayName
Supports parameterized tests with @ParameterizedTest
Integrated with Maven, Gradle, and all Java IDEs

Example:
@Test void shouldAdd() {
assertEquals(5, calc.add(2, 3));
} TDD leads to better code design because:

Forces you to think about the API before implementation
Untestable code signals poor design (tight coupling, hidden dependencies)
Encourages SOLID principles, dependency injection, and small functions
Results in modular, loosely coupled code

Code that is easy to test is typically easy to maintain, extend, and understand.

Question 7 Testing Tdd

What is a dummy object in testing?

A dummy object is a placeholder that is passed around but never actually used:

Fills required parameters in method signatures
Has no behavior and no assertions on it
Simplest form of test double

Example:
const dummyLogger = {} as Logger;
const service = new UserService(realRepo, dummyLogger);
Here, dummyLogger satisfies the constructor but the test doesn't exercise logging. A spy wraps a real function, allowing it to execute normally while also recording information about its calls:

Tracks call count, arguments, return values
Does not replace the implementation (unlike mocks/stubs)
Useful for verifying side effects without changing behavior

Example in Jest:
const spy = jest.spyOn(obj, 'method');
expect(spy).toHaveBeenCalledWith('arg'); Mocha is a flexible JavaScript test framework for Node.js and browsers:

BDD-style syntax with describe and it
Requires separate assertion library (e.g., Chai)
Requires separate mocking library (e.g., Sinon)
Supports async tests with callbacks, promises, and async/await

Example:
describe('Array', () => {
  it('should return -1 when not found', () => {
    assert.equal([1,2,3].indexOf(4), -1);
  });
}); An E2E test simulates real user workflows through the entire application stack. It validates the system from the user's perspective:

Uses tools like Playwright, Cypress, or Selenium
Tests full user journeys (login → action → logout)
Slowest and most brittle test type
Catches integration issues across the whole system

Question 8 Testing Tdd

What is the Given-When-Then pattern?

Mocking replaces a real dependency with a controlled fake object that can:

Return predefined values
Track how it was called (arguments, call count)
Verify interactions between the system under test and its dependencies

Example in Jest:
const mockFn = jest.fn().mockReturnValue(42);
Mocks are useful for isolating units and testing behavior without side effects. Given-When-Then is a BDD test structuring pattern:

Given: The initial context or preconditions
When: The action or event that occurs
Then: The expected outcome

Equivalent to AAA: Given=Arrange, When=Act, Then=Assert.
Example:
Given a logged-in user
When they click "Delete Account"
Then their account is deactivated The AAA (Arrange-Act-Assert) pattern structures tests into three clear phases:

Arrange: Set up test data, mocks, and preconditions
Act: Execute the code under test
Assert: Verify the expected outcome

Example:
// Arrange
const calc = new Calculator();
// Act
const result = calc.add(2, 3);
// Assert
expect(result).toBe(5); Red-Green-Refactor is the TDD cycle:

Red: Write a test that fails (no implementation yet)
Green: Write just enough code to pass the test
Refactor: Improve code structure without changing behavior

The key rule: never write production code without a failing test first. Each iteration should be small (minutes, not hours).

Question 9 Testing Tdd

What is mutation testing?

assertEquals checks value equality — do two objects have the same content?
assertSame checks reference equality — are they the exact same object in memory?

Example (Java):
String a = new String("hello");
String b = new String("hello");
assertEquals(a, b); // ✅ passes
assertSame(a, b); // ❌ fails (different objects)
In Jest: toBe ≈ assertSame, toEqual ≈ assertEquals. Test independence means each test can run in any order and produce the same result:

No shared state between tests
Each test creates its own data and cleans up
No reliance on test execution sequence

Violation example: Test B depends on data created by Test A. If A is skipped or runs after B, B fails.
Use beforeEach/afterEach hooks to ensure a fresh state. A dummy object is a placeholder that is passed around but never actually used:

Fills required parameters in method signatures
Has no behavior and no assertions on it
Simplest form of test double

Example:
const dummyLogger = {} as Logger;
const service = new UserService(realRepo, dummyLogger);
Here, dummyLogger satisfies the constructor but the test doesn't exercise logging. Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests catch them:

Mutants: Change + to -, == to !=, remove statements
Killed mutant: A test fails (good — tests caught the bug)
Survived mutant: No test fails (bad — tests have gaps)

Mutation score = killed / total mutants.
Tools: Stryker (JS), PITest (Java), mutmut (Python).

Question 10 Testing Tdd

What is test-driven development's impact on code design?

Smoke testing (aka build verification testing) is a quick, shallow test to check if the most critical functions work:

Runs before deeper testing begins
Answers: "Does the build even work?"
Checks basic operations: app starts, login works, main page loads
Named after hardware testing — "turn it on and see if smoke comes out"

If smoke tests fail, the build is rejected immediately. TDD leads to better code design because:

Forces you to think about the API before implementation
Untestable code signals poor design (tight coupling, hidden dependencies)
Encourages SOLID principles, dependency injection, and small functions
Results in modular, loosely coupled code

Code that is easy to test is typically easy to maintain, extend, and understand. Contract testing verifies that services (consumer and provider) agree on the API interface:

Consumer-driven: Consumer defines expected interactions
Provider verifies: Provider tests against consumer contracts
Catches breaking API changes early

Tool: Pact is the most popular contract testing framework.
Unlike integration tests, each side is tested independently using the shared contract. Test coverage measures how much of your code is executed during testing. Common metrics:

Line coverage: % of lines executed
Branch coverage: % of decision branches taken
Function coverage: % of functions called
Statement coverage: % of statements executed

Tools: Istanbul/nyc (JS), coverage.py (Python), JaCoCo (Java). High coverage ≠ good tests.

Question 11 Testing Tdd

What is the difference between line coverage and branch coverage?

Strategies for managing flaky tests in CI/CD:

Quarantine: Move flaky tests to a separate suite that doesn't block deploys
Retry: Auto-retry failed tests (e.g., jest --retry 2)
Track: Log flaky test history to identify patterns
Fix root cause: Prioritize fixing over retrying
Timeout tuning: Use explicit waits, not arbitrary sleeps

Never ignore flaky tests — they erode trust in the test suite. A unit test verifies the behavior of a single, isolated piece of code (e.g., a function or method). Key characteristics:

Tests one logical unit in isolation
Dependencies are mocked or stubbed
Runs fast (milliseconds)
Deterministic and repeatable

Example in Jest:
test('add returns sum', () => { expect(add(2, 3)).toBe(5); }); A fake is a working implementation with simplified behavior used for testing:

Has real logic but takes shortcuts
Examples: in-memory database, fake file system, local email server
More realistic than stubs but lighter than real dependencies

Unlike mocks, fakes don't verify interactions. Unlike stubs, fakes have working business logic. Example: FakeUserRepository backed by a HashMap instead of a real database. Line coverage: Measures whether each line of code was executed at least once.
Branch coverage: Measures whether each branch of every decision point (if/else, switch, ternary) was taken.

Example:
if (x > 0) { doA(); } else { doB(); }
A test with x = 1 gives 50% line coverage for this block but only 50% branch coverage. You need x = -1 too for full branch coverage.

Question 12 Testing Tdd

What does "Red-Green-Refactor" mean in TDD?

TDD is a development practice where you write tests before writing production code. The cycle is:

Red: Write a failing test for the desired behavior
Green: Write the minimum code to make the test pass
Refactor: Clean up the code while keeping tests green

Benefits: better design, fewer bugs, living documentation, and confidence in refactoring. A unit test verifies the behavior of a single, isolated piece of code (e.g., a function or method). Key characteristics:

Tests one logical unit in isolation
Dependencies are mocked or stubbed
Runs fast (milliseconds)
Deterministic and repeatable

Example in Jest:
test('add returns sum', () => { expect(add(2, 3)).toBe(5); }); Red-Green-Refactor is the TDD cycle:

Red: Write a test that fails (no implementation yet)
Green: Write just enough code to pass the test
Refactor: Improve code structure without changing behavior

The key rule: never write production code without a failing test first. Each iteration should be small (minutes, not hours). Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests catch them:

Mutants: Change + to -, == to !=, remove statements
Killed mutant: A test fails (good — tests caught the bug)
Survived mutant: No test fails (bad — tests have gaps)

Mutation score = killed / total mutants.
Tools: Stryker (JS), PITest (Java), mutmut (Python).

Question 13 Testing Tdd

What is test isolation?

Acceptance testing verifies that the system meets business requirements and is ready for delivery:

User Acceptance Testing (UAT): End users validate real-world scenarios
Business Acceptance Testing: Stakeholders verify business rules
Often the final testing phase before release

Can be automated using BDD tools (Cucumber, SpecFlow) with Gherkin scenarios written by product owners. Test isolation means each test is independent and doesn't depend on or affect other tests:

No shared mutable state between tests
Tests can run in any order and still pass
Each test sets up and tears down its own data

Violations cause flaky tests — tests that pass or fail depending on execution order or timing. Use fresh fixtures and avoid global state. Given-When-Then is a BDD test structuring pattern:

Given: The initial context or preconditions
When: The action or event that occurs
Then: The expected outcome

Equivalent to AAA: Given=Arrange, When=Act, Then=Assert.
Example:
Given a logged-in user
When they click "Delete Account"
Then their account is deactivated Performance testing evaluates how a system behaves under various conditions:

Load testing: Behavior under expected load
Stress testing: Behavior beyond normal capacity
Spike testing: Sudden large load increases
Endurance testing: Sustained load over time

Metrics: response time, throughput, resource utilization.
Tools: JMeter, k6, Gatling, Locust.

Question 14 Testing Tdd

What is sanity testing?

Red-Green-Refactor is the TDD cycle:

Red: Write a test that fails (no implementation yet)
Green: Write just enough code to pass the test
Refactor: Improve code structure without changing behavior

The key rule: never write production code without a failing test first. Each iteration should be small (minutes, not hours). Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests catch them:

Mutants: Change + to -, == to !=, remove statements
Killed mutant: A test fails (good — tests caught the bug)
Survived mutant: No test fails (bad — tests have gaps)

Mutation score = killed / total mutants.
Tools: Stryker (JS), PITest (Java), mutmut (Python). Sanity testing is a focused, narrow test after a specific change to verify the fix works:

Subset of regression testing
Verifies a particular bug fix or feature change
Not exhaustive — just checks the specific area

Smoke vs Sanity:
Smoke = broad, shallow (does the whole system boot?)
Sanity = narrow, deep (does this specific fix work correctly?) A CI/CD testing strategy defines what tests run at each pipeline stage:

Pre-commit: Linting, unit tests (fast feedback)
CI build: Unit + integration tests
Staging: E2E tests, smoke tests
Pre-deploy: Contract tests, security scans
Post-deploy: Smoke tests, synthetic monitoring

Goal: shift left — catch bugs as early as possible. Fast tests run first; slow tests gate later stages.

Question 15 Testing Tdd

What is a test suite?

A test suite is a collection of related test cases grouped together:

Organized by feature, module, or test type
Can be nested (suites within suites)
Run as a unit for targeted testing

Example in Jest:
describe('UserService', () => {
  describe('createUser', () => {
    test('creates with valid data', ...);
    test('rejects invalid email', ...);
  });
}); Snapshot testing captures the output of a component or function and compares it against a stored reference:

First run: saves output as a snapshot file
Subsequent runs: compares output to saved snapshot
If different, the test fails — developer must accept or reject changes

Common in React with Jest:
expect(render(<Button />)).toMatchSnapshot();
Useful for UI testing but can become brittle if overused. An E2E test simulates real user workflows through the entire application stack. It validates the system from the user's perspective:

Uses tools like Playwright, Cypress, or Selenium
Tests full user journeys (login → action → logout)
Slowest and most brittle test type
Catches integration issues across the whole system

A unit test verifies the behavior of a single, isolated piece of code (e.g., a function or method). Key characteristics:

Tests one logical unit in isolation
Dependencies are mocked or stubbed
Runs fast (milliseconds)
Deterministic and repeatable

Example in Jest:
test('add returns sum', () => { expect(add(2, 3)).toBe(5); });

Question 16 Testing Tdd

What is test coverage?

assertEquals checks value equality — do two objects have the same content?
assertSame checks reference equality — are they the exact same object in memory?

Example (Java):
String a = new String("hello");
String b = new String("hello");
assertEquals(a, b); // ✅ passes
assertSame(a, b); // ❌ fails (different objects)
In Jest: toBe ≈ assertSame, toEqual ≈ assertEquals. Test coverage measures how much of your code is executed during testing. Common metrics:

Line coverage: % of lines executed
Branch coverage: % of decision branches taken
Function coverage: % of functions called
Statement coverage: % of statements executed

Tools: Istanbul/nyc (JS), coverage.py (Python), JaCoCo (Java). High coverage ≠ good tests. Mocking replaces a real dependency with a controlled fake object that can:

Return predefined values
Track how it was called (arguments, call count)
Verify interactions between the system under test and its dependencies

Example in Jest:
const mockFn = jest.fn().mockReturnValue(42);
Mocks are useful for isolating units and testing behavior without side effects. Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests catch them:

Mutants: Change + to -, == to !=, remove statements
Killed mutant: A test fails (good — tests caught the bug)
Survived mutant: No test fails (bad — tests have gaps)

Mutation score = killed / total mutants.
Tools: Stryker (JS), PITest (Java), mutmut (Python).

Question 17 Testing Tdd

What is test debt?

Flaky tests pass or fail intermittently without code changes. Common causes:

Shared mutable state between tests
Timing/race conditions in async code
External dependency failures (network, DB)
Order-dependent tests

Remedies:

Isolate tests properly
Use deterministic waits instead of sleep()
Mock external services
Quarantine flaky tests and fix them

BDD extends TDD by writing tests in natural language that describe behavior from a user's perspective:

Uses ubiquitous language shared by devs, QA, and stakeholders
Tests are structured as scenarios with Given-When-Then
Tools: Cucumber, SpecFlow, Behave

BDD focuses on what the system does, not how it's implemented. Test debt is a form of technical debt where the test suite becomes a liability:

Slow tests that delay CI/CD feedback
Flaky tests that erode confidence
Missing tests for critical paths
Tightly coupled tests that break on refactoring
Excessive mocking that hides real bugs

Manage it by: regularly reviewing test quality, deleting low-value tests, refactoring test code, and treating tests as production code. Mocking replaces a real dependency with a controlled fake object that can:

Return predefined values
Track how it was called (arguments, call count)
Verify interactions between the system under test and its dependencies

Example in Jest:
const mockFn = jest.fn().mockReturnValue(42);
Mocks are useful for isolating units and testing behavior without side effects.

Question 18 Testing Tdd

What is BDD (Behavior-Driven Development)?

Code coverage measures the percentage of code exercised by tests. 100% can be misleading because:

Covered ≠ tested — code may execute without meaningful assertions
Doesn't test edge cases, error handling, or concurrency
Can incentivize writing trivial tests to hit targets
Misses logical errors in covered code

Better approach: aim for meaningful coverage (80-90%) with high-quality assertions, not 100% with weak tests. BDD extends TDD by writing tests in natural language that describe behavior from a user's perspective:

Uses ubiquitous language shared by devs, QA, and stakeholders
Tests are structured as scenarios with Given-When-Then
Tools: Cucumber, SpecFlow, Behave

BDD focuses on what the system does, not how it's implemented. Mocha is a flexible JavaScript test framework for Node.js and browsers:

BDD-style syntax with describe and it
Requires separate assertion library (e.g., Chai)
Requires separate mocking library (e.g., Sinon)
Supports async tests with callbacks, promises, and async/await

Example:
describe('Array', () => {
  it('should return -1 when not found', () => {
    assert.equal([1,2,3].indexOf(4), -1);
  });
}); Snapshot testing captures the output of a component or function and compares it against a stored reference:

First run: saves output as a snapshot file
Subsequent runs: compares output to saved snapshot
If different, the test fails — developer must accept or reject changes

Common in React with Jest:
expect(render(<Button />)).toMatchSnapshot();
Useful for UI testing but can become brittle if overused.

Question 19 Testing Tdd

What is a test runner?

JUnit is the standard unit testing framework for Java:

JUnit 5 (Jupiter) is the latest version
Uses annotations: @Test, @BeforeEach, @AfterAll, @DisplayName
Supports parameterized tests with @ParameterizedTest
Integrated with Maven, Gradle, and all Java IDEs

Example:
@Test void shouldAdd() {
assertEquals(5, calc.add(2, 3));
} Red-Green-Refactor is the TDD cycle:

Red: Write a test that fails (no implementation yet)
Green: Write just enough code to pass the test
Refactor: Improve code structure without changing behavior

The key rule: never write production code without a failing test first. Each iteration should be small (minutes, not hours). A test runner is the tool that discovers, executes, and reports test results:

Finds test files by naming convention or config
Executes tests (optionally in parallel)
Reports pass/fail status and timing
Supports filtering, watching, and CI integration

Examples: jest (JS), pytest (Python), gradle test (Java), phpunit (PHP), go test (Go). Regression testing verifies that previously working features still work after code changes:

Re-runs existing test suites after modifications
Catches unintended side effects of new code
Often automated in CI/CD pipelines

Strategies:

Full regression: Run all tests
Selective regression: Run tests related to changed code
Risk-based: Prioritize tests for critical features

Question 20 Testing Tdd

What is acceptance testing?

Gherkin is a structured language for writing BDD scenarios:
Feature: User login
  Scenario: Valid credentials
    Given a registered user
    When they enter valid credentials
    Then they should see the dashboard

Keywords: Feature, Scenario, Given, When, Then, And, But. It's human-readable and executable. Sanity testing is a focused, narrow test after a specific change to verify the fix works:

Subset of regression testing
Verifies a particular bug fix or feature change
Not exhaustive — just checks the specific area

Smoke vs Sanity:
Smoke = broad, shallow (does the whole system boot?)
Sanity = narrow, deep (does this specific fix work correctly?) Acceptance testing verifies that the system meets business requirements and is ready for delivery:

User Acceptance Testing (UAT): End users validate real-world scenarios
Business Acceptance Testing: Stakeholders verify business rules
Often the final testing phase before release

Can be automated using BDD tools (Cucumber, SpecFlow) with Gherkin scenarios written by product owners. Code coverage measures the percentage of code exercised by tests. 100% can be misleading because:

Covered ≠ tested — code may execute without meaningful assertions
Doesn't test edge cases, error handling, or concurrency
Can incentivize writing trivial tests to hit targets
Misses logical errors in covered code

Better approach: aim for meaningful coverage (80-90%) with high-quality assertions, not 100% with weak tests.

Question 21 Testing Tdd

What is Mocha?

Line coverage: Measures whether each line of code was executed at least once.
Branch coverage: Measures whether each branch of every decision point (if/else, switch, ternary) was taken.

Example:
if (x > 0) { doA(); } else { doB(); }
A test with x = 1 gives 50% line coverage for this block but only 50% branch coverage. You need x = -1 too for full branch coverage. Mocha is a flexible JavaScript test framework for Node.js and browsers:

BDD-style syntax with describe and it
Requires separate assertion library (e.g., Chai)
Requires separate mocking library (e.g., Sinon)
Supports async tests with callbacks, promises, and async/await

Example:
describe('Array', () => {
  it('should return -1 when not found', () => {
    assert.equal([1,2,3].indexOf(4), -1);
  });
}); Black-box testing: Tests functionality without knowing internal implementation.

Based on requirements and specifications
Tester sees only inputs and outputs

White-box testing: Tests with knowledge of internal code structure.

Based on code paths, branches, and logic
Tester examines source code

Unit tests are often white-box; E2E tests are typically black-box. Both are needed for comprehensive coverage. A test runner is the tool that discovers, executes, and reports test results:

Finds test files by naming convention or config
Executes tests (optionally in parallel)
Reports pass/fail status and timing
Supports filtering, watching, and CI integration

Examples: jest (JS), pytest (Python), gradle test (Java), phpunit (PHP), go test (Go).

Question 22 Testing Tdd

What is CI/CD testing strategy?

Flaky tests pass or fail intermittently without code changes. Common causes:

Shared mutable state between tests
Timing/race conditions in async code
External dependency failures (network, DB)
Order-dependent tests

Remedies:

Isolate tests properly
Use deterministic waits instead of sleep()
Mock external services
Quarantine flaky tests and fix them

Load testing simulates expected concurrent users/requests to verify the system meets performance requirements:

Identifies bottlenecks under realistic conditions
Measures response time, throughput, and error rates
Establishes performance baselines

Example with k6:
export default function() {
http.get('https://api.example.com');
sleep(1);
} Shift left means moving testing activities earlier in the development lifecycle:

Write tests during development, not after
Run automated tests on every commit
Include security and performance testing early
Review testability during design

Benefits: bugs found earlier are cheaper to fix. A bug caught in development costs 10x less than one found in production. A CI/CD testing strategy defines what tests run at each pipeline stage:

Pre-commit: Linting, unit tests (fast feedback)
CI build: Unit + integration tests
Staging: E2E tests, smoke tests
Pre-deploy: Contract tests, security scans
Post-deploy: Smoke tests, synthetic monitoring

Goal: shift left — catch bugs as early as possible. Fast tests run first; slow tests gate later stages.

Question 23 Testing Tdd

What is test independence?

A test suite is a collection of related test cases grouped together:

Organized by feature, module, or test type
Can be nested (suites within suites)
Run as a unit for targeted testing

Example in Jest:
describe('UserService', () => {
  describe('createUser', () => {
    test('creates with valid data', ...);
    test('rejects invalid email', ...);
  });
}); Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests catch them:

Mutants: Change + to -, == to !=, remove statements
Killed mutant: A test fails (good — tests caught the bug)
Survived mutant: No test fails (bad — tests have gaps)

Mutation score = killed / total mutants.
Tools: Stryker (JS), PITest (Java), mutmut (Python). Test independence means each test can run in any order and produce the same result:

No shared state between tests
Each test creates its own data and cleans up
No reliance on test execution sequence

Violation example: Test B depends on data created by Test A. If A is skipped or runs after B, B fails.
Use beforeEach/afterEach hooks to ensure a fresh state. The AAA (Arrange-Act-Assert) pattern structures tests into three clear phases:

Arrange: Set up test data, mocks, and preconditions
Act: Execute the code under test
Assert: Verify the expected outcome

Example:
// Arrange
const calc = new Calculator();
// Act
const result = calc.add(2, 3);
// Assert
expect(result).toBe(5);

Question 24 Testing Tdd

What is an integration test?

An integration test verifies that multiple components work correctly together. Unlike unit tests, it exercises real interactions:

Tests communication between modules, services, or layers
May use real databases, APIs, or file systems
Slower than unit tests but catches interface bugs
Example: testing a controller that queries a real database

A unit test verifies the behavior of a single, isolated piece of code (e.g., a function or method). Key characteristics:

Tests one logical unit in isolation
Dependencies are mocked or stubbed
Runs fast (milliseconds)
Deterministic and repeatable

Example in Jest:
test('add returns sum', () => { expect(add(2, 3)).toBe(5); }); Acceptance testing verifies that the system meets business requirements and is ready for delivery:

User Acceptance Testing (UAT): End users validate real-world scenarios
Business Acceptance Testing: Stakeholders verify business rules
Often the final testing phase before release

Can be automated using BDD tools (Cucumber, SpecFlow) with Gherkin scenarios written by product owners. Assertions verify expected outcomes. Matchers are methods that define how values are compared:

toBe(value) — strict equality
toEqual(obj) — deep equality
toContain(item) — array/string inclusion
toThrow() — exception thrown
toBeGreaterThan(n) — numeric comparison
toMatch(/regex/) — pattern matching

Frameworks: Jest, Chai, AssertJ, Hamcrest.

Question 25 Testing Tdd

What is performance testing?

Code coverage measures the percentage of code exercised by tests. 100% can be misleading because:

Covered ≠ tested — code may execute without meaningful assertions
Doesn't test edge cases, error handling, or concurrency
Can incentivize writing trivial tests to hit targets
Misses logical errors in covered code

Better approach: aim for meaningful coverage (80-90%) with high-quality assertions, not 100% with weak tests. Performance testing evaluates how a system behaves under various conditions:

Load testing: Behavior under expected load
Stress testing: Behavior beyond normal capacity
Spike testing: Sudden large load increases
Endurance testing: Sustained load over time

Metrics: response time, throughput, resource utilization.
Tools: JMeter, k6, Gatling, Locust. Test doubles replace real dependencies in tests:

Dummy: Passed around but never used (fills parameter lists)
Stub: Provides canned responses to calls
Spy: Records calls while executing real logic
Mock: Pre-programmed with expectations to verify behavior
Fake: Working implementation with shortcuts (e.g., in-memory database)

Term coined by Gerard Meszaros in xUnit Test Patterns. JUnit is the standard unit testing framework for Java:

JUnit 5 (Jupiter) is the latest version
Uses annotations: @Test, @BeforeEach, @AfterAll, @DisplayName
Supports parameterized tests with @ParameterizedTest
Integrated with Maven, Gradle, and all Java IDEs

Example:
@Test void shouldAdd() {
assertEquals(5, calc.add(2, 3));
}

Question 26 Testing Tdd

What is the difference between a mock and a stub?

Shift left means moving testing activities earlier in the development lifecycle:

Write tests during development, not after
Run automated tests on every commit
Include security and performance testing early
Review testability during design

Benefits: bugs found earlier are cheaper to fix. A bug caught in development costs 10x less than one found in production. BDD extends TDD by writing tests in natural language that describe behavior from a user's perspective:

Uses ubiquitous language shared by devs, QA, and stakeholders
Tests are structured as scenarios with Given-When-Then
Tools: Cucumber, SpecFlow, Behave

BDD focuses on what the system does, not how it's implemented. Stub: Provides canned answers to calls. Used for state verification — you check the result.
Mock: Pre-programmed with expectations. Used for behavior verification — you check that specific methods were called.

Example:

Stub: getUser() always returns { name: "Alice" }
Mock: Asserts getUser() was called exactly once with ID 5

Parameterized testing runs the same test logic with different input/output pairs:

Reduces code duplication for similar test cases
Each parameter set is a separate test case

Jest example:
test.each([
  [1, 2, 3],
  [0, 0, 0],
])('add(%i, %i) = %i', (a, b, expected) => {
  expect(add(a, b)).toBe(expected);
});
Also available in JUnit (@ParameterizedTest), pytest (@pytest.mark.parametrize).

Question 27 Testing Tdd

What is a unit test?

A unit test verifies the behavior of a single, isolated piece of code (e.g., a function or method). Key characteristics:

Tests one logical unit in isolation
Dependencies are mocked or stubbed
Runs fast (milliseconds)
Deterministic and repeatable

Example in Jest:
test('add returns sum', () => { expect(add(2, 3)).toBe(5); }); Regression testing verifies that previously working features still work after code changes:

Re-runs existing test suites after modifications
Catches unintended side effects of new code
Often automated in CI/CD pipelines

Strategies:

Full regression: Run all tests
Selective regression: Run tests related to changed code
Risk-based: Prioritize tests for critical features

BDD extends TDD by writing tests in natural language that describe behavior from a user's perspective:

Uses ubiquitous language shared by devs, QA, and stakeholders
Tests are structured as scenarios with Given-When-Then
Tools: Cucumber, SpecFlow, Behave

BDD focuses on what the system does, not how it's implemented. A spy wraps a real function, allowing it to execute normally while also recording information about its calls:

Tracks call count, arguments, return values
Does not replace the implementation (unlike mocks/stubs)
Useful for verifying side effects without changing behavior

Example in Jest:
const spy = jest.spyOn(obj, 'method');
expect(spy).toHaveBeenCalledWith('arg');

Question 28 Testing Tdd

How do you handle flaky tests in CI/CD?

Strategies for managing flaky tests in CI/CD:

Quarantine: Move flaky tests to a separate suite that doesn't block deploys
Retry: Auto-retry failed tests (e.g., jest --retry 2)
Track: Log flaky test history to identify patterns
Fix root cause: Prioritize fixing over retrying
Timeout tuning: Use explicit waits, not arbitrary sleeps

Never ignore flaky tests — they erode trust in the test suite. TDD is a development practice where you write tests before writing production code. The cycle is:

Red: Write a failing test for the desired behavior
Green: Write the minimum code to make the test pass
Refactor: Clean up the code while keeping tests green

Benefits: better design, fewer bugs, living documentation, and confidence in refactoring. Mocha is a flexible JavaScript test framework for Node.js and browsers:

BDD-style syntax with describe and it
Requires separate assertion library (e.g., Chai)
Requires separate mocking library (e.g., Sinon)
Supports async tests with callbacks, promises, and async/await

Example:
describe('Array', () => {
  it('should return -1 when not found', () => {
    assert.equal([1,2,3].indexOf(4), -1);
  });
}); A test suite is a collection of related test cases grouped together:

Organized by feature, module, or test type
Can be nested (suites within suites)
Run as a unit for targeted testing

Example in Jest:
describe('UserService', () => {
  describe('createUser', () => {
    test('creates with valid data', ...);
    test('rejects invalid email', ...);
  });
});

Question 29 Testing Tdd

What is snapshot testing?

Test fixtures provide a fixed, known environment for tests. They include:

Predefined data (database records, files)
Object instances in a known state
Environment configuration

Setup/teardown hooks manage fixtures:
beforeEach() / afterEach() — per test
beforeAll() / afterAll() — per suite
Good fixtures are isolated, repeatable, and independent of test execution order. Snapshot testing captures the output of a component or function and compares it against a stored reference:

First run: saves output as a snapshot file
Subsequent runs: compares output to saved snapshot
If different, the test fails — developer must accept or reject changes

Common in React with Jest:
expect(render(<Button />)).toMatchSnapshot();
Useful for UI testing but can become brittle if overused. Test doubles replace real dependencies in tests:

Dummy: Passed around but never used (fills parameter lists)
Stub: Provides canned responses to calls
Spy: Records calls while executing real logic
Mock: Pre-programmed with expectations to verify behavior
Fake: Working implementation with shortcuts (e.g., in-memory database)

Term coined by Gerard Meszaros in xUnit Test Patterns. assertEquals checks value equality — do two objects have the same content?
assertSame checks reference equality — are they the exact same object in memory?

Example (Java):
String a = new String("hello");
String b = new String("hello");
assertEquals(a, b); // ✅ passes
assertSame(a, b); // ❌ fails (different objects)
In Jest: toBe ≈ assertSame, toEqual ≈ assertEquals.

Question 30 Testing Tdd

What is the AAA pattern in testing?

The AAA (Arrange-Act-Assert) pattern structures tests into three clear phases:

Arrange: Set up test data, mocks, and preconditions
Act: Execute the code under test
Assert: Verify the expected outcome

Example:
// Arrange
const calc = new Calculator();
// Act
const result = calc.add(2, 3);
// Assert
expect(result).toBe(5); A test runner is the tool that discovers, executes, and reports test results:

Finds test files by naming convention or config
Executes tests (optionally in parallel)
Reports pass/fail status and timing
Supports filtering, watching, and CI integration

Examples: jest (JS), pytest (Python), gradle test (Java), phpunit (PHP), go test (Go). TDD is a development practice where you write tests before writing production code. The cycle is:

Red: Write a failing test for the desired behavior
Green: Write the minimum code to make the test pass
Refactor: Clean up the code while keeping tests green

Benefits: better design, fewer bugs, living documentation, and confidence in refactoring. Assertions verify expected outcomes. Matchers are methods that define how values are compared:

toBe(value) — strict equality
toEqual(obj) — deep equality
toContain(item) — array/string inclusion
toThrow() — exception thrown
toBeGreaterThan(n) — numeric comparison
toMatch(/regex/) — pattern matching

Frameworks: Jest, Chai, AssertJ, Hamcrest.

Question 31 Testing Tdd

What is Gherkin syntax in BDD?

assertEquals checks value equality — do two objects have the same content?
assertSame checks reference equality — are they the exact same object in memory?

Example (Java):
String a = new String("hello");
String b = new String("hello");
assertEquals(a, b); // ✅ passes
assertSame(a, b); // ❌ fails (different objects)
In Jest: toBe ≈ assertSame, toEqual ≈ assertEquals. Gherkin is a structured language for writing BDD scenarios:
Feature: User login
  Scenario: Valid credentials
    Given a registered user
    When they enter valid credentials
    Then they should see the dashboard

Keywords: Feature, Scenario, Given, When, Then, And, But. It's human-readable and executable. Test independence means each test can run in any order and produce the same result:

No shared state between tests
Each test creates its own data and cleans up
No reliance on test execution sequence

Violation example: Test B depends on data created by Test A. If A is skipped or runs after B, B fails.
Use beforeEach/afterEach hooks to ensure a fresh state. Test doubles replace real dependencies in tests:

Dummy: Passed around but never used (fills parameter lists)
Stub: Provides canned responses to calls
Spy: Records calls while executing real logic
Mock: Pre-programmed with expectations to verify behavior
Fake: Working implementation with shortcuts (e.g., in-memory database)

Term coined by Gerard Meszaros in xUnit Test Patterns.

Question 32 Testing Tdd

What is parameterized testing?

Parameterized testing runs the same test logic with different input/output pairs:

Reduces code duplication for similar test cases
Each parameter set is a separate test case

Jest example:
test.each([
  [1, 2, 3],
  [0, 0, 0],
])('add(%i, %i) = %i', (a, b, expected) => {
  expect(add(a, b)).toBe(expected);
});
Also available in JUnit (@ParameterizedTest), pytest (@pytest.mark.parametrize). Smoke testing (aka build verification testing) is a quick, shallow test to check if the most critical functions work:

Runs before deeper testing begins
Answers: "Does the build even work?"
Checks basic operations: app starts, login works, main page loads
Named after hardware testing — "turn it on and see if smoke comes out"

If smoke tests fail, the build is rejected immediately. Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests catch them:

Mutants: Change + to -, == to !=, remove statements
Killed mutant: A test fails (good — tests caught the bug)
Survived mutant: No test fails (bad — tests have gaps)

Mutation score = killed / total mutants.
Tools: Stryker (JS), PITest (Java), mutmut (Python). An integration test verifies that multiple components work correctly together. Unlike unit tests, it exercises real interactions:

Tests communication between modules, services, or layers
May use real databases, APIs, or file systems
Slower than unit tests but catches interface bugs
Example: testing a controller that queries a real database

Question 33 Testing Tdd

What is regression testing?

assertEquals checks value equality — do two objects have the same content?
assertSame checks reference equality — are they the exact same object in memory?

Example (Java):
String a = new String("hello");
String b = new String("hello");
assertEquals(a, b); // ✅ passes
assertSame(a, b); // ❌ fails (different objects)
In Jest: toBe ≈ assertSame, toEqual ≈ assertEquals. Regression testing verifies that previously working features still work after code changes:

Re-runs existing test suites after modifications
Catches unintended side effects of new code
Often automated in CI/CD pipelines

Strategies:

Full regression: Run all tests
Selective regression: Run tests related to changed code
Risk-based: Prioritize tests for critical features

Gherkin is a structured language for writing BDD scenarios:
Feature: User login
  Scenario: Valid credentials
    Given a registered user
    When they enter valid credentials
    Then they should see the dashboard

Keywords: Feature, Scenario, Given, When, Then, And, But. It's human-readable and executable. A fake is a working implementation with simplified behavior used for testing:

Has real logic but takes shortcuts
Examples: in-memory database, fake file system, local email server
More realistic than stubs but lighter than real dependencies

Unlike mocks, fakes don't verify interactions. Unlike stubs, fakes have working business logic. Example: FakeUserRepository backed by a HashMap instead of a real database.

Question 34 Testing Tdd

What is setup and teardown in testing?

Setup prepares the test environment before tests run. Teardown cleans up afterward.

beforeEach: Runs before each test (reset state)
afterEach: Runs after each test (cleanup)
beforeAll: Runs once before the suite
afterAll: Runs once after the suite

Purpose: ensure test isolation — each test starts with a clean slate and doesn't affect other tests. Given-When-Then is a BDD test structuring pattern:

Given: The initial context or preconditions
When: The action or event that occurs
Then: The expected outcome

Equivalent to AAA: Given=Arrange, When=Act, Then=Assert.
Example:
Given a logged-in user
When they click "Delete Account"
Then their account is deactivated BDD extends TDD by writing tests in natural language that describe behavior from a user's perspective:

Uses ubiquitous language shared by devs, QA, and stakeholders
Tests are structured as scenarios with Given-When-Then
Tools: Cucumber, SpecFlow, Behave

BDD focuses on what the system does, not how it's implemented. Load testing simulates expected concurrent users/requests to verify the system meets performance requirements:

Identifies bottlenecks under realistic conditions
Measures response time, throughput, and error rates
Establishes performance baselines

Example with k6:
export default function() {
http.get('https://api.example.com');
sleep(1);
}

Question 35 Testing Tdd

What is path coverage?

Test coverage measures how much of your code is executed during testing. Common metrics:

Line coverage: % of lines executed
Branch coverage: % of decision branches taken
Function coverage: % of functions called
Statement coverage: % of statements executed

Tools: Istanbul/nyc (JS), coverage.py (Python), JaCoCo (Java). High coverage ≠ good tests. An integration test verifies that multiple components work correctly together. Unlike unit tests, it exercises real interactions:

Tests communication between modules, services, or layers
May use real databases, APIs, or file systems
Slower than unit tests but catches interface bugs
Example: testing a controller that queries a real database

pytest is a popular Python testing framework known for its simplicity:

Uses plain assert statements (no special API)
Auto-discovers test files and functions
Powerful fixtures with dependency injection
Rich plugin ecosystem (pytest-cov, pytest-mock, pytest-xdist)

Example:
def test_add():
assert add(2, 3) == 5
Run with: pytest -v Path coverage measures whether every possible execution path through a function has been tested. It considers all combinations of branches:

More thorough than branch coverage
Number of paths grows exponentially with branches
Often impractical for complex functions

For n independent if statements, there are 2^n paths. It's the most rigorous coverage metric but rarely achievable at 100%.

Question 36 Testing Tdd

What is TDD (Test-Driven Development)?

The AAA (Arrange-Act-Assert) pattern structures tests into three clear phases:

Arrange: Set up test data, mocks, and preconditions
Act: Execute the code under test
Assert: Verify the expected outcome

Example:
// Arrange
const calc = new Calculator();
// Act
const result = calc.add(2, 3);
// Assert
expect(result).toBe(5); Gherkin is a structured language for writing BDD scenarios:
Feature: User login
  Scenario: Valid credentials
    Given a registered user
    When they enter valid credentials
    Then they should see the dashboard

Keywords: Feature, Scenario, Given, When, Then, And, But. It's human-readable and executable. TDD is a development practice where you write tests before writing production code. The cycle is:

Red: Write a failing test for the desired behavior
Green: Write the minimum code to make the test pass
Refactor: Clean up the code while keeping tests green

Benefits: better design, fewer bugs, living documentation, and confidence in refactoring. A dummy object is a placeholder that is passed around but never actually used:

Fills required parameters in method signatures
Has no behavior and no assertions on it
Simplest form of test double

Example:
const dummyLogger = {} as Logger;
const service = new UserService(realRepo, dummyLogger);
Here, dummyLogger satisfies the constructor but the test doesn't exercise logging.

Question 37 Testing Tdd

What is Jest?

Jest is a JavaScript testing framework by Meta (Facebook):

Zero-config setup for most JS projects
Built-in mocking, spying, and assertion library
Snapshot testing support
Code coverage reporting via --coverage
Parallel test execution for speed

Example:
describe('math', () => {
  test('adds numbers', () => {
    expect(1 + 2).toBe(3);
  });
}); Test isolation means each test is independent and doesn't depend on or affect other tests:

No shared mutable state between tests
Tests can run in any order and still pass
Each test sets up and tears down its own data

Violations cause flaky tests — tests that pass or fail depending on execution order or timing. Use fresh fixtures and avoid global state. A test suite is a collection of related test cases grouped together:

Organized by feature, module, or test type
Can be nested (suites within suites)
Run as a unit for targeted testing

Example in Jest:
describe('UserService', () => {
  describe('createUser', () => {
    test('creates with valid data', ...);
    test('rejects invalid email', ...);
  });
}); Setup prepares the test environment before tests run. Teardown cleans up afterward.

beforeEach: Runs before each test (reset state)
afterEach: Runs after each test (cleanup)
beforeAll: Runs once before the suite
afterAll: Runs once after the suite

Purpose: ensure test isolation — each test starts with a clean slate and doesn't affect other tests.

Question 38 Testing Tdd

What are the five types of test doubles?

A dummy object is a placeholder that is passed around but never actually used:

Fills required parameters in method signatures
Has no behavior and no assertions on it
Simplest form of test double

Example:
const dummyLogger = {} as Logger;
const service = new UserService(realRepo, dummyLogger);
Here, dummyLogger satisfies the constructor but the test doesn't exercise logging. Test doubles replace real dependencies in tests:

Dummy: Passed around but never used (fills parameter lists)
Stub: Provides canned responses to calls
Spy: Records calls while executing real logic
Mock: Pre-programmed with expectations to verify behavior
Fake: Working implementation with shortcuts (e.g., in-memory database)

Term coined by Gerard Meszaros in xUnit Test Patterns. TDD leads to better code design because:

Forces you to think about the API before implementation
Untestable code signals poor design (tight coupling, hidden dependencies)
Encourages SOLID principles, dependency injection, and small functions
Results in modular, loosely coupled code

Code that is easy to test is typically easy to maintain, extend, and understand. JUnit is the standard unit testing framework for Java:

JUnit 5 (Jupiter) is the latest version
Uses annotations: @Test, @BeforeEach, @AfterAll, @DisplayName
Supports parameterized tests with @ParameterizedTest
Integrated with Maven, Gradle, and all Java IDEs

Example:
@Test void shouldAdd() {
assertEquals(5, calc.add(2, 3));
}

Question 39 Testing Tdd

What are test fixtures?

Test fixtures provide a fixed, known environment for tests. They include:

Predefined data (database records, files)
Object instances in a known state
Environment configuration

Setup/teardown hooks manage fixtures:
beforeEach() / afterEach() — per test
beforeAll() / afterAll() — per suite
Good fixtures are isolated, repeatable, and independent of test execution order. Strategies for managing flaky tests in CI/CD:

Quarantine: Move flaky tests to a separate suite that doesn't block deploys
Retry: Auto-retry failed tests (e.g., jest --retry 2)
Track: Log flaky test history to identify patterns
Fix root cause: Prioritize fixing over retrying
Timeout tuning: Use explicit waits, not arbitrary sleeps

Never ignore flaky tests — they erode trust in the test suite. Contract testing verifies that services (consumer and provider) agree on the API interface:

Consumer-driven: Consumer defines expected interactions
Provider verifies: Provider tests against consumer contracts
Catches breaking API changes early

Tool: Pact is the most popular contract testing framework.
Unlike integration tests, each side is tested independently using the shared contract. A dummy object is a placeholder that is passed around but never actually used:

Fills required parameters in method signatures
Has no behavior and no assertions on it
Simplest form of test double

Example:
const dummyLogger = {} as Logger;
const service = new UserService(realRepo, dummyLogger);
Here, dummyLogger satisfies the constructor but the test doesn't exercise logging.

Question 40 Testing Tdd

What is the difference between black-box and white-box testing?

Path coverage measures whether every possible execution path through a function has been tested. It considers all combinations of branches:

More thorough than branch coverage
Number of paths grows exponentially with branches
Often impractical for complex functions

For n independent if statements, there are 2^n paths. It's the most rigorous coverage metric but rarely achievable at 100%. Black-box testing: Tests functionality without knowing internal implementation.

Based on requirements and specifications
Tester sees only inputs and outputs

White-box testing: Tests with knowledge of internal code structure.

Based on code paths, branches, and logic
Tester examines source code

Unit tests are often white-box; E2E tests are typically black-box. Both are needed for comprehensive coverage. Assertions verify expected outcomes. Matchers are methods that define how values are compared:

toBe(value) — strict equality
toEqual(obj) — deep equality
toContain(item) — array/string inclusion
toThrow() — exception thrown
toBeGreaterThan(n) — numeric comparison
toMatch(/regex/) — pattern matching

Frameworks: Jest, Chai, AssertJ, Hamcrest. The AAA (Arrange-Act-Assert) pattern structures tests into three clear phases:

Arrange: Set up test data, mocks, and preconditions
Act: Execute the code under test
Assert: Verify the expected outcome

Example:
// Arrange
const calc = new Calculator();
// Act
const result = calc.add(2, 3);
// Assert
expect(result).toBe(5);

Question 41 Testing Tdd

What is a fake in testing?

Test fixtures provide a fixed, known environment for tests. They include:

Predefined data (database records, files)
Object instances in a known state
Environment configuration

Setup/teardown hooks manage fixtures:
beforeEach() / afterEach() — per test
beforeAll() / afterAll() — per suite
Good fixtures are isolated, repeatable, and independent of test execution order. A fake is a working implementation with simplified behavior used for testing:

Has real logic but takes shortcuts
Examples: in-memory database, fake file system, local email server
More realistic than stubs but lighter than real dependencies

Unlike mocks, fakes don't verify interactions. Unlike stubs, fakes have working business logic. Example: FakeUserRepository backed by a HashMap instead of a real database. Flaky tests pass or fail intermittently without code changes. Common causes:

Shared mutable state between tests
Timing/race conditions in async code
External dependency failures (network, DB)
Order-dependent tests

Remedies:

Isolate tests properly
Use deterministic waits instead of sleep()
Mock external services
Quarantine flaky tests and fix them

Path coverage measures whether every possible execution path through a function has been tested. It considers all combinations of branches:

More thorough than branch coverage
Number of paths grows exponentially with branches
Often impractical for complex functions

For n independent if statements, there are 2^n paths. It's the most rigorous coverage metric but rarely achievable at 100%.

Question 42 Testing Tdd

What is property-based testing?

Parameterized testing runs the same test logic with different input/output pairs:

Reduces code duplication for similar test cases
Each parameter set is a separate test case

Jest example:
test.each([
  [1, 2, 3],
  [0, 0, 0],
])('add(%i, %i) = %i', (a, b, expected) => {
  expect(add(a, b)).toBe(expected);
});
Also available in JUnit (@ParameterizedTest), pytest (@pytest.mark.parametrize). Property-based testing generates random inputs to verify that properties (invariants) hold for all cases:

Instead of specific examples, you define properties the code must satisfy
The framework generates hundreds/thousands of test cases
On failure, it shrinks the input to the minimal failing case

Tools: QuickCheck (Haskell), Hypothesis (Python), fast-check (JS).
Example property: reverse(reverse(list)) == list Strategies for managing flaky tests in CI/CD:

Quarantine: Move flaky tests to a separate suite that doesn't block deploys
Retry: Auto-retry failed tests (e.g., jest --retry 2)
Track: Log flaky test history to identify patterns
Fix root cause: Prioritize fixing over retrying
Timeout tuning: Use explicit waits, not arbitrary sleeps

Never ignore flaky tests — they erode trust in the test suite. pytest is a popular Python testing framework known for its simplicity:

Uses plain assert statements (no special API)
Auto-discovers test files and functions
Powerful fixtures with dependency injection
Rich plugin ecosystem (pytest-cov, pytest-mock, pytest-xdist)

Example:
def test_add():
assert add(2, 3) == 5
Run with: pytest -v

Question 43 Testing Tdd

What is load testing?

Mocking replaces a real dependency with a controlled fake object that can:

Return predefined values
Track how it was called (arguments, call count)
Verify interactions between the system under test and its dependencies

Example in Jest:
const mockFn = jest.fn().mockReturnValue(42);
Mocks are useful for isolating units and testing behavior without side effects. Path coverage measures whether every possible execution path through a function has been tested. It considers all combinations of branches:

More thorough than branch coverage
Number of paths grows exponentially with branches
Often impractical for complex functions

For n independent if statements, there are 2^n paths. It's the most rigorous coverage metric but rarely achievable at 100%. Load testing simulates expected concurrent users/requests to verify the system meets performance requirements:

Identifies bottlenecks under realistic conditions
Measures response time, throughput, and error rates
Establishes performance baselines

Example with k6:
export default function() {
http.get('https://api.example.com');
sleep(1);
} Test coverage measures how much of your code is executed during testing. Common metrics:

Line coverage: % of lines executed
Branch coverage: % of decision branches taken
Function coverage: % of functions called
Statement coverage: % of statements executed

Tools: Istanbul/nyc (JS), coverage.py (Python), JaCoCo (Java). High coverage ≠ good tests.

Question 44 Testing Tdd

What is JUnit?

JUnit is the standard unit testing framework for Java:

JUnit 5 (Jupiter) is the latest version
Uses annotations: @Test, @BeforeEach, @AfterAll, @DisplayName
Supports parameterized tests with @ParameterizedTest
Integrated with Maven, Gradle, and all Java IDEs

Example:
@Test void shouldAdd() {
assertEquals(5, calc.add(2, 3));
} Stub: Provides canned answers to calls. Used for state verification — you check the result.
Mock: Pre-programmed with expectations. Used for behavior verification — you check that specific methods were called.

Example:

Stub: getUser() always returns { name: "Alice" }
Mock: Asserts getUser() was called exactly once with ID 5

Line coverage: Measures whether each line of code was executed at least once.
Branch coverage: Measures whether each branch of every decision point (if/else, switch, ternary) was taken.

Example:
if (x > 0) { doA(); } else { doB(); }
A test with x = 1 gives 50% line coverage for this block but only 50% branch coverage. You need x = -1 too for full branch coverage. Strategies for managing flaky tests in CI/CD:

Quarantine: Move flaky tests to a separate suite that doesn't block deploys
Retry: Auto-retry failed tests (e.g., jest --retry 2)
Track: Log flaky test history to identify patterns
Fix root cause: Prioritize fixing over retrying
Timeout tuning: Use explicit waits, not arbitrary sleeps

Never ignore flaky tests — they erode trust in the test suite.

Question 45 Testing Tdd

What is contract testing?

A dummy object is a placeholder that is passed around but never actually used:

Fills required parameters in method signatures
Has no behavior and no assertions on it
Simplest form of test double

Example:
const dummyLogger = {} as Logger;
const service = new UserService(realRepo, dummyLogger);
Here, dummyLogger satisfies the constructor but the test doesn't exercise logging. Assertions verify expected outcomes. Matchers are methods that define how values are compared:

toBe(value) — strict equality
toEqual(obj) — deep equality
toContain(item) — array/string inclusion
toThrow() — exception thrown
toBeGreaterThan(n) — numeric comparison
toMatch(/regex/) — pattern matching

Frameworks: Jest, Chai, AssertJ, Hamcrest. Contract testing verifies that services (consumer and provider) agree on the API interface:

Consumer-driven: Consumer defines expected interactions
Provider verifies: Provider tests against consumer contracts
Catches breaking API changes early

Tool: Pact is the most popular contract testing framework.
Unlike integration tests, each side is tested independently using the shared contract. Regression testing verifies that previously working features still work after code changes:

Re-runs existing test suites after modifications
Catches unintended side effects of new code
Often automated in CI/CD pipelines

Strategies:

Full regression: Run all tests
Selective regression: Run tests related to changed code
Risk-based: Prioritize tests for critical features

Question 46 Testing Tdd

What is pytest?

Mocha is a flexible JavaScript test framework for Node.js and browsers:

BDD-style syntax with describe and it
Requires separate assertion library (e.g., Chai)
Requires separate mocking library (e.g., Sinon)
Supports async tests with callbacks, promises, and async/await

Example:
describe('Array', () => {
  it('should return -1 when not found', () => {
    assert.equal([1,2,3].indexOf(4), -1);
  });
}); TDD leads to better code design because:

Forces you to think about the API before implementation
Untestable code signals poor design (tight coupling, hidden dependencies)
Encourages SOLID principles, dependency injection, and small functions
Results in modular, loosely coupled code

Code that is easy to test is typically easy to maintain, extend, and understand. pytest is a popular Python testing framework known for its simplicity:

Uses plain assert statements (no special API)
Auto-discovers test files and functions
Powerful fixtures with dependency injection
Rich plugin ecosystem (pytest-cov, pytest-mock, pytest-xdist)

Example:
def test_add():
assert add(2, 3) == 5
Run with: pytest -v Flaky tests pass or fail intermittently without code changes. Common causes:

Shared mutable state between tests
Timing/race conditions in async code
External dependency failures (network, DB)
Order-dependent tests

Remedies:

Isolate tests properly
Use deterministic waits instead of sleep()
Mock external services
Quarantine flaky tests and fix them

Question 47 Testing Tdd

What is mocking in testing?

Given-When-Then is a BDD test structuring pattern:

Given: The initial context or preconditions
When: The action or event that occurs
Then: The expected outcome

Equivalent to AAA: Given=Arrange, When=Act, Then=Assert.
Example:
Given a logged-in user
When they click "Delete Account"
Then their account is deactivated Mocking replaces a real dependency with a controlled fake object that can:

Return predefined values
Track how it was called (arguments, call count)
Verify interactions between the system under test and its dependencies

Example in Jest:
const mockFn = jest.fn().mockReturnValue(42);
Mocks are useful for isolating units and testing behavior without side effects. The Test Pyramid is a testing strategy that recommends:

Base (most): Unit tests — fast, cheap, numerous
Middle: Integration tests — moderate speed and count
Top (fewest): E2E tests — slow, expensive, few

The idea is to have many small, fast tests and fewer large, slow ones. This gives fast feedback while still covering the full stack. Coined by Mike Cohn. Test coverage measures how much of your code is executed during testing. Common metrics:

Line coverage: % of lines executed
Branch coverage: % of decision branches taken
Function coverage: % of functions called
Statement coverage: % of statements executed

Tools: Istanbul/nyc (JS), coverage.py (Python), JaCoCo (Java). High coverage ≠ good tests.

Question 48 Testing Tdd

What is the Test Pyramid?

Stub: Provides canned answers to calls. Used for state verification — you check the result.
Mock: Pre-programmed with expectations. Used for behavior verification — you check that specific methods were called.

Example:

Stub: getUser() always returns { name: "Alice" }
Mock: Asserts getUser() was called exactly once with ID 5

A unit test verifies the behavior of a single, isolated piece of code (e.g., a function or method). Key characteristics:

Tests one logical unit in isolation
Dependencies are mocked or stubbed
Runs fast (milliseconds)
Deterministic and repeatable

Example in Jest:
test('add returns sum', () => { expect(add(2, 3)).toBe(5); }); The Test Pyramid is a testing strategy that recommends:

Base (most): Unit tests — fast, cheap, numerous
Middle: Integration tests — moderate speed and count
Top (fewest): E2E tests — slow, expensive, few

The idea is to have many small, fast tests and fewer large, slow ones. This gives fast feedback while still covering the full stack. Coined by Mike Cohn. Parameterized testing runs the same test logic with different input/output pairs:

Reduces code duplication for similar test cases
Each parameter set is a separate test case

Jest example:
test.each([
  [1, 2, 3],
  [0, 0, 0],
])('add(%i, %i) = %i', (a, b, expected) => {
  expect(add(a, b)).toBe(expected);
});
Also available in JUnit (@ParameterizedTest), pytest (@pytest.mark.parametrize).

Question 49 Testing Tdd

What does "shift left" mean in testing?

Black-box testing: Tests functionality without knowing internal implementation.

Based on requirements and specifications
Tester sees only inputs and outputs

White-box testing: Tests with knowledge of internal code structure.

Based on code paths, branches, and logic
Tester examines source code

Unit tests are often white-box; E2E tests are typically black-box. Both are needed for comprehensive coverage. Test debt is a form of technical debt where the test suite becomes a liability:

Slow tests that delay CI/CD feedback
Flaky tests that erode confidence
Missing tests for critical paths
Tightly coupled tests that break on refactoring
Excessive mocking that hides real bugs

Manage it by: regularly reviewing test quality, deleting low-value tests, refactoring test code, and treating tests as production code. Stub: Provides canned answers to calls. Used for state verification — you check the result.
Mock: Pre-programmed with expectations. Used for behavior verification — you check that specific methods were called.

Example:

Stub: getUser() always returns { name: "Alice" }
Mock: Asserts getUser() was called exactly once with ID 5

Shift left means moving testing activities earlier in the development lifecycle:

Write tests during development, not after
Run automated tests on every commit
Include security and performance testing early
Review testability during design

Benefits: bugs found earlier are cheaper to fix. A bug caught in development costs 10x less than one found in production.

Question 50 Testing Tdd

What are assertion patterns and matchers?

Load testing simulates expected concurrent users/requests to verify the system meets performance requirements:

Identifies bottlenecks under realistic conditions
Measures response time, throughput, and error rates
Establishes performance baselines

Example with k6:
export default function() {
http.get('https://api.example.com');
sleep(1);
} A dummy object is a placeholder that is passed around but never actually used:

Fills required parameters in method signatures
Has no behavior and no assertions on it
Simplest form of test double

Example:
const dummyLogger = {} as Logger;
const service = new UserService(realRepo, dummyLogger);
Here, dummyLogger satisfies the constructor but the test doesn't exercise logging. Assertions verify expected outcomes. Matchers are methods that define how values are compared:

toBe(value) — strict equality
toEqual(obj) — deep equality
toContain(item) — array/string inclusion
toThrow() — exception thrown
toBeGreaterThan(n) — numeric comparison
toMatch(/regex/) — pattern matching

Frameworks: Jest, Chai, AssertJ, Hamcrest. TDD is a development practice where you write tests before writing production code. The cycle is:

Red: Write a failing test for the desired behavior
Green: Write the minimum code to make the test pass
Refactor: Clean up the code while keeping tests green

Benefits: better design, fewer bugs, living documentation, and confidence in refactoring.