c# - 测试策略建议——需要记录运行方法的验证结果并将其用于测试目的

Question

我是测试新手，需要有关最佳测试策略(及其应用)的建议。 这是我的问题:

我有一个程序可以读取文件并自动提取其结构。我想测试进行这种“智能”提取的方法。最初我可以使用一些文件来检查该方法是否进行了正确的提取。然后我想使用这些文件和(正确的)提取结果进行测试。由于提取结果已经过验证，因此应该(并且必须)将其用于进一步的测试。

所以，我有类似的东西:对于“这个特定文件”，我期望“这个结果”。

问题:

1. 很容易得到测试的输入文件。我会将它们存储在特定目录中。结果呢？它们影响存储文件结构的对象的内容。在这种情况下，我可能还需要将这个对象保存在一个文件中。使用序列化恐怕随着对象结构的变化，将很难重用以前保存的对象。

2. 随着越来越多的结果，我可能有数百个文件和结果，测试将花费很多时间。我希望测试时间不会成为大问题。

我需要测试，因为我在方法中使用的“提取算法”会经常变化。为了有一个完美的提取算法，我无法应付所有的可能性。因此，我的解决方案是构建一个适用于十几个文件的初始算法，每次我发现特定文件的算法失败时，我都会更改算法以解决该文件的问题。应测试此更改，以便以前的文件和结果仍然有效。

对测试策略有什么建议吗？

Answer 1

对于测试，您需要一个可以注入(inject)输入测试数据的地方，以及一个可以观察某些行为或输出的地方。

在输入端:文件真的是注入(inject)输入测试数据的唯一可能吗？如果是，则该应用程序没有良好的可测试设计。文件测试很难维护。在输出端:该应用程序似乎没有提供观察行为或输出的可能性。这指向不可测试的设计。

即使您找到了一种方法来观察我们的输出行为，也只会对所有提取算法进行端到端测试。这种端到端的测试是脆弱的，是维护的噩梦。原因是一个不好的可测试设计。

如果没有良好的可测试设计，您将无法实现良好的测试策略。您将需要更改应用程序的设计。另一方面，您可能会争辩说您不想在没有进行任何测试的情况下更改设计。这似乎是一个先有鸡还是先有蛋的问题。

如何摆脱这种情况？测试和重构策略的组合可能会有所帮助。在高层次上，这可能是这样工作的:

1. 构建一些有代表性的端到端测试。因此，即使使用 序列化技巧。这只是为了验证您的程序是否有效 就像在你开始重构之前一样。它们充当迁移测试。

2. 重构您的程序。给它注入(inject)和观察的地方。这样的 这些地方被称为接缝。

3. 因此，您将拥有可测试的 block ，您可以将其放入 测试工具。

4. 你重构代码并将新的接缝放入代码中，以测试更小的 block ，直到你到达你有单元测试的地步 地方。理想情况下，您会将所有算法封装到一系列经过单元测试的类中。

听起来很辛苦？不，实际上它比听起来更难。将应用程序重构为可测试的设计需要大量经验。幸运的是，有人为此写了一本书:Michael Feather’s 'Working Effectively with Legacy Code' .

如果您真的非常想为现有应用程序实现良好的测试策略，请阅读那本书。如果你想知道下次可以做什么更好，请阅读那本书。如果您认为单元测试可能是避免不可测试设计的关键，那么现在就开始学习单元测试吧。互联网上有很多关于单元测试的资源和书籍。