C# 编写单元测试时如何知道要测试什么？

How do you know what to test when writing unit tests?

提问by Mike Roosa

Using C#, I need a class called Userthat has a username, password, active flag, first name, last name, full name, etc.

使用 C#，我需要一个名为的类User，它具有用户名、密码、活动标志、名字、姓氏、全名等。

There should be methods to authenticateand savea user. Do I just write a test for the methods? And do I even need to worry about testing the properties since they are .Net's getter and setters?

应该有方法来验证和保存用户。我只是为这些方法编写测试吗？我什至需要担心测试属性，因为它们是 .Net 的 getter 和 setter 吗？

采纳答案by Rob Cooper

Many great responses to this are also on my question: "Beginning TDD - Challenges? Solutions? Recommendations?"

关于这个问题的许多很好的回应也来自我的问题：“开始 TDD - 挑战？解决方案？建议？”

May I also recommend taking a look at my blog post(which was partly inspired by my question), I have got some good feedback on that. Namely:

我还可以推荐看看我的博客文章（部分灵感来自我的问题），我得到了一些很好的反馈。即：

I Don't Know Where to Start?

• Start afresh. Only think about writing tests when you are writing new code. This can be re-working of old code, or a completely new feature.
• Start simple. Don't go running off and trying to get your head round a testing framework as well as being TDD-esque. Debug.Assert works fine. Use it as a starting point. It doesn't mess with your project or create dependencies.
• Start positive. You are trying to improve your craft, feel good about it. I have seen plenty of developers out there that are happy to stagnate and not try new things to better themselves. You are doing the right thing, remember this and it will help stop you from giving up.
• Start ready for a challenge. It is quite hard to start getting into testing. Expect a challenge, but remember – challenges can be overcome.

Only Test For What You Expect

I had real problems when I first started because I was constantly sat there trying to figure out every possible problem that could occur and then trying to test for it and fix. This is a quick way to a headache. Testing should be a real YAGNI process. If you know there is a problem, then write a test for it. Otherwise, don't bother.

Only Test One Thing

Each test case should only ever test one thing. If you ever find yourself putting “and” in the test case name, you're doing something wrong.

我不知道从哪里开始？

• 重新开始。只有在编写新代码时才考虑编写测试。这可以是旧代码的重新工作，也可以是全新的功能。
• 开始简单。不要跑掉并试图让你的头脑绕过测试框架以及成为 TDD 式的。Debug.Assert 工作正常。使用它作为起点。它不会干扰您的项目或创建依赖项。
• 开始积极。你正在努力提高你的手艺，对此感觉良好。我见过很多开发人员乐于停滞不前，而不是尝试新事物来改善自己。你在做正确的事情，记住这一点，这将有助于阻止你放弃。
• 开始准备迎接挑战。开始测试非常困难。期待挑战，但请记住——挑战是可以克服的。

只测试你所期望的

刚开始时我遇到了真正的问题，因为我经常坐在那里试图找出可能发生的每个可能的问题，然后尝试对其进行测试并修复。这是解决头痛的快速方法。测试应该是一个真正的 YAGNI 过程。如果您知道存在问题，则为它编写一个测试。否则，不要打扰。

只测试一件事

每个测试用例应该只测试一件事。如果您发现自己在测试用例名称中添加了“and”，那么您就做错了。

I hope this means we can move on from "getters and setters" :)

我希望这意味着我们可以从“getter 和 setter”继续前进 :)

回答by UnkwnTech

I can't speak for C# specificly, but when I write unit tests I test EVERY input, even those the user does not do, that way I know how to prevent my own mistakes.

我不能专门说 C#，但是当我编写单元测试时，我会测试每个输入，即使是那些用户没有做的输入，这样我就知道如何防止自己的错误。

回答by Slavo

The rule is that you have to test every piece of logic you write. If you implemented some specific functionality in the getters and setters I think they are worth testing. If they only assign values to some private fields, don't bother.

规则是您必须测试您编写的每条逻辑。如果您在 getter 和 setter 中实现了某些特定功能，我认为它们值得测试。如果他们只为某些私有字段赋值，请不要打扰。

回答by Onorio Catenacci

As I understand unit tests in the context of agile development, Mike, yes, you need to test the getters and setters (assuming they're publicly visible). The whole concept of unit testing is to test the software unit, which is a class in this case, as a black box. Since the getters and setters are externally visible you need to test them along with Authenticate and Save.

正如我所理解的敏捷开发上下文中的单元测试，迈克，是的，您需要测试 getter 和 setter（假设它们是公开可见的）。单元测试的整个概念是测试软件单元，在这种情况下是一个类，作为一个黑盒。由于 getter 和 setter 是外部可见的，因此您需要与 Authenticate 和 Save 一起测试它们。

回答by Bob King

It doesn't hurt to write unit tests for your getters and setters. Right now, they may just be doing field get/sets under the hood, but in the future you may have validation logic, or inter-property dependencies that need to be tested. It's easier to write it now while you're thinking about it then remembering to retrofit it if that time ever comes.

为你的 getter 和 setter 编写单元测试并没有什么坏处。现在，他们可能只是在幕后进行字段获取/设置，但将来您可能会有验证逻辑或需要测试的属性间依赖关系。现在在考虑它的时候写它会更容易，然后记住如果那个时候来改造它。

回答by Tom Walker

If the Authenticate and Save methods use the properties, then your tests will indirectly touch the properties. As long as the properties are just providing access to data, then explicit testing should not be necessary (unless you are going for 100% coverage).

如果 Authenticate 和 Save 方法使用这些属性，那么您的测试将间接接触这些属性。只要属性只是提供对数据的访问，就不需要进行显式测试（除非您要 100% 的覆盖率）。

回答by Tim Howland

Test your code, not the language.

测试你的代码，而不是语言。

A unit test like:

一个单元测试，如：

Integer i = new Integer(7);
assert (i.instanceOf(integer));

is only useful if you are writing a compiler and there is a non-zero chance that your instanceofmethod is not working.

仅当您正在编写编译器并且您的instanceof方法不工作的可能性非零时才有用。

Don't test stuff that you can rely on the language to enforce. In your case, I'd focus on your authenticate and save methods - and I'd write tests that made sure they could handle null values in any or all of those fields gracefully.

不要测试你可以依靠语言来执行的东西。在您的情况下，我会专注于您的身份验证和保存方法 - 我会编写测试以确保它们可以优雅地处理任何或所有这些字段中的空值。

回答by Peter Bernier

I would test your getters and setters. Depending on who's writing the code, some people change the meaning of the getter/setter methods. I've seen variable initialization and other validation as part of getter methods. In order to test this sort of thing, you'd want unit tests covering that code explicitly.

我会测试你的 getter 和 setter。根据编写代码的人的不同，有些人会更改 getter/setter 方法的含义。我已经看到变量初始化和其他验证是 getter 方法的一部分。为了测试这类事情，您需要明确地覆盖该代码的单元测试。

回答by tronda

Personally I would "test anything that can break" and simple getter (or even better auto properties) will not break. I have never had a simple return statement fail and therefor never have test for them. If the getters have calculation within them or some other form of statements, I would certainly add tests for them.

就我个人而言，我会“测试任何可能损坏的东西”并且简单的 getter（甚至更好的自动属性）不会损坏。我从未有过简单的 return 语句失败，因此从未对它们进行过测试。如果 getter 中有计算或其他形式的语句，我当然会为它们添加测试。

Personally I use Moqas a mock object framework and then verify that my object calls the surrounding objects the way it should.

我个人使用Moq作为模拟对象框架，然后验证我的对象是否以它应该的方式调用周围的对象。

回答by m_pGladiator

You have to cover the execution of every method of the class with UT and check the method return value. This includes getters and setters, especially in case the members(properties) are complex classes, which requires large memory allocation during their initialization. Call the setter with some very large string for example (or something with greek symbols) and check the result is correct (not truncated, encoding is good e.t.c.)

您必须使用 UT 覆盖类的每个方法的执行并检查方法返回值。这包括 getter 和 setter，尤其是在成员（属性）是复杂类的情况下，在初始化期间需要大量内存分配。例如，使用一些非常大的字符串（或带有希腊符号的东西）调用 setter 并检查结果是否正确（未截断，编码良好等）

In case of simple integers that also applies - what happens if you pass long instead of integer? That's the reason you write UT for :)

在同样适用的简单整数的情况下 - 如果传递 long 而不是整数会发生什么？这就是你写 UT 的原因:)

回答by Steve Cooper

If they really are trivial, then don't bother testing. Eg, if they are implemented like this;

如果它们真的是微不足道的，那么就不要费心进行测试。例如，如果它们是这样实现的；

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
}

If, on the other hand, you are doing something clever, (like encrypting and decrypting the password in the getter/setter) then give it a test.

另一方面，如果您正在做一些聪明的事情（例如在 getter/setter 中加密和解密密码），则对其进行测试。