我在assertEquals()
中使用jUnit
方法来测试某个值是否与代码生成的实际值相等。
/*
calculating the actual_value
*/
int expected_value = 1000; // rows of the set of files, manually calculated
assertEquals(expected_value, actual_value);
我想知道如果我这样做,那么在标准和手续的情况下这将是一个问题。
/*
calculating the actual_value
*/
int expected_value = getRelevantLinesOfFiles(set of files); // rows of the set of files
assertEquals(expected_value, actual_value);
因为几乎不可能总是手动找到那种变量,所以我写了一个方法来读取和计算这些文件中的相关行。
我担心的是我在assertEquals
测试中使用了一个方法。但getRelevantLinesOfFiles()
方法未经过测试。如果我要测试它,那么我必须再次手动读取文件。所以它一次又一次有点相同。
这是一个好习惯吗?或者进行这类测试的最佳方法是什么?
答案 0 :(得分:4)
如果这些文件也是actual_value
的计算输入,那么您正在做的是测试替代实现与真实替代实现。这是有效的,但需要预先了解事情,例如,与优化和更复杂的生产相比,通常使用非常简单且易于审查的测试实施来完成。实现。如果情况并非如此,那你就做错了。
如果文件包含actual_value
从那时起计算的结果,那么它应该没问题,例如,如果您有输入集和预期输出的匹配集。
另外,考虑一下你是否可以提炼至少一些简单的硬编码输入和硬编码的预期输出,类似于你的第一个例子,不涉及文件。这可能需要允许您的界面使用不是File
的抽象来模拟输入,或者能够在实际提供模拟测试数据的测试中注入替代文件读取机制。 / p>
编辑:只是提供一个很好的抽象的具体示例,而不是File
实例(或文件名,或其他)使用okio并传入一组Source实例
真实实施:给定File
个实例列表,使用Okio.source(file)创建Source
个实例。
测试:传递包含您想要的任何内容的Buffer个实例列表
Buffer b = new Buffer();
b.writeUtf8("whatever the hell I want in this file");
// can also write bytes or anything else
int actualValue = getRelevantLinesOfFiles(Arrays.asList(b));
答案 1 :(得分:0)
如果仅为测试生成测试文件,我认为您应该手动准确地准备这些测试文件,例如,' file1'有1行,file0
有0行,' fileX'有X行等,不需要准备太多文件,你可以考虑一些重要的案例。
如果这些文件是来自生产环境的真实数据,那么我建议您编写一个方法,例如代码中的getRelevantLinesOfFiles
,以计算它们的行号。但首先,你应该使用我上面提到的方法来测试这种方法。
答案 2 :(得分:-2)
离开" Magic Numbers"这是一个好习惯。 (代表1000)你的代码。就像talex所说的那样,在文件上测试getRelevantLivesOfFiles()
方法,这个方法足够小,可以计算。然后,您可以放心地使用它来测试代码的其他部分。