测试类 - 何时重构？
我正在使用 NUnit 和 Selenium 在 C# 中编写一系列自动测试。
编辑：我正在测试整个网站，首先我为使用该网站的三种类型的成员编写了三个类，这些类包含使用 selenium 来由这些成员执行各种操作的方法。然后创建这些类，并由我的测试类使用适当的输入调用它们的方法。
我的问题是：
我的测试班有多大有关系吗？ （即数千个测试？）
什么时候重构我的功能类？ （25 或 50 种方法，1000 行代码等）
我一直在尝试阅读有关测试设计的所有内容，因此如果您有任何好的资源，我将不胜感激链接。
I'm writing a series of automatic tests in C# using NUnit and Selenium.
Edit: I am testing an entire website, to begin I wrote three classes for the three types of members that use the website, these classes contain methods which use selenium to perform various actions by these members. These classes are then created and their methods called by my test classes with the appropriate inputs.
My question is:
Does it matter how large my test class becomes? (i.e. thousands of tests?)
When is it time to refactor my functionality classes? (25 or 50 methods, 1000 lines of code, etc)
I've been trying to read all I can about test design so if you have any good resources I would appreciate links.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的。测试需要长期维护，庞大的测试类难以理解和维护。
当您开始感觉很难找到特定的测试用例，或者浏览与特定场景相关的测试时。我认为这里没有硬性限制，就像生产类的大小或方法的数量没有硬性限制一样。我个人对测试代码的限制比对生产代码的限制更高，因为测试代码往往更简单，因此开始变得难以理解的门槛更高。但总的来说，具有 50 个测试方法的 1000 行测试类对我来说开始感觉太大了。
我最近不得不使用这样一个测试类，最后我对其进行了分区，所以现在我有几个测试类，每个测试类测试特定类*的一个特定方法/用例。我设法将一些旧测试转换为参数化测试，并且所有新测试都编写为参数化测试。我发现参数化测试可以更轻松地纵览全局，并立即牢记所有测试用例。我在 Java 项目上使用 JUnit 完成了此操作，但我看到 NUnit 2.5 现在也提供了参数化测试 - 您应该检查一下。
*您可能会正确地问，如果我们需要这么多测试用例来覆盖被测试的类，是否应该重构它 - 是的，最终应该重构。它是我们遗留应用程序中最大的类，里面有太多的东西。但首先我们需要准备好测试用例:-) 顺便说一句，这也可能适用于您的类 - 如果您需要这么多测试用例来覆盖它，则可能是被测类试图做太多事情，你最好将它的一些功能提取到一个单独的类中，并带有自己的单元测试。
Yes it does. Tests need to be maintained in the long term, and a huge test class is difficult to understand and maintain.
When you start to feel it is awkward to find a specific test case, or to browse through the tests related to a specific scenario. I don't think there is a hard limit here, just as there is no hard limit for the size of production classes or the number of methods. I personally put the limits higher for test code than for production code, because test code tends to be simpler, so the threshold where it starts to become difficult to understand is higher. But in general, a 1000 line test class with 50 test methods starts to feel too big for me.
I just recently had to work with such a test class, and I ended up partitioning it, so now I have several test classes each testing one particular method / use case of a specific class*. Some of the old tests I managed to convert into parameterized tests, and all new tests are written as paramterized tests. I found that parameterized tests make it much easier to look through the big picture, and keep all test cases in mind at once. I did this using JUnit on a Java project, but I see NUnit 2.5 now offers parameterized tests too - you should check it out.
*You may rightly ask shouldn't the class under test be refactored if we need so many test cases to cover it - yes it should, eventually. It is the largest class in our legacy app, with way too much stuff in it. But first we need to have the test cases in place :-) Btw this may apply to your class too - if you need so many test cases to cover it, it might be that the class under test is just trying to do too much, and you would be better off extracting some of its functionality into a separate class, with its own unit tests.