JUnit-如何编写文件解析方法的测试?

发布于 2024-11-08 07:46:59 字数 618 浏览 1 评论 0原文

我是测试开发新手,正在尝试打破我的非 TDD 习惯。

我的应用程序中的大部分功能性、可测试代码都与数据库 I/O 或文件读/写有关。 Android 提供了一些用于处理数据库测试的扩展,但我不知道如何编写用于读取示例文件的测试。

这是我的应用程序的示例:XML 导入。

parseXML() 方法读取具有相当简单架构的文件,并将其内容直接写入数据库。有几个子方法可以解析不同节点的内容(即parseNote()parseList())。

我必须提供样本文件吗?如果是这样怎么办?我应该如何开始测试这样的代码?

编辑 样本文件:

<lists>
<list title="Sample List">
<note title="Note 1" details="Details 1"/>
<note title="Note 2" details="Details 2"/>
<note title="Note 3" details="Details 3"/>
</list>
</lists>

I'm new to test development and am trying to break my non-tdd habits.

Most of the functional, testable code in my app has to do with database i/o or file reading/writing. Android provides some extensions for dealing with the database tests, but I'm lost as to how I can write tests for reading a sample file.

Here's an example from my app: XML import.

The method parseXML() reads a file with a fairly simple schema and directly writes its contents to the database. There are several sub-methods that parse the contents of different nodes (i.e. parseNote() or parseList()).

Do I have to provide a sample file? If so how? How should I even start testing code like this?

Edit
Sample File:

<lists>
<list title="Sample List">
<note title="Note 1" details="Details 1"/>
<note title="Note 2" details="Details 2"/>
<note title="Note 3" details="Details 3"/>
</list>
</lists>

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

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

发布评论

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

评论(3

爺獨霸怡葒院 2024-11-15 07:46:59

很难对将信息保存到数据库的部分进行单元测试,因为这样做需要启动并运行数据库。通过单元测试,您希望避免像瘟疫一样的依赖关系。

相反,您应该做的是测试解组过程,即您的代码是否正确地从 XML 文档中提取数据。创建一个类,其唯一目的是保存已解析的 XML 数据(仅包含属性和 getter/setter 的 POJO/bean 类)。让您的 parseXML() 方法将所有数据放入此类中并返回它(它不应该将任何内容保存到数据库中)。然后,您的单元测试所要做的就是检查以确保对象的属性具有正确的值。

就像 @Woot4Moo 所说,您还应该测试该方法如何处理意外错误,例如不存在的文件或非 XML 文件。

另外,如果您的 XML 遵循某种架构,您可能需要查看 JAX-B。这是一个框架,如果 XML 文档遵循某种模式,它将自动从 XML 文档创建 Java bean 对象。您不必自己编写任何解析代码。

It's hard to unit test the part that saves the information to the database because doing so would require that you have a database up and running. With unit tests, you want to avoid these kinds of dependencies like the plague.

Instead, what you should do is test the unmarshalling process--that is, does your code correctly extract the data from the XML document. Create a class whose sole purpose is to hold the parsed XML data (a POJO/bean class with just properties and getters/setters). Have your parseXML() method throw all the data into this class and return it (it shouldn't be saving anything to the database). Then, all your unit test has to do is check to make sure the object's properties have the correct values.

Like @Woot4Moo said, you should also test how the method handles unexpected errors, like a non-existant file or a non-XML file.

Also, if your XML adheres to a schema, you might want to check out JAX-B. This is a framework that will automatically create a Java bean object from an XML document, given that the XML document adheres to a schema. You don't have to write any parsing code yourself.

深白境迁sunset 2024-11-15 07:46:59

您需要测试的内容如下:

  1. 格式正确的 XML 文件
  2. 格式错误的 XML 文件
  3. XML 文件 > 2GB
  4. 不存在的
  5. XML 文件XML 文件另存为 txt 文件(这实际上仅表明您不依赖扩展名)

The things you will want to test are as follows:

  1. Properly formed XML file
  2. Malformed XML file
  3. XML file that is > 2GB
  4. XML file that does not exist
  5. XML file saved as txt file (this really only shows that you aren't relying on the extension)
岁月蹉跎了容颜 2024-11-15 07:46:59

我会模拟数据库并测试解析器在输入 XML 片段时是否能正确地与其交互。或者,如果您不熟悉模拟框架,您可以将 XML 解析为中间“值”类(所有最终字段)并执行相等断言。

您可以使用 XML 构建器类创建这些片段。对于 XML 文件的基本解析和构建,使用预先存在的 DOM 库比自己编写一个库要容易得多。

I would mock out the database and test that the parser interacts with it correctly when fed snippets of XML. Or, if you are not familiar with mocking frameworks, you can parse the XML into an intermediate 'value' class (all final fields) and perform equality assertions.

You can create these snippets using a XML builder class. For basic parsing and building of XML files, using a preexisting DOM library will be much easier than writing one yourself.

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