如何对我的数据库内容进行单元测试？
我们有一个正在测试 swing 应用程序的案例。我们有一名 QA 人员，到目前为止一直在对应用程序进行手动测试。现在我们意识到手动测试需要很长时间才能重复，因此投入时间使用 Fest 对 UI 进行自动化测试。
硬币的另一面是测试数据库数据。这意味着在 GUI 中执行一些步骤后，我们需要检查数据库中是否存在我们期望的数据。
由于是 QA 人员为我们编写这些单元测试，因此我们希望通过提供某种框架来使他尽可能轻松地完成此任务。
是否有某种框架可以根据我们拥有的数据测试数据库？类似于 JUnit 断言的预期和实际。
基本上，我们正在寻找一个具有以下功能的框架：
- “预期”数据应该很容易提供，就像以 YAML、JSON、Excel Sheet、CSV 方式一样。 XML 和编写代码来在 java 中创建 Bean 非常耗时。
- 我们希望创建预期数据，以便仅根据数据库检查预期数据中存在的列。
- 我们不介意扩展框架，让不太了解 Java 的人也能轻松使用......
We have a case where we are testing a swing application. We have a QA person who up until now was doing manual testing of the app. Now we have realised that manual testing takes a long time to repeat and hence investing time into automated testing of our UI using Fest.
The other side of the coin is testing the database data. Meaning after doing some steps in the GUI, we need to check with the database if the data we expect is present there or not.
Since it's a QA guy who is writing these unit tests for us, we would like to make it as easy as possible for him by providing some sort of framework in order to do this.
Is there some sort of a framework which will test the database against the data that we have? Something like an expected and actual as with JUnit's assert.
Basically we are looking for a framework that has these features:
- The 'expected' data should be easy to provide like in a YAML, JSON, Excel Sheet, CSV way. XML and writing code to create beans in java is time consuming.
- We would like to create the expected data such that only the columns present in the expected data should be checked against the database.
- We don't mind extending the framework to make it easy for a person who doesn't know Java much to work with....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Dbunit 看起来像是适合您的解决方案。
DbUnit 还可以帮助您验证数据库数据是否与预期的值集匹配。
Dbunit looks like a solution for you.
DbUnit can also help you to verify that your database data match an expected set of values.
这似乎是 DBUnit 的用例
This seems like a use case for DBUnit
您可能还喜欢将 FitNesse 视为一种易于使用的工具。尽管您可能需要在幕后投入更多时间来创建测试装置，但这对于测试人员来说将是一个易于使用的工具。请参阅http://fitnesse.org/
You may also like to consider FitNesse as an easy to use tool. Although you may have to invest more time behind the scenes creating the test fixtures it will be an easy to use tool for the tester. See http://fitnesse.org/
我们最近也遇到了类似的情况，最终选择了我们自己的框架。我们将其基于优秀的 scala 规范库（它也可以与 JUnit 的运行程序一起使用）。与您的案例的主要区别可能是，我们的 QA 人员有一点编程背景，并且我们在同一框架内编写了更多涉及更多的测试用例。
然而，为了涵盖主要功能，中心思想是定义一种特定于领域的语言来测试数据。这使得它非常容易用于 QA（在学习如何使用该语言、可用的语言等的初始开销之后）。
为了更具体地回答您的特征点：
Scala 与 XML 配合得非常好。不需要解析器代码，样板代码被减少到最少。自己编写 XML-Database-Comparator 并通过 DSL 提供对它的访问，然后 QA 可以简单地编写一个 XML 片段来在数据库中进行检查。
同上。您自己提供比较器，因此确保这一点很简单。
Scala 与 Java 配合得很好，因为它编译为 Java 字节码。您可以重用所有现有的 Java 代码来创建 DSL，甚至让您的测试代码访问它。
对我们来说，主要的优势是我们可以重用 Hibernate 数据模型来对数据模型执行更多复杂的测试，我们仍然可以像往常一样访问所有 Java 代码，而且 DSL 即使对于非程序员来说也很容易阅读。 （当你试图解释一些经理类型的东西实际上在做什么时，后者会派上用场。）
We had a similar situation recently and ultimately went for our own framework. We are basing it on the excellent scala specs library (which can also work with JUnit's runner). The main difference to your case will probably be, that our QA guy has a little programming background and that we write additional more involved test cases within the same framework.
However, to cover you main features, the central idea is to define a domain-specific language for testing your data. This makes it very easy to use for a QA (after the initial overhead for learning how to use the language, what's available for it, etc.).
To more concretely answer your feature points:
Scala works extremely well with XML. No parser code required, boilerplate code is reduced to a minimum. Write the XML-Database-Comparator yourself and provide access to it via the DSL, then the QA can simply write a XML fragment to check for in the database.
Same as above. You provide the comparator yourself, so it's straightforward to ensure this.
Scala works lovely with Java, as it compiles to Java bytecode. You can reuse all your existing Java code for creating the DSL, or even let your test-code access it.
Major advantages for us were that we could reuse the Hibernate datamodel to perform more involved tests on the datamodel, we could still access all our Java code as usual, and the DSL is very easy to read even for non-programmers. (The latter comes in handy, when you try to explain some manager-type what that stuff is actually doing.)