我喜欢 Pex 的想法 - 通过静态代码分析自动生成单元测试 - 但该工具实际生成的测试是可怕的、丑陋的、与 Pex 模块紧密耦合、难以阅读和理解等。
像这样的工具真的适合（在当前状态下）在企业环境中使用，重点必须放在易于维护上吗？
还是我误解了 Pex 的预期用途？
问问题
233 次
4 回答
1
确实，您误解了预期用途。
Pex 是一个白盒测试工具。它根据对它应该测试的代码的分析生成测试用例。这样做的原因是为了检测和测试边缘情况。所以基本上，你甚至不应该改变自动生成的测试。
您的正常单元测试不能被 Pex 替换。它只是一个额外的工具。
于 2012-09-06T13:00:31.600 回答
1
这似乎是一个主观问题......
我会说是的，在给定框架/API 中编写的测试通常与该框架紧密耦合。Pex 的目的不是生成“可读”测试，而是确保代码覆盖给定的一组约束。如果这对您的产品有价值，那么它就是合适的——当然我敢打赌，对于给定的团队和给定的代码库，这将提供价值。
每个企业都是不同的，但产品及其代码决定了测试工具的适用性。我建议要质疑的是 Pex 对于给定代码库的价值，无论所讨论的组织如何。
于 2012-09-06T13:05:41.923 回答
1
我曾在一家大型金融机构使用过 pex，并建议使用它，但仅限于非常具体的情况。我认为 pex 擅长它的工作（如此处其他地方所述，白盒测试以查找边缘情况），但测试的寿命并不长，因为它们的耦合非常紧密。
基本上 pex 非常擅长生成覆盖范围。如果您没有测试并且想要一些快速，请使用 Pex。但是我建议不要再次使用它，而是强制执行新代码的标准，以通过手写测试满足商定的覆盖率指标。
这样，来自 pex 的脆弱测试会随着时间的推移被更灵活和更高质量的测试所取代。
于 2012-09-06T16:20:02.200 回答
0
Pex 对于测试不依赖任何外部的复杂算法非常有用。例如，它不会帮助您找到 SQL 语句或文件访问中的边缘情况。但是，对于发现边缘情况和增加代码覆盖率，除了正常的单元测试之外，它非常有用。
于 2012-09-06T13:01:43.067 回答