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