技术：Junit最新版本 应用程序是面向业务的
有些人在测试用例中使用硬编码数据，有些人使用属性文件和一些xml文件。据我所知，xml比其他两个更好。是否有一些更好的方法在工业中使用。请建议开发测试用例的最佳实践。
答案 0 :(得分：3)
重要的是，测试中的数据表示与传递给被测试函数的数据之间的映射尽可能透明。如果数据很少且在源代码中很容易观察，那么硬编码数据就完全可以了。您需要保持开放以了解测试用例的窗口越少越好。
XML最适合嵌套的树状数据，但它有点罗嗦。 YAML也可能对此有好处。对于平面数据，属性和只有行组织的文件都可以。
no 单一格式在所有方面都优于其他格式。为特定的测试套件/主题区域选择最简单，最自然的选项。当您需要快速生成越来越多的测试用例时，投入一些精力来处理最自然的格式，然后在调查回归时再次付费。例如，在我们的项目中（非常大）我们必须创建几个数据表示和编写（简单）自定义解析器，以便轻松地为测试用例编写和读取数据。
答案 1 :(得分：2)
我认为没有最佳做法。我建议您使用最适合您特定问题空间的那个，以及您需要执行的测试类型。如果您需要编码的测试主要涉及调用具有大量不同输入的方法，那么数据驱动方法（使用属性文件，XML或其他东西）是个好主意。如果没有，这是一个坏主意。
要注意的一件事是花费太多时间创建复杂的基础架构，以便您可以整齐地编写测试代码。
答案 2 :(得分：2)
我会尽量保持测试的快速和简单。测试运行得越快，您可以添加到构建中的测试就越多。
xml：解析的缺点是非常昂贵，也从DOM读取值。对于表格数据，我使用某种CSV格式的平面文件。对于键/值数据，一个简单的属性文件就足够绝对了。
使用JUnit，我们处于单元测试级别，我们想知道公共接口是否根据规范实现，以及它们是否以所定可能输入的定义方式运行。因此，我通常在测试方法中对测试值进行硬编码，因为它们通常不会更改（无需编辑测试类之外的值）