3

技术：Junit 最新版本 应用面向业务

有些人将硬编码数据用于测试用例，有些人使用属性文件和一些 xml 文件。据我所知，xml 比其他两个更好。有没有更好的方法在工业中使用。请建议开发测试用例的最佳实践。

4

3 回答 3

3

测试中的数据表示和传递给被测试函数的数据之间的映射尽可能透明是很重要的。如果数据很少且易于在源中观察，则硬编码数据是完全可以的。为理解测试用例而需要保持打开的窗口越少越好。

XML 最适合嵌套的树状数据，但它有点冗长。YAML 也可能对此有好处。对于平面数据，属性和仅行组织的文件都可以。

没有一种格式在所有方面都优于所有其他格式。为特定的测试套件/主题领域选择最简单、最自然的方法。当您需要快速生成越来越多的测试用例时，投入一些精力来处理最自然的格式确实会有所回报，然后在您调查回归时再次这样做。例如，在我们的项目（相当大）中，我们必须发明几种数据表示并编写（简单）自定义解析器，以使测试用例的数据写入和读取变得轻而易举。

于 2010-12-18T09:33:12.297 回答
2

我认为没有最佳实践。我建议您使用最适合您的特定问题空间的测试，以及您需要执行的测试类型。如果您需要编写代码的测试本质上涉及调用具有大量不同输入的方法，那么数据驱动方法（使用属性文件、XML 或其他东西）是一个好主意。如果不是，那是个坏主意。

需要注意的一件事是花费太多时间创建复杂的基础架构，以便您可以整齐地编写测试代码。

于 2010-12-18T08:27:47.863 回答
2

我会尽量让测试保持快速和简单。测试运行得越快，您可以添加到构建中的测试就越多。

xml 的缺点：解析非常昂贵，还要从 DOM 中读取值。对于表格数据，我会使用某种 CSV 格式的平面文件。对于键/值数据，一个简单的属性文件就足够了。

使用 JUnit，我们处于单元测试级别，我们想知道公共接口是否根据规范实现，以及它们是否以定义的方式处理所有可能的输入。因此我通常在测试方法中硬编码测试值，因为它们通常不会改变（不需要在测试类之外编辑值）

于 2010-12-18T09:39:41.040 回答