如何比较 JUnit 测试用例中的文件?

发布于 2024-09-19 13:14:50 字数 168 浏览 11 评论 0原文

我想在我正在从事的一个小项目上实现 JUnit,因为我想了解一些关于它的知识。

我读过的教程都引用了具有特定输出的方法。

就我而言,我的输出是文件,我该怎么做?有什么简单的例子吗? 有什么方法可以帮助我解决这个问题吗?

这些文件是通过 void 私有方法构建的原始文本文件。

I want to implement JUnit on a small project I'm working on because I want to learn a little bit about it.

The tutorials that I read all make reference to methods that have a particular output.

In my case my output are files, how can I do this? any simple example?
any approach that could help me with this?

The files are raw text files that are build by a void private method.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

臻嫒无言 2024-09-26 13:14:50

您希望为给定的一组输入获取正确的输出文件,并设置一个测试以使用这些输入调用 void 方法,然后将经过验证的输出文件与方法生成的文件进行比较。您需要确保有某种方法来指定方法的输出位置,否则您的测试将非常脆弱。

@Rule
public TemporaryFolder folder = new TemporaryFolder();

@Test
public void testXYZ() {
    final File expected = new File("xyz.txt");
    final File output = folder.newFile("xyz.txt");
    TestClass.xyz(output);
    Assert.assertEquals(FileUtils.readLines(expected), FileUtils.readLines(output));
}

为了方便起见,使用 commons-io FileUtils文本文件比较& JUnit 的 TemporaryFolder 确保输出文件在测试运行之前不存在。

You want to get a correct output file for a given set of inputs, and setup a test to call your void method with those inputs, and then compare your validated output file against whats produced by your method. You need to make sure that you have some way of specifying where your method will output to, otherwise your test will be very brittle.

@Rule
public TemporaryFolder folder = new TemporaryFolder();

@Test
public void testXYZ() {
    final File expected = new File("xyz.txt");
    final File output = folder.newFile("xyz.txt");
    TestClass.xyz(output);
    Assert.assertEquals(FileUtils.readLines(expected), FileUtils.readLines(output));
}

Uses commons-io FileUtils for convinience text file comparison & JUnit's TemporaryFolder to ensure the output file never exists before the test runs.

℉服软 2024-09-26 13:14:50

使用 junitx.framework.FileAssertjunit-addons 项目。其他链接:

其中一种方法:

assertEquals(java.lang.String message,
             java.io.Reader expected,
             java.io.Reader actual) 

Use junitx.framework.FileAssert class from junit-addons project. Other links:

One of the methods:

assertEquals(java.lang.String message,
             java.io.Reader expected,
             java.io.Reader actual) 
半世蒼涼 2024-09-26 13:14:50

在您的方法写入文件后,在单元测试中您可以读取该文件并验证其是否写入正确。

另一件有意义的事情是将您的方法分成一个检索该数据并将其返回到仅将其写入文件的方法。然后就可以验证第一个方法返回的数据是否没问题。

另一种可行的方法是将 OutputStream 传递给写入数据的方法。在“真实代码”中,您可以传递 FileOutputStream / FileWriter,而在测试代码中,您可以编写 OutputStream 的模拟实现,并且检查正在写入的内容。

After your methods write the file, in the unit-test you can read the file and verify whether it is written correctly.

Another thing that makes sense is to have your methods split in one that retrieves that data and returns it to the methods that merely writes it to a file. Then you can verify whether the data returned by the first method is fine.

And another plausible approach would be to pass an OutputStream to the method that writes the data. In the "real code" you can pass a FileOutputStream / FileWriter, while in the test-code you can write a mock implementation of OutputStream and check what is being written to it.

梦途 2024-09-26 13:14:50

尽管您的问题可能看起来很简单,但它确实触及了单元测试的核心,但需要编写格式良好且可测试的代码。这就是为什么一些专家建议应该先编写单元测试,然后再编写实现类。

在您的情况下,我建议您允许您的方法执行并创建预期的文件,然后您的单元测试可以分析文件是否正确形成。

Although your question may seem simplistic it does strike to the heart of unit testing, one needs to write well formed code that is testable. This is why some experts advise that one should write the unit test first and then the implementing class.

In your case I suggest you allow your method to execute and create the file(s) expected, following which your unit test(s) can analyse that the files are formed correctly.

哆啦不做梦 2024-09-26 13:14:50

如果您无法控制该方法将输出放入流中,那么我会说您需要重构代码,以便该方法在参数中(或其类的构造函数中)接收流。

之后,测试非常简单 - 您只需检查流即可。易于测试的代码通常等于好的代码。

If you can't control the method to put the output in a stream, then I'd say you need to refactor your code so that the method receives a stream in the parameter (or in the constructor of its class).

After that, testing is pretty easy - you can just check the stream. Easily testable code usually equals good code.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文