单元测试数据模型:相关实体

发布于 2024-12-06 13:25:05 字数 328 浏览 0 评论 0原文

我是单元测试的新手TDD 在阅读了一些文章后,我决定在我的一个小项目中开始 TDD。这是一个简单的剧院门票预订,使用 NHibernate 和还有存储库模式。我决定首先为我的数据模型编写一些测试,因此我从对实体进行简单的 CRUD 操作开始。我面临的第一个问题是具有多对一关系的实体。例如,我有一个 Show 实体,它与 Director 实体具有多对一关联(每个节目都有一个导演),因此用于测试 Show.Create 方法我必须创建一个导演实体来首先为他分配演出。

由于单元测试强烈不鼓励编写依赖测试,因此我如何在不依赖此类相关实体的情况下解决这个问题?

I'm new to unit testing & TDD and after reading some articles i decided to start TDD in a small project of mine. it's a simple Theater Ticket Booking which uses NHibernate & also Repository pattern. i decided to first write some tests for my data model, so i started with simple CRUD operations on entities. the first problem that i faced was entities with many-to-one relations. for example i have a Show entity which has a many-to-one association to the Director entity (each Show has a Director), so for testing the Show.Create method i had to create a Director entity to assign him the Show first.

Since unit testing strongly discourage writing dependent tests, how could i get over this problem without making any dependency to such related entities?

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

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

发布评论

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

评论(2

丢了幸福的猪 2024-12-13 13:25:05

我发现将 TDD 视为编写如何使用某些东西以及为什么该行为很有趣的示例会有所帮助。

例如,在您的应用程序中您可能有以下行为:

节目在创建时就与导演相关联。

然而,这并不是很有趣。为什么这很有价值?它用在哪里?如果你能展示行为的某些方面,这在其中很重要,那就更有趣了。

节目的声誉始于其导演的声誉。

然后您可以编写此行为的示例:

Given a director with a reputation of 75%
When he creates a new show
Then the show should start with a reputation of 75%.

那将是更有趣的行为。实际上,我们可以在不使用 Hibernate 的情况下创建具有这种声誉的节目。我有时会在测试中添加这样的示例作为注释。 (我用这个作为例子,因为我不知道为什么与导演一起创建一个节目对你来说很重要!)

对于像 NHibernate 这样的东西,要么使用覆盖整个应用程序的全栈场景,要么使用仅覆盖整个应用程序的集成测试通过与其导演构建节目来检查映射,或手动检查应用程序是否正常工作。您可以假设,如果您以正确的方式使用 NHibernate,它将继续工作,因此与要更改的代码相比,您需要对其进行的测试更少。

我的经验是,创建真实的领域对象(表演、导演等)而不是模拟它们是可以的。然而,如果你有任何复杂的计算 - 例如,一旦节目播出了几个晚上,计算它的声誉可能会很复杂 - 那么你可以注入一个模拟来帮助解决这个问题,你的行为会相应地改变

A show uses the reputation rules for its reputation

// Given the reputation rules
(mock out the reputation)

// When a show is created with a director
(create the show)

// And it's shown for 3 nights with varying reviews
(associate the reviews with the show)

// Then it should use the rules to calculate its reputation
(verify that when you get the reputation, the show asks the mock for help).

:这让您了解哪些地方可能需要模拟,哪些地方可能不需要。你练习得越多,这就会变得越自然。

I find it helps to think of TDD as writing an example of how to use something, and why the behavior is interesting.

So for instance, in your application you might have this behavior:

A show is associated with a director when it's created.

However, that's not very interesting. Why is this valuable? Where is it used? If you can show some aspect of behavior in which this is important, that's more interesting.

A show's reputation starts off with its director's reputation.

You can then write an example of this behavior:

Given a director with a reputation of 75%
When he creates a new show
Then the show should start with a reputation of 75%.

That would be more interesting behavior. We can actually create a show with that reputation, without using Hibernate. I sometimes put examples like this as comments in the test. (I'm using this as an example, since I have no idea why creating a show with a director is important to you!)

For something like NHibernate, either use full-stack scenarios that cover the entire application, or integration tests which just check the mappings by constructing a show with its director, or check manually that the application works. You can assume that NHibernate will continue to work if you're using it in the right way, so you need fewer tests around it compared to the code you're going to change.

My experience is that it's OK to create real domain objects (Show, Director, etc.) rather than mocking them out. However, if you have any complex calculations - for instance, perhaps there are complexities to calculating the reputation of a Show once it's been on for several nights - then you can inject a mock to help with that, and your behavior will change accordingly:

A show uses the reputation rules for its reputation

// Given the reputation rules
(mock out the reputation)

// When a show is created with a director
(create the show)

// And it's shown for 3 nights with varying reviews
(associate the reviews with the show)

// Then it should use the rules to calculate its reputation
(verify that when you get the reputation, the show asks the mock for help).

Hope this gives you an idea of where it might be useful to mock, and where it's likely that you don't have to. This becomes more natural the more you practice.

只涨不跌 2024-12-13 13:25:05

只需创建一个 IDirector 接口,并将其放入显示实体的构造函数中。这样,您可以在分配给演出之前创建导演的模型(测试)实现。只需使用一些虚拟数据或我们的 Rhino Mocks 自己实现 IDirector 接口即可。请参阅http://haacked.com/archive/2006/06/23/usingrhinomockstounittesteventsoninterfaces。 aspx 为例。

Just create an IDirector interface that you will put in the constructor of the Show Entity. That way you can create a mockup (test) implementation of your Director before assigning to the show. Just implement the IDirector interface yourself with some dummy data, or us Rhino Mocks. See http://haacked.com/archive/2006/06/23/usingrhinomockstounittesteventsoninterfaces.aspx for an example.

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