Unit testing 非常动态的web应用程序的单元测试？

我的商业web应用程序（带有HTML/Javascript的PHP）有很多不同的选项（大约1000个）存储在数据库中，因此用户可以自己更改它们。例如，这些选项定义按钮、选项卡或输入字段是否可见、输入的验证和工作流程，如应发送电子邮件的时间。每个用户都有一个用户角色，该角色还定义了他们能够看到和执行的内容

我的用户可以使用这些选项的任意组合，因此我发现很难为所有这些情况编写测试。我有100多个客户，所以为每个客户编写测试肯定不是一个选项

问题是有些选择是共同作用的。因此，在测试一个选项时，有必要了解其他选项的价值。理想情况下，测试还应该能够读取每个客户的选项配置文件。但这几乎就像重写整个应用程序，只是为了测试，这本身似乎很容易出错

在单元测试中，读取数据库以获取测试数据和选项是常见的，还是不是一个好主意？

---

你将如何处理我描述的情况？

首先是的，这是完全可能的。虽然不建议在应用程序已经编写好之后再编写单元测试，而且这非常困难

以下是一些针对您的案例的建议：

数据提供者

数据提供程序使使用不同参数调用同一测试成为可能，从而防止测试中的代码重复。如果你想用不同的配置测试同一种方法，那就太完美了

模拟对象

如果对象依赖于其他对象，则使用模拟对象。模拟一个对象基本上就是创建一个虚拟对象，这个虚拟对象有一个已定义的行为，除了你告诉它做的事情之外，不会做任何其他事情。 请注意，您还可以模拟测试类本身！默认情况下，模拟将保留被模拟类的方法，因此您可以模拟要测试的类，并在测试另一个方法时为某些方法定义特定行为。 如果这还不够，您可能需要考虑将方法拆分为更小、更具体的方法，以获得更小的单元

小一点

单元测试之所以称为单元测试，是因为它们在不执行任何其他操作的情况下测试代码中可能最小的单元。因此，与其测试按钮是否按应有的方式运行，不如测试按钮是否可见。只需测试一种行为，就行了

不要读取数据库

在编写单元测试时读取数据库是非常不寻常的，而使用实际用户数据则更不寻常。而是定义测试数据。您应该测试所有可能的配置，而不是测试用户配置

代码覆盖率

检查代码是否被测试覆盖的一个好方法是代码覆盖率。它将显示测试执行了多少代码以及哪些代码。虽然100%的保险范围并不意味着在现实中完全覆盖，特别是在你的情况下。仅仅因为执行了所有代码行并不意味着考虑了所有选项。但无论如何，这是一个方便的工具，您可以看到哪些代码已经完成，哪些代码已经忘记

结论:

你想做的事情本身就是容易出错的，是的。因为通常在编写实际方法之前，您会编写所有测试。您可能会编写比应用程序本身更多的测试代码，但这并不少见