TDD 和测试数据 [英] TDD and Test Data

问题描述

我是 TDD 的新手，想知道从哪里开始.我已经尽可能多地阅读了我认为可以而不会呕吐的内容，但仍然对测试什么和不测试什么感到困惑.例如，我从阅读中知道，我们不应该对数据库进行测试，从而进入模拟框架.我们模拟我们的存储库，以便它们返回假数据.我的问题是我们是否测试数据常量的要求?例如，一个需求可能会声明，一个人应该总是有一个名字，因此:

I'm new to TDD and was wondering where to begin. I've read about as much as I think I can without throwing up and am still confused what to test and what not to test. For example, I know, from reading, we should not run tests against databases, thus enters the mocking framework. We mock our repositories so they will return fake data. My question is do we test requirements for data constants? For example, a requirement may state, a person should always have a name, thus:

Assert.IsNotNull(personObject.Name);

应该总是正确的，但是我如何在没有假"数据的情况下测试它?我是否愿意测试这种类型的需求?

Should always be true, but how do I test it without have "fake" data? Do I care to test that type of requirement?

推荐答案

让我们来看看你的要求一个人应该永远有一个名字".我们可以从哪里开始?

Let's take your requirement "a person should always have a name". Where could we start?

首先，我们需要澄清一下.我相信当你说应该总是有一个名字"时，你的意思是不应该有一个空字符串"作为一个名字.

First, we need some clarity. I believe that when you say "should always have a name", you mean "should never have a null or empty string" as a name.

我们在这里可能真正的意思是当一个人存储在我们的数据库中时，它的名字不能为空或为空".第一线攻击是在数据库中使用约束来强制执行；然而，没有什么可以保护您免受恶意 DBA 删除该约束，因此您可能需要测试您认为系统的真实情况，如果它发生变化，将被失败的测试标记.为此，您将编写一个测试，例如当我的应用程序发送一个具有 Null 名称的 Person 以保存到数据库时，它应该会失败".这不是一个单元测试，它更像是一个集成测试 - 编写起来比一个好的旧单元测试更复杂.

What we probably really mean here is "when a person is stored in our database, its name cannot be null or empty". The first line of attack would be to enforce that with a constraint in your database; however, nothing protects you against a rogue DBA removing that constraint, so you may want to test that what you think is true about the system, will be flagged by a failing test if it changes. For this purpose you would write a test like "when my app sends a Person with a Null name to be saved to the DB, it should fail miserably". That's not a unit test, it is more of an integration test - and it is more complicated to write than a good old unit test.

然而，这仍然没有涵盖流氓 DBA 删除约束并直接创建具有空名称的记录的场景.换句话说，您的应用程序不能相信它返回的数据是正确的，因此问题变成了:您希望您的域如何处理具有空名称的人的可能性?

However, this still doesn't cover the scenario of a rogue DBA removing the constraint and directly creating records which have null names. In other words, your app cannot trust the data it gets back to be correct, so the question becomes: how do you want your domain to deal with the possibility of persons with null names?

一种非常直接的方法可能是强制 Person 只能用非空的 Name 构造，否则抛出.这很容易进行单元测试和执行，但可能会使开发变得痛苦.一个更愉快的方法是对 Person 没有限制，而是一个 Validator 类，它可以验证一个人的违反规则.这更可口，因为你现在可以对一个人做任何你想做的事情(比喻)，然后验证那个人是否仍然处于有效状态.

A very literal approach could be to enforce that Person can only be constructed with non-null Name, and throws otherwise. That would be easy to unit test and enforce, but will probably make development painful. A more pleasant approach would be to have no constraints on Person, but a Validator class, which can Validate a Person for broken rules. This is more palatable because you could now do anything you wish to a Person (figuratively) and then Validate whether that Person is still in a Valid state.

这样做的好处是

1) 非常容易测试:为这样的验证器创建单元测试是小菜一碟，

1) being very easily testable: creating a Unit Test for such a validator is a piece of cake,

2) 解决流氓 DBA 问题:您现在可以通过应用验证器来验证来自应用程序外部或进入应用程序外部的所有内容.

2) addressing the rogue DBA issue: you can now Validate everything that comes from or goes to the outside of the app, by applying the Validator.

所以，作为一个懒惰的开发人员，这就是我要开始的地方:使用验证器，因为它解决了我的问题，同时比涉及数据的东西更容易测试.换句话说，一般来说，我倾向于尽可能多地使用单元测试(即完全在内存中)，并在代码/域中尽可能多地使用我的业务逻辑，因为将所有内容合而为一更容易地方，更容易测试.

So, being the lazy developer that I am, this is where I would start: go with the Validator, because it addresses my problem, while being much easier to test than something involving the data. In other words, in general I tend to stick as much as possible with Unit Tests (i.e. completely in memory), and to have as much as I can of my business logic in the code / domain, because it's easier to have all in one place, and easier to test.

这篇关于TDD 和测试数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！