我对单元测试相当新，但我完全了解了测试执行特定的，可测试的任务的单个代码单元的想法，但是，我处于需要编写测试并提供信任的位置。作用于具有50多个属性的对象的方法的输出的准确性。这些属性的值的组合基于从规则定义对象（使用lambda表达式）注入的规则产生输出，该规则基本上等于百分比。这些输出百分比是“关键任务”并且之前已经进行过相当严格的测试，例如规则定义类的质量（每个规则的所有可归因百分比加起来都达到100％）但是对象的实际属性没有是。
“数据”对象来自数据库，但我当然可以嘲笑它。我的问题是需要模拟的数据排列数量和需要编写的测试数量，以确保数据x，y，z（乘以50奇数指数）几乎不可能。
所以，问题是，这些情况在真正意义上是如何测试的。脚本测试是基于已知的“正确”状态和“正确”结果甚至可能/合理吗？在这种情况下是否适用单元测试，如果没有，则有哪些替代方案。
顺便说一下，这是遗留代码，只有很少的机会进行重构，但前提是我可以在几天的时间内保证准确性等同时进行重构和测试！
答案 0 :(得分：4)
我认为你自己已经给出了一半的答案：
这些属性值的组合产生输出 基于规则定义对象中的注入规则（使用lambda 表达式）基本上等于百分比。
在您当前的单元测试中，您嘲笑数据和规则。因此，您只需要确保输入和输出方法的行为正确。
测试规则是一项不同的任务。我只能猜测，但通常情况下，您将有一个Excel表格或类似的东西，可能的输入和输出值来指定此规则的要求。我会将同一个表转换为可读（csv）格式，并直接使用它来驱动规则的单元测试。
答案 1 :(得分：3)
好吧，我不知道你在用什么语言工作，但在查看你的个人资料之后我认为.Net可能会参与其中。
如果我说得对，我建议使用数据驱动测试。 MSDN提供了一个简短的快速入门，它帮助我骰子：How to: Create a Data-Driven Unit Test 自从我读到这篇文章以来，我开始发明一种新的变体，以便在每个新项目中使用......
在Visual Studio中使用这些DDT，可以将测试数据存储在XML，CSV或数据库表中。也许您可以编写一些代码来生成要插入测试的必要值？
Microsoft提出的Pex and Moles项目的第二个建议是分析您正在测试的系统，并在此基础上自动生成测试数据以查找更极端的测试用例。
答案 2 :(得分：3)
如果大量的组合阻碍了您尝试生成测试用例，那么您可以查看 all-pair测试。
我们使用了来自microsoft的PICT来成功地减少了测试用例的数量，同时仍然有充分的信心来覆盖大多数案例。
<强>摘要
例如，如果您希望为分区创建测试套件 卷创建，域可以通过以下描述 参数：类型，大小，文件系统，格式方法，簇大小和 压缩。每个参数都有有限数量的可能值， 每个都由其性质决定（例如，压缩 只能是On或Off）或作为等价分区（例如Size）。
类型：主要，逻辑，单一，跨度，条纹，镜像，RAID-5
尺寸：10,100,500,1000,5000,10000,40000 格式方法：快速，慢速
文件系统：FAT，FAT32，NTFS
簇大小：512,1024,2048,4096,8192,16384,32768,65536
压缩：开，关这些值有超过4,700种可能的组合。它会 很难在合理的时间内测试所有这些。 研究表明，测试所有可能的值对提供了很多 良好的覆盖率和测试用例的数量将保持可管理性。对于 例如，{Primary，FAT}是一对，{10，slow}是另一对;一个 单个测试用例可以涵盖多对。
对于上面显示的参数集，PICT将产生60个测试 例。
外卖点
所有对
全对测试背后的原因 是这样的：最简单的错误 程序通常由a触发 单输入参数。
下一个最简单的错误类别包括 那些依赖于互动的人 在参数对之间，可以 被所有对测试抓住。
涉及之间相互作用的错误 三个或更多参数是 渐渐变得不那么常见了 同时正在逐步进行 通过详尽的找到更昂贵的 测试，其中有限制 所有可能的详尽测试 输入。