我应该初始化每个测试方法，还是只初始化类，或者两者都不初始化？
我向自己（现在向整个世界，甚至更远的地方）提出的问题是在我下面的评论中：
[TestMethod()]
public void SetMessageTypeSubcodeTest()
{
int AMessageTypeSubcode;
// Should I put this class instantiation in MyTestInitialize?
MessageClass target = new MessageClass();
. . .
我应该这样做：
[TestInitialize()]
public void MyTestInitialize()
{
MessageClass target = new MessageClass();
}
...还是这样：
[ClassInitialize()]
public void MyTestInitialize()
{
MessageClass target = new MessageClass();
}
...或者两者都不做？
由于 C#/.NET 是垃圾收集的，因此无需在 TestCleanup() 或 ClassCleanup() 方法中释放 MessageClass，不是吗？
The question I pose to myself (and now to the entire world, and perhaps beyond), is in my comment below:
[TestMethod()]
public void SetMessageTypeSubcodeTest()
{
int AMessageTypeSubcode;
// Should I put this class instantiation in MyTestInitialize?
MessageClass target = new MessageClass();
. . .
Should I do this:
[TestInitialize()]
public void MyTestInitialize()
{
MessageClass target = new MessageClass();
}
...or this:
[ClassInitialize()]
public void MyTestInitialize()
{
MessageClass target = new MessageClass();
}
...or neither?
And since C#/.NET is garbage collected, there's no need to free MessageClass in the TestCleanup() or ClassCleanup() method, is there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您需要为您的集合中的每个测试测试类的全新实例。这将防止任何可能的副作用（可能发生），并且结果测试（应该是单位，分开）相互影响。
You want brand new instance of class you're testing for every single test in your set. This will prevent any possible side effects (which may happen), and as a result tests (which should be units, separated) influencing one another.
除非类的构建成本很高，否则每次测试都要进行。保证你有一个干净的记录。你是对的，你也不需要在测试结束时进行任何清理，除非你正在测试的特定内容需要它（数据库连接关闭，网络协议的关闭握手等）
Unless construction of the class is expensive, do it every test. Guarantee you have a clean slate. You're right, you don't need to do any cleanup at test end either, unless the specific thing you're testing needs it (database connections closing, closing handshakes for web protocols, etc)
这个问题没有真正的“正确”答案。就我个人而言，考虑到您的代码，我不会将该类实例化放入任何类型的设置方法中。我会将其保留在每个测试中，以使测试更具可读性和完整性。
我相信使用 ClassInitialize 或 TestInitialize 方法的正确时机是当您想要为该类中的所有测试创建一个一致的环境时。这也是为什么我不喜欢“每个系统类单个测试类”方法的原因。每个测试类都是一个固定装置，为其测试提供一致的环境。
过度激进地重构测试代码以将每个“new Foo()”移动到 TestFixture 中将导致奇妙的分解，但难以阅读单元测试。对于测试，我更看重可读性而不是因式分解的水平。
There is no real "right" answer to this question. Personally, given your code, I would not put that class instantiation into any kind of a setup method. I would keep that inside of each test, to make the test more readable and complete.
I believe that the right time to use a ClassInitialize or TestInitialize method is when you want to create a single consistent environment for all of the tests in that class to use. This is also why I don't like the "single test class per system class" approach. Each test class is a fixture that provides a consistent environment for its tests.
Over-aggressive refactoring of test code to move every "new Foo()" into the TestFixture will lead to wonderfully factored, but difficult to read unit tests. And for tests, I value readability over that level of factoring.
两者都不。避免/最小化在测试类中使用成员变量。尽可能在测试方法中使用局部变量。它将使每个测试更加独立/分开/独立。
如果您需要一些通用的初始化代码，请创建一个带有可选参数的辅助函数，可以从（某些）测试方法调用该函数并允许您控制初始化数据。
我们应该能够在不同的测试中使用不同的参数（例如配置选项）初始化被测系统（SUT），这就是我们在单独的测试中而不是在类级别上使用初始化的原因。
您不应该期望在特定场景中参数是相同的，当排列参数可以不同时，最好以可扩展的方式编写代码。
另请参阅 是吗在单元测试之间共享成员变量的好习惯
Neither. Avoid/minimise use of member variables in test class. Use local variables inside the test methods as much as possible. It will make each test more independent/separate/self-contained.
If you need some common initialisation code, create a helper function(s) with optional parameters, that can be called from (some) test methods and allow you to control initialisation data.
We should be able in different tests initialize system under test (SUT) with different parameters (e.g. configuration options), this is why we are using initialization in individual tests, not on class level.
You shouldn’t expect that in the specific scenarios the parameters are the same, better to write the code in an extendable way, when the arrange parameters can be different.
See also Is it a good practice to share member variables among unit tests