unit-testing - 在自己的单元测试中针对函数输出断言？

Question

如果该标题没有意义(这是我所期望的 =))，这就是我要问的:

我有一个名为 ParseFile() 的函数。它以字符串作为参数，以 DataTable 作为返回值。

我想对这个函数进行单元测试。我先编写函数代码，运行它，获取输出，将其序列化为 XML，将其保存为预期输出，然后编写我的单元测试来调用该函数并对反序列化数据进行断言，这对我来说是错误的吗？

我意识到这对我有帮助，在我们获得以前可能没有见过的新输入并且必须更改解析函数来处理它的情况下 - 运行我的测试现在将断言我没有破坏任何当前工作文件。太棒了...

.. 但在这种情况下，格式永远不会改变并且是标准的。那么按照我说的去做就完全没用了吗？如果是，那么如何测试这个功能？

哎呀，如果我说的仍然是个好主意 - 您将如何采用真正的 TDD 风格并首先编写测试？无需为文件中的每个预期字段繁琐地编写 Assert calls() ？我还没有完全进入 TDD“模式”——但我正试图到达那里……在这种情况下，我有时想知道当预期输出是一个数据集时，你如何首先为它编写测试例子...

谢谢

Answer 1

没有错，但不是 TDD。

话虽这么说，但我想警告您关于对 XML 字符串进行断言:当 XML 大小足够大时出现问题时，您最终会手动比较两个 XML 字符串，这在视觉上是错误的。

去过那里，做过那件事。我记得在那种情况下，将 XML 复制到两个文件中，将其修改为每行一个属性，然后使用 diff 比较这两个文件。我说过下次我将尝试使用 XPath 和/或 XQuery 在 XML 上断言。

另外，你的函数是不是做了太多事情:解析字符串和生成XML？您可能要考虑将其分开。

How would you even do that true TDD style and write the test first?

如果你真的想使用 TDD 并保留一个功能，那么你可以从一个测试开始:你的 XML 输出应该是什么样子的空字符串？这是你的第一个测试。一旦通过，就用一个带有简单元素的字符串重新开始，编写测试，让它通过，然后取一个更复杂的字符串。起泡、冲洗、重复。