Home/ Questions/Q 6351575
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T22:02:05+00:00

I’m currently trying to use PHPUnit to learn about Test Driven Development (TDD) and

  • 0

I’m currently trying to use PHPUnit to learn about Test Driven Development (TDD) and I have a question about writing reports using TDD.

First off: I understand the basic process of TDD:

TDD Flowchart

But my question is this: How do you use TDD to write a report?

Say you’ve been tasked to write a report about the number of cars that pass by a given intersection by color, type, and weight. Now, all of the above data has been captured in a database table but you’re being asked to correlate it.

How do you go about writing tests for a method that you don’t know the outcome of? The outcome of the method that correlates this data is going to change based on date range and other limiting criteria that the user may provide when running the report? How do you work in the confines of TDD in this situation using a framework like PHPUnit?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You create test data beforehand that represents the type of data you will receive in production, then test your code against that, refreshing the table each time you run the test (i.e. in your SetUp() function).

    You can’t test against the actual data you will receive in production no matter what you’re testing. You’re only testing that the code works as expected for a given scenario. For example, if you load your testing table with five rows of blue cars, then you want your report to show five blue cars when you test it. You’re testing the parts of the report, so that when you’re done you will have tested the whole of the report automatically.

    As a comparison, if you were testing a function that expected a positive integer between 1 and 100, would you write 100 tests to test each individual integer? No, you would test something within the range, then something on and around the boundaries (e.g. -1, 0, 1, 50, 99, 100, and 101). You don’t test, for example, 55, because that test will go down the same code path as 50.

    Identify your code paths and requirements, then create suitable tests for each one of them. Your tests will become a reflection of your requirements. If the tests pass, then the code will be an accurate representation of your requirements (and if your requirements are wrong, TDD can’t save you from that anyway).

    • 0