持久化复杂的测试数据 [英] Persisting complex test data

查看:34
本文介绍了持久化复杂的测试数据的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在使用构建器模式来生成测试数据.这些领域对象之间有关系.我们的功能测试需要持久化这些对象.

We are using builder pattern to generate test data. These domain objects have relations between them. Our functional tests require these objects to be persisted.

想想这个模型:

如果我想要一个普通的 C 实例,我可以 aNew().c().build()

If I want a plain instance of C I do aNew().c().build()

如果我希望它被持久化,我会执行 aNew().c().saveIn(session)

If I want it to be persisted I do aNew().c().saveIn(session)

如果我想要一个具有已知 B 的 C 实例,我会执行 aNew().c().with(b).build()

If I want an instance of C with a known B I do aNew().c().with(b).build()

好吧,你明白了.我的问题是,如果我想坚持一个 C,它是否应该坚持它的 B?还是应该事先坚持?如果我想要一个合理的默认 B 呢?如果我想坚持一个 D 呢?是否应该保留所有 A、B、C?

Well, you got the idea. My problem is, if I want to persist a C, should it persist it's B? Or should it be persisted before hand? What about if I want a reasonable default B? What about if I want to persist a D? Should it persist all A, B, C?

当然真正的系统要复杂得多(有时需要循环引用).我正在寻找持久化复杂测试数据的最佳实践.

Of course real system is much more complex (sometimes with circular references). I am looking for a best practice for persisting complex test data.

看来我遇到了语言障碍,我的母语不是英语,所以很抱歉默默无闻.以下是更多信息:

It looks like I have bumped into the language barrier, my mother language is not English, so I am sorry for obscurity. Here is more information:

  • 我要测试的不是遗留代码
  • 我正在尝试编写覆盖测试,而不是单元测试(因此我不会嘲笑任何东西)
  • 如果数据库被填充到某种程度(它不使用所有实体),我尝试测试的软件就可以工作.

附注.请不要犹豫,询问更多信息,因为我一直在努力寻找可能的最佳实践.我想出的最接近的事情是:

PS. Please don't hesitate to ask for more information, because I have been struggling to find the possible best practice. The closest thing I have come up with is:

  1. 跟踪构建实体时明确设置的内容.
  2. 假设显式设置的实体已经持久化,不要持久化它们.
  3. 坚持其他一切(使用自己的坚持者).

这会起作用,但是我的蜘蛛感是刺痛的,我想我做错了什么,因为测试代码中会涉及逻辑,如果没有测试,处理起来会非常复杂.

This will work, but my spider sense is tingling, I think I am doing something wrong because, there will be logic involved in test code, it will be very complex to deal with without tests.

编辑 2:我会尽量让自己更清楚.当我编写/运行我的单元和一些集成测试时,我没有问题,因为测试数据不是持久化的,它存在于内存中.

Edit 2: I will try to make myself more clear. When I am writing/running my unit and some integration tests I have no problem, because the test data are not persisted, it lives in memory.

但是当我尝试持久化我的测试数据时,hibernate 不会让我在没有关系的情况下保存实体.

But when I try to persist my test data, hibernate will not let me save an entity without it's relations.

我该如何克服这个问题?

How can I overcome this problem?

推荐答案

您需要更好地定义域上的级联.如果您无法对其进行测试,您希望它在实际应用中的表现如何?

You need to define your cascades on the domain better. If you can't test it, how do you expect it will perform in the real application?

例如:

A -> B:谁是这段关系的所有者?您想将 B 添加到 A,还是相反?这可以是一个实现细节,您可以同时拥有 B.SetParent(A) 和 A.Children.Add(B),并且在 A.Children.Add(B) 的情况下,您将 B 的父级设置为 A(同样的另一个绕道而行).如果你这样做会发生什么:

A -> B: Who's the owner of this relationship? Do you want to add B to A, or the other way around? This can be an implementation detail where you can have both B.SetParent(A) and A.Children.Add(B), and where you set B's parent to A in case of A.Children.Add(B) (likewise the other way around). What happens if you do:

A a1 = new A();
A a2 = new A();
B b = new B();
a1.Children.Add(b);
b.SetParent(a);

你需要在这里下定决心.没有一个解决方案是完美的,因此这里适用的基本上是个人偏好和应用一致性.

You need to make up your mind here. None of the solutions are perfect, so it's basically personal preference and app consistency that applies here.

与使用纯 SQL(或任何其他数据源,如 XML 或您自己的数据源)相比,使用 ORM 会更快地解决这些约束问题,但是如果您也编写纯 SQL,则需要考虑这些问题.

Working with ORMs you get into these constraint problems faster then with plain SQL (or any other datasource like XML or your own datasource), but you'd need to consider the problems if you were to write plain SQL too.

抱歉,我没有明确的答案,但在我看来,您似乎需要考虑一些(我认为)您尚未完成的限制条件.

I'm sorry, I don't have an definite answer for you, but to me it looks like you need to consider some constraints which (I presume) you haven't done yet.

就个人而言,我喜欢在 DAL 中使用 NHibernate 时的存储库模式.我让我的存储库从 IDisposable 实现,并让它们每个都有一个会话.通过这种方式,您可以将工作单元"模式融入您的设计中.

Personally, I like the repository-pattern when dealing using NHibernate in DALs. I make my repositories implement from IDisposable and let them get a session each. This way you get the "Unit of work"-pattern into your design.

祝你好运:)

这篇关于持久化复杂的测试数据的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆