PHP From ZeroModern PHP course

testing php applications

TDD, BDD, And Acceptance Criteria In Real Delivery

TDD, BDD, and acceptance criteria support different conversations during delivery. TDD gives a developer a tight implementation feedback loop. BDD helps a team discuss examples of behaviour. Acceptance criteria define what must be true for the work to be considered complete.

Use Examples To Remove Ambiguity

Start with a user or business outcome, discuss normal and rejected scenarios, then choose the cheapest automation boundary that protects each rule. Not every acceptance criterion belongs in a browser test.

Carry The Criteria Through Delivery

Link implementation, tests, review, manual QA, and release notes back to the agreed behaviour. When a scenario changes, update the criteria and the most useful automated evidence together.

For the criterion "eligible orders receive free delivery", use a unit example proving that a 5000-pence basket has no delivery fee, an HTTP example proving that checkout returns the fee correctly, and one browser journey proving that the customer sees free delivery before placing the order.

Common Mistakes

  • Turning every criterion into a browser test.
  • Writing criteria after implementation only to describe what already exists.
  • Skipping rejected and boundary examples.
  • Separating manual QA from agreed behaviour.

What To Practise

  • Connect acceptance criteria to examples.
  • Choose useful automation boundaries.
  • Use TDD and BDD as complementary practices.

Practice

Practice: Plan Delivery For A Discount Code

Write acceptance criteria and a test plan for applying a discount code at checkout.

Requirements

  • Include valid, expired, and unknown codes.
  • Include one calculation boundary.
  • Choose unit, HTTP, and browser checks deliberately.
  • State manual QA focus.
Show solution

The plan keeps most rule coverage fast and one journey user-visible.

  • Unit: calculate the valid discount and reject expired or unknown codes, including the calculation boundary.
  • HTTP: prove the apply endpoint returns an updated basket or a stable validation error.
  • Browser: keep one journey where a customer applies a valid code and sees the updated total.
  • Manual QA: review message clarity, keyboard flow, and mobile layout.

The browser journey stays small because lower-level checks already cover the matrix of code states.