Skip to main content

Testing guide in this project

As of 2025, software testing practices have evolved significantly. The traditional pyramid—where unit tests formed the foundation—is being reshaped. Today, fast, containerized integration tests (e.g. via Testcontainers) form the new core of the testing strategy.

That why we use this a modernized view of the test pyramid where integration tests and BDD-style acceptance tests play a central role, supported by automated E2E tests focused on technical quality and UX validation.

Levels of Testing and Their Purpose​

1. Unit Tests​

  • Purpose: Validate individual functions or methods in isolation
  • Relevance: Decreased; used only when isolation is crucial
  • Examples: VAT calculation, input validation, data transformation

⚠️ No longer the base of the test strategy—they are often replaced by more valuable integration coverage.

BDD? ❌ Not recommended – too low-level to express behavior meaningfully.

2. Integration Tests (Primary Pillar)​

  • Purpose: Verify interactions between components (e.g. service + repository + DB)
  • Tech stack: Testcontainers, Docker Compose, in-memory databases (e.g. SQLite)
  • Advantages:
    • Fast execution (seconds)
    • Real integrations without mocking
    • Alignment with business rules and domain boundaries

BDD? ✅ Yes. BDD scenarios can be very effective here.

Benefits:

  • Clear behavioral specs, readable by non-technical stakeholders
  • Supports domain modeling and DDD practices
  • Validates edge cases and business decision paths

Challenges:

  • Requires clear definition of behavior boundaries
  • Risk of excessive scenario duplication if business requirements aren't properly analyzed:
    • Without prior refinement (e.g. Event Storming, Impact Mapping, or Three Amigos sessions), it's easy to write similar or redundant scenarios that test the same behavior.
    • Leads to:
      • Low-value test bloat
      • Slower pipelines
      • Higher maintenance cost
      • Difficulty identifying relevant cases

➡️ Mitigation: Focus on business goals and behavior-driven value.

3. Acceptance Tests (BDD)​

  • Purpose: Validate that business requirements are met
  • Format: Given–When–Then scenarios (Cucumber, SpecFlow, Behave)
  • Role: Shared documentation and acceptance criteria

BDD? ✅ Yes. This is the core practice of BDD.

Benefits:

  • Shared language across business and engineering
  • Structured behavioral documentation
  • Can drive both automated and manual QA

Challenges:

  • Requires team commitment (business, QA, dev)
  • Risk of focusing too much on tooling rather than on behavior

4. End-to-End (E2E) Tests​

  • Purpose: Validate full user flows across the system
  • Scope: Frontend + backend + DB + external services
  • Tools: Playwright, Cypress, Selenium
  • 2025 Trends:
    • Accessibility: WCAG 2.2 compliance testing
    • UX performance: Core Web Vitals (LCP, FID, CLS)
    • Responsiveness and usability checks

BDD? ✅ Yes, selectively.

  • ✅ Use BDD for business-relevant flows (checkout, onboarding, login)
  • ❌ Avoid BDD for purely technical tests (e.g. FID validation, layout shifts)—use metric-focused tools instead

Benefits:

  • Ensures system-wide functionality
  • Operates in real environments (browser, network, APIs)

Challenges:

  • Brittle and high-maintenance
  • Can slow down CI/CD pipelines

BDD as a Behavioral Specification Tool​

When BDD shines:​

  • ✅ Integration tests — behavioral logic across components
  • ✅ Acceptance tests — shared understanding with business
  • ✅ E2E tests — when validating real user scenarios

When BDD should be avoided:​

  • ❌ Unit tests — too granular, low ROI
  • ❌ Technical validations — where metrics or accessibility scores are better suited

Summary​

Your approach emphasizes integration over isolated units, acceptance over heavy E2E reliance, and behavior over implementation details. This results in a modern, scalable, and collaboration-driven testing strategy:

  • Integration + BDD = reliable, fast, business-aligned test coverage
  • Automated acceptance = fewer bugs, clearer requirements
  • E2E = technical & UX assurance aligned with 2025 standards (WCAG, Web Vitals)

✅ It’s not just about testing code.
It’s about communicating behavior and ensuring user value.

References and further reading: