Using TDD to create a report

Question

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

First: I understand the basic TDD process:

But my question is this: how do you use TDD to record a report?

Say that you were instructed to write a report on the number of cars that pass at this intersection by color, type and weight. Now all of the above data has been fixed in the database table, but you will be asked to adjust it.

How are you going to write tests for a method that does not know the result? The result of the method that correlates this data will vary depending on the date range and other limit criteria that the user can provide when starting the report? How do you work on TDD in this situation using a framework like PHPUnit?

Answer 1

You create test data in advance that represents the type of data that you will receive during production, and then check your code for this by updating the table every time you run the test (i.e. in your SetUp () function).

You cannot verify the actual data that you will receive during the production process, no matter what you test. You only verify that the code is working as expected for this scenario. For example, if you upload a test table with five rows of blue cars, then you want your report to show five blue cars when you test it. You are testing parts of the report, so when you are done, you will automatically check the entire report.

As a comparison, if you tested a function that expects a positive integer from 1 to 100, would you write 100 tests to test every single integer? No, you would check for something within the range, then something at the borders (e.g. -1, 0, 1, 50, 99, 100, and 101). You do not test, for example, 55, because this test will go by the same code as 50.

Define your paths and code requirements, then create the appropriate tests for each one. Your tests will reflect your requirements. If the tests pass, the code will be an accurate representation of your requirements (and if your requirements are incorrect, TDD cannot save you from this).

Answer 2

You do not use the same data when running test suites and when running a script. You are using test data. Therefore, if you want to interact with the database, a good solution is to create a sqlite database stored in your bank .

Similarly, if your function interacts with the file system, you can use the virtual file system .

And if you need to interact with objects, you too can trick them .

It’s good that you can test all the bad data about extreme cases that you think of when writing code (hey, what if the data contains unshielded quotes?).

Answer 3

It is very difficult and often unreasonable to test directly against your production server, so it’s best to fake it.

First, you create stub , a special object that stands for a database that allows you to test your device, pretending that some value came from the database when it really came from you. If necessary, you have something that can generate something that you do not know, but which is still available for testing.

Once everything works there, you can have the data set in the database itself in some kind of testing scheme - basically, you are connected, but with different parameters, so that while he thinks he is looking at PRODUCTION.CAR_TABLE , he really is looking at TESTING.CAR_TABLE . You might even want the test / table creation table to drop out each time (although this might be a little larger, which leads to more reliable tests).