# Qs: Testing

***

## Why Testing?

Reduction in bugs reported after deployments, which led to faster release cycles and improved customer satisfaction.

Instill a culture of quality within the team.

***

## How would you implement a more robust testing strategy?

Included both `unit tests` and `end-to-end tests`.

Assess current testing practices and identify key areas where additional testing could be most beneficial.

Used mental models like the Testing Pyramid to design our testing efforts and agreed on a desired code coverage.

In the initial step, we would be happy with anything above 60%.

***

## What's A Testing Pyramid?

Metaphor for structuring automated tests.

Shape: pyramid — wide at the bottom, narrow at the top.

Core Idea:

1. Lots of unit tests (fast, isolated).
2. Fewer integration tests.
3. Even fewer E2E/UI tests (slow, brittle).

From top to bottom:

* Manual and Exploratory Tests
* UI and API Testing
* Integration Testing
* Component Testing
* Unit Testing

***

### What's Unit Testing?

Individual pieces of code — the smaller the better.

***

### What's Component Testing?

Tests objects independently, such as modules, classes, and programs. More thorough than unit testing. Often need access to a database or other components. Slower than unit tests.

***

### What's Integration Testing?

Combines the individual software modules and tests them together as a group.

***

### What's Manual and Exploratory Tests?

TODO

***

## Code Coverage

Software testing metric that measures the percentage of a program's source code that is executed when a test suite is run.

Measure % of functions that are tested.

***

## AAA Pattern

Technique to write adequate test cases.

A = Arrange A = Act A = Assert

***

## "Given > When > Then" Pattern

technique to write adequate test cases.

***

## What is a Test Double?

A generic term (Umbrella Term) for any kind of object that replaces a real component in testing.

Includes `dummy`, `stub`, `fake`, `mock`, and `spy`.

***

## Why Test Doubles?

To isolate the system under test (SUT) from external complexity.

Typically: test a function in isolation.

To do so, we need to provide a **placeholder** or **replacement**.

***

## Types of Test Doubles?

| Type      | Purpose             | Behavior                       | Example Use Case             |
| --------- | ------------------- | ------------------------------ | ---------------------------- |
| **Dummy** | Placeholder         | Does nothing                   | Fill unused params           |
| **Stub**  | Provide test data   | Returns predefined values      | Feed input to SUT            |
| **Fake**  | Lightweight version | Works but not production-ready | External Calls: APIs, DBs... |
| **Mock**  | Verify interactions | Checks if calls were made      | Ensure method was called     |

Summary:

1. Dummy = exists but unused
2. Stub = provides answers
3. Fake = simplified real thing
4. Mock = checks expectations

***

## What's a Dummy?

Passed around only because the method signature requires it.

Never actually used in the test.

***

## What's a Stub?

Provides predefined responses.

Used when the SUT needs some data.

No verification of interactions.

***

## Why Stubs? Use Cases?

1. Avoiding External Calls - i.e. APIs, DBs - isolation & speed
2. Controlling Edge Cases - i.e. simulate errors or unusual data
3. Replacing Expensive or Random Behavior
4. Simulating Slow or Complex Logic - skip heavy processing

***

## What's a Fake?

Has a simplified but working implementation.

Not suitable for production.

Example: in-memory DB.

***

## Why use Mocks in Unit Tests?

If we do not provide a mock, the test will become an INTEGRATION TEST - not a unit test - as it will evaluate the function and its dependencies together.

Used to verify interactions with dependencies.

Typically created with a mocking framework (like Jest).

***

## Are test doubles only used in Unit Testing?

No — test doubles are not only used in unit testing.

But unit testing is where they are most common and essential.

Test doubles can also be useful outside of unit tests:

* Integration Testing: Sometimes you still want to isolate part of the system, e.g., replace a payment provider with a fake service to avoid hitting real APIs.
* System / End-to-End (E2E) Testing: Often discouraged, but still possible when external services are too costly or unstable. Example: Using a mocked email server to capture emails instead of sending real ones.

***

## To write a unit test for the following function we need to also ...

```
import { User } from "./types";
import validateUser from "./validateUser";
async function getUser(url: string): Promise<User | false> {
  const response = await fetch(url);
  const user = (await response.json()) as User;

  if (validateUser(user)) return user;

  return false;
}
export default getUser;
```

1. `mock` the validateUser function so the test is constrained to the current function
2. `stub` the fetch call, and return mock data to make the test independent of the availability/response of the backend

***

## What are Spies?

Spy function records the calls to the external function

For instance, to spy on a specific method, and make sure it was called with the right inputs.

***

## When testing with mocks, why use model without relations?

"Without relations" means the type includes only the User's scalar fields, not the relation fields.

Scalar Field = stores a single, indivisible value — something that is not another object or record - i.e. string, int, boolean, date, etc

Relation fields = represents a relationship between two entities/models/tables - typically correspond to foreign keys - i.e. relations One-to-one, One-to-many, Many-to-many

***

## Coverage threshold levels

**Conservative (80% overall, 70% per-file)**

* Pros: Achievable quickly, less friction, focuses on critical paths
* Cons: May miss edge cases, lower confidence in refactoring
* Best for: Early projects, rapid iteration, small teams

**Moderate (85% overall, 75% per-file)**

* Pros: Good balance, catches most issues, reasonable maintenance
* Cons: Some gaps remain, requires consistent discipline
* Best for: Most production projects, growing codebases

**Strict (90% overall, 80% per-file)**

* Pros: High confidence, safer refactoring, catches edge cases
* Cons: Higher maintenance, can slow development, may encourage low-value tests
* Best for: Critical systems, mature codebases, regulated industries

***

## Coverage metrics

**Lines**

* Pros: Simple, fast, easy to understand
* Cons: Misses untested branches/conditions, can be misleading

**Statements**

* Pros: More accurate than lines, accounts for multi-line statements
* Cons: Similar to lines, still misses branch coverage

**Functions**

* Pros: Ensures functions are called, good for API coverage
* Cons: Doesn't verify behavior, can pass with shallow tests

**Branches**

* Pros: Catches untested if/else, switch cases, ternaries; most valuable
* Cons: Harder to achieve, can be noisy with defensive code

**All metrics (recommended)**

* Pros: Comprehensive, catches different failure modes
* Cons: Strictest, requires thorough testing

***

## Per-file vs global thresholds

**Per-file threshold**

* Pros: Prevents files with 0% coverage, ensures consistent quality
* Cons: Can be strict for utility files, may need exceptions

**Global threshold only**

* Pros: Flexible, allows some files to be lower if others are higher
* Cons: Can hide files with no coverage

***

**TODOs**

* Testing REST APIs
* Testing REST APIs: Postman?
* Testing REST APIs: Integration Tests?
* Testing REST APIs: Unit Tests? SuperTest library?
* Testing REST APIs: cURL Scripts ?