使用 TDD 创建报告
我目前正在尝试使用 PHPUnit 来了解测试驱动开发 (TDD)，并且我有一个关于使用 TDD 编写报告的问题。
首先：我了解 TDD 的基本流程：
但我的问题是这样的：你如何使用 TDD 来编写报告？
假设您的任务是根据颜色、类型和重量编写一份关于通过给定十字路口的汽车数量的报告。现在，上述所有数据都已捕获在数据库表中，但系统要求您将其关联起来。
您如何为您不知道结果的方法编写测试？关联此数据的方法的结果是否会根据日期范围和用户在运行报告时可能提供的其他限制标准而改变？在这种情况下，您如何使用 PHPUnit 这样的框架在 TDD 的范围内工作？
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:
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您预先创建代表您将在生产中收到的数据类型的测试数据，然后根据该数据测试您的代码，并在每次运行测试时刷新表格（即在您的 SetUp() 函数中）。
无论您测试什么，都无法针对生产中收到的实际数据进行测试。您只是测试代码是否按给定场景的预期工作。例如，如果您在测试表中加载五行蓝色汽车，那么您希望报告在测试时显示五辆蓝色汽车。您正在测试报告的各个部分，因此完成后您将自动测试整个报告。
作为比较，如果您正在测试一个期望 1 到 100 之间的正整数的函数，您会编写 100 个测试来测试每个单独的整数吗？不，您将测试范围内的某些内容，然后测试边界上及其周围的内容（例如-1、0、1、50、99、100 和101）。例如，您不会测试 55，因为该测试将沿着与 50 相同的代码路径进行。
确定您的代码路径和要求，然后为每一个创建合适的测试。您的测试将反映您的要求。如果测试通过，那么代码将准确地表示您的需求（如果您的需求是错误的，TDD 无论如何也无法挽救您）。
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).
运行测试套件和运行脚本时不使用相同的数据。您使用测试数据。因此，如果你想与数据库交互，一个好的解决方案是创建一个存储在你的内存中的sqlite数据库。
同样，如果您的函数与文件系统交互，您可以使用 虚拟文件系统。
如果您必须与对象交互，你也可以嘲笑他们。
好处是，您可以使用编写代码时想到的所有恶性边缘情况数据进行测试（嘿，如果数据包含未转义的引号怎么办？）。
You don't use the same data when running the test suites and when running your script. You use test data. So if you want to interact with a database, a good solution is to create a sqlite database stored in your ram.
Similarly, if your function interacts with a filesystem, you can use a virtual filesystem.
And if you have to interact with objects, you can mock them too.
The good thing is you can test with all the vicious edge-case-data you think of when you write the code (hey, what if the data contains unescaped quotes?).
直接针对生产服务器进行测试非常困难，而且通常是不明智的，因此最好的选择是伪造它。
首先，您创建一个存根，这是一个代表数据库的特殊对象，它允许您让单元测试假装某些值来自数据库，而实际上它来自您。如果需要的话，你有一些东西能够生成一些你不知道的东西，但仍然可以通过测试访问。
一旦一切正常，您就可以在某些测试模式中在数据库本身中拥有一个数据集 - 基本上，您可以使用不同的参数进行连接，这样当它认为它正在查看 Production.CAR_TABLE 时，它就会真正关注的是
TESTING.CAR_TABLE。您甚至可能希望每次都进行测试删除/创建表（尽管这可能有点多，但它确实会导致更可靠的测试）。It is very difficult, and often unwise, to test directly against your production server, so your best bet is to fake it.
First, you create a
stub, a special object which stands in for the database that allows you to have your unit tests pretend that some value came from the DB when it really came from you. If needs be, you have something which is capable of generating something which is not knowable to you, but still accessible by the tests.Once everything is working there, you can have a data set in the DB itself in some testing schema -- basically, you connect but with different parameters so that while it thinks it is looking at
PRODUCTION.CAR_TABLEit is really looking atTESTING.CAR_TABLE. You may even want to have the test drop/create table each time (though that might be a bit much it does result in more reliable tests).