Testing

Testing is an essential part of engineering best practices.
It ensures reliability, prevents regressions, and builds confidence in your code before it reaches production or other team members.

This page outlines the core testing expectations for practicum projects, including unit tests, integration tests, UI/snapshot tests, and when testing is required.

---

Quick Navigation

• Unit Test Structure
• Integration Testing Expectations
• UI / Snapshot Testing
• When Tests Are Required

---

Unit Test Structure

View Unit Test Guidelines

Unit tests focus on validating the smallest pieces of code:
functions, utilities, classes, components, logic blocks.

Goals of Unit Tests

• Validate expected outputs
• Catch edge cases
• Ensure functions behave predictably
• Prevent regressions when code changes

General Structure

Unit tests usually follow this pattern:

describe("functionName", () => {
  it("should do something expected", () => {
    // Arrange
    const input = ...
    
    // Act
    const result = functionName(input)

    // Assert
    expect(result).toBe(...)
  })
})

Best Practices

• One test suite (describe) per function or module
• One behavior tested per it block
• Use clear naming:
  “should return X when Y occurs”
• Avoid testing implementation details—test outcomes
• Keep tests small and isolated

Common Tools (depending on project)

• Jest (JS/TS, React, Node)
• PyTest (Python)
• Vitest (modern JS/TS projects)
• JUnit (Java/Kotlin, Android)

(Tools depend on course track — check your project requirements.)

/details

---

Integration Testing Expectations

View Integration Testing Guidelines

Integration tests validate how multiple modules work together.
They cover real-world flows rather than individual functions.

What Integration Tests Should Cover

• API request + data handling workflows
• Component interaction (e.g., button triggers navigation)
• Database + service logic
• Multi-step operations (login → fetch data → render UI)

Best Practices

• Test the full flow, not just pieces
• Use mock services when needed (e.g., fake APIs)
• Avoid overly complex test setups
• Name tests according to user behavior:
  “logs in and loads profile data”

Examples (JS/TS)

it("logs in and fetches user profile", async () => {
  mockApi.post.mockResolvedValue({ token: "123" })
  mockApi.get.mockResolvedValue({ name: "Alice" })

  await login("alice", "password")
  const profile = await loadProfile()

  expect(profile.name).toBe("Alice")
})

Tools (depending on project)

• Jest + React Testing Library
• Playwright or Cypress (advanced UI integration)
• PyTest (Python backends)
• Espresso (Android)

---

UI / Snapshot Testing

View UI / Snapshot Testing

This section is a placeholder until we finalize UI testing tools.
However, here is the planned direction:

Snapshot Testing

Used for:

• React components
• Expo screens
• Small UI units that should remain visually identical

Snapshot example:

it("renders correctly", () => {
  const tree = render(<HomeScreen />).toJSON()
  expect(tree).toMatchSnapshot()
})

Future Topics (To Be Added)

• Visual regression testing
• Accessibility testing
• End-to-end UI flows
• Platform-specific handling (iOS vs Android)

Possible Tools

• Jest Snapshot Testing
• React Native Testing Library
• Playwright Visual Regression
• Detox (native mobile)

This section will be expanded once the practicum finalizes its UI testing stack.

---

When Tests Are Required

View Testing Requirements

Testing requirements vary depending on the project, class, and team expectations.
Below is the general rule for the practicum.

You MUST Write Tests When:

• Creating or modifying core business logic
• Adding utilities that will be reused across the project
• Fixing a bug (add a test to prevent regression)
• Working in modules that already have tests
• Writing complex data transformations
• Building login, authentication, or security-related features

Tests Are Recommended When:

• Adding new React components
• Writing helper functions
• Adding new API request flows
• Doing refactors

Tests Are Not Required When:

• Modifying UI styling only (CSS/Tailwind)
• Updating README or documentation
• Changing small layout components
• Temporary prototypes (unless used in production)

Instructor/Lead-Engineer Note:

• Certain projects may enforce stricter test coverage
• Some repos may include a “minimum coverage” threshold

Always check your project’s README and ask your PM or Lead Engineer if unsure.