NUnit 是 Selenium 测试的糟糕选择吗？
在搜索 NUnit + 依赖方法 + 测试执行顺序时，我已经阅读了无数关于 SO 的答案。每一个答案都表明，强制执行单元测试的任何顺序都是极其邪恶的。
我正在使用 NUnit 编写 Selenium 测试。 所以我尝试使用单元测试框架编写集成测试！
举一个集成测试的例子（这只是一个例子）。在继续其他测试之前，我需要创建一个有效的帐户。如果创建帐户失败，那么我想中止整个测试执行。
由于我不想依赖测试的字母顺序并且本着 NUnit 的真正精神，因此决定在进行任何进一步测试之前创建一个帐户。虽然它在我看来不正确，有两个核心原因 -
- 不必要的代码重复/执行
- 如果应用程序帐户创建不起作用怎么办，我所有的测试仍然会一次又一次地尝试创建和帐户并失败
我倾向于认为 NUnit 可能不能正确处理 Selenium 测试。 但如果不是 Nunit 那么我应该使用什么？
I have read umpteen answers on SO while searching for NUnit + dependent methods + order of test execution. Every single answer suggests that forcing any set of order for unit tests is extremely evil.
I am writing Selenium tests using NUnit.
So I am trying to write integration tests using Unit testing framework!!!
To cite an example of integration tests (and this is just one example). I need to create a valid account before proceeding with other tests. If creation of account fails then I would like to abort entire test execution.
Since I don't want to rely on alphabetic order of test and in true spirit of NUnit, decided to create an account before any further test. Though it does not look right to me for two core reasons -
- Unnecessary code duplication/execution
- What if application account creation is not working, all my tests would still try to create and account again and again and failing
I am inclined to think that NUnit may be not be right deal with Selenium tests.
But if not Nunit then what should I use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Selenium Core 本身附带了一个用 Javascript 编写的 TestRunner，您可以直接从浏览器运行测试。
有关更多信息，请参阅：
http://www. developerfusion.com/article/84484/light-up-your-development-with-selenium-tests/
除此之外，使用 Nunit 和用 C# 编写的测试更容易编写和维护。您在编写测试时是否使用 SetUp 和 TearDown？这样你就可以避免代码重复。
关于第二点，您可以在第一次设置失败时设置一个标志，并在下次设置时跳过设置，或者设置本身跟踪它并在下次快速失败。如果 Nunit 中的安装失败，则测试不会运行。
Selenium Core itself comes with a TestRunner that is written in Javascript and you can run your tests directly from the browser.
For more see:
http://www.developerfusion.com/article/84484/light-up-your-development-with-selenium-tests/
Apart from that, using Nunit and tests written in C# are much more easier to write and maintain. Are you using SetUp and TearDown while writing your tests? That way you can avoid code duplication.
Regarding you second point, you can have a flag that is set on first setup failure and skips the setup the next time or the setup itself tracking it and quickly failing the next time. And tests don't run if setup fails in Nunit.
我一直用 NUnit 运行 Selenium。这仅取决于您如何编写测试。为了避免代码重复，我创建了一个辅助函数库，这些函数可以执行常见操作，例如登录或注销我的网站，其他测试可以使用该库来访问他们需要测试的页面。 （我在宽松的意义上使用术语“库”；我实际上并没有将它们拆分到自己的 C# 项目中。）
你是对的，如果帐户创建功能被破坏，其他测试将失败。但就我个人而言，我不认为这是一个问题，因为单元测试的目的是确保您的更改不会在项目的其他地方产生意想不到的影响。如果帐户创建失败，显然会影响很多事情。如果我的登录帮助程序方法失败，情况也是如此：如果您无法登录，则无法访问网站中的任何内容。实际上，整个网站都被破坏了。
I run Selenium with NUnit all the time. It just depends on how you write your tests. To avoid code duplication, I make a library of helper functions that do common things, like log in or log out of my site, that the other tests use to get to the page they need to test. (I use the term 'library' in a loose sense; I don't actually split them into their own C# project.)
You are right that if the account creation function is broken, the other tests will fail. But personally, I don't see that as a problem, as the point of unit tests is to make sure that your changes didn't have unintended effects elsewhere in your project. If the account creation broke, clearly that affects a lot of things. Ditto if my login helper method fails: if you can't log in, you can't get to anything in the site. Effectively, the whole site is broken.
如果您需要在每次测试中创建新帐户，那么我将采取的方法是将该代码移至您的设置代码中。如果您的某些测试不需要登录，请将它们分成不同的文件。
任何重复的部分都应该被删除，测试代码应该像生产代码一样干净和健壮。使用不同的测试拆分文件有助于维护单一职责的理念。
If you need to create new accounts on each test then the approach that I would take is to have that code moved into your SetUp code. If some of your tests don't require login, split them out into different files.
Any bits of duplcation should be removed, test code should be as clean and robust as production code. Splitting the files with different tests help maintain the idea of Single Responsibility.
你也看过PNunit吗？
请参阅此问题中的答案之一：
有没有人找到并行运行 C# Selenium RC 测试的方法？
我仍然不是 100% 确定 TestNG 如何与网格一起工作，假设您有一个 3 步注册过程，并将其分开在 3 次测试中。 TestNG with grid 能帮到你吗？我想不会，或者它会检测到测试 C 需要让测试 A 和 B 在同一线程上运行吗？
PNunit 看起来可以提供一种将相关测试分发到同一台机器的方法。尽管设置起来可能相当复杂。
Did you also look at PNunit?
See one of the anwers in this question:
Has anyone found a way to run C# Selenium RC tests in parallel?
I'm still not 100% sure how TestNG would work with grid, suppose you have a 3-step registration process and you divide this up in 3 tests. Is TestNG with grid going to help you here? I suppose not, or will it detect that test C needs to have test A and B runned on the same thread?
PNunit looks like it could provide a way to distribute dependent tests to the same machine. Although it's probably quite complicated to set up.
对于您所描述的问题作为 AutomatedTester 的答案，有两种方法可能会对您有所帮助：
首先，NUnit 2.4.4 定义了一个SuiteAttribute，它允许您按照您想要的顺序运行测试。非常方便，但它有一个主要限制：它与 TestCaseAttribute 不兼容。这意味着您的所有测试只能由 TestAttribute 触发；如果您的目标是覆盖基于值的边界测试（因此有几个数据驱动的测试用例），这是非常烦人的。更多信息请参阅 http://www.nunit.org/index。 php?p=suite&r=2.5.10
另一种方法是准备一个专门为您的测试用例定制的集成示例数据库。假设您有一个 15 个步骤的注册流程：创建一个学生记录并将其推送到第一步，然后创建另一个学生并将其推送到第二步，依此类推。保存您的数据库并将其恢复为测试夹具设置。然后让不同的学生测试每个步骤。
在大多数情况下，对每个步骤的不同记录进行集成测试是完全有效的，因为它提供了相同的功能和代码覆盖范围，并且它遵循集成测试的思想，因为数据库中的记录是真实记录（由 UI 创建）以及 UI 带来的所有缺陷）。
当然，由于您必须存储数据库副本，因此它需要更多的运行时间和存储空间。如果您的系统无法承受，那么您可能需要考虑第一个解决方案。
它还为您提供了即使早期步骤不稳定也能够发现后续步骤中的错误的优势：所有测试都在每个测试活动上运行，而您要求的解决方案中并非如此。
Two approaches might help you, with the problem you describe as an answer to AutomatedTester:
First, NUnit 2.4.4 defines a SuiteAttribute that lets you run tests in the order you want. Very handy but it has a major restriction: it is not compatible with TestCaseAttribute. That means all your tests have to be triggered only by TestAttribute; which is very annoying if you target coverage of value-based boundary tests (thus several data-driven test cases). More info on http://www.nunit.org/index.php?p=suite&r=2.5.10
Another approach is to prepare an integration sample database tailored just for your test cases. Say you have a 15-steps registration process: create a student record and push it to step one, then another student and push it to step two, and so on. Save your database and restore it as test fixture setup. Then test each step with a different student.
It is perfectly valid in most cases to do integration tests on different records for each step, as it provides the same functionwise and codewise coverage, and it follows the idea of integration testing because your records in the DB are true records (created by the UI with all flaws that comes with the UI).
Of course it needs more time to run and storage space because of the DB copies you'll have to store. If your system can't afford that, then you'll probably want to look at the first solution.
It also gives you the advantage of being able to spot bugs on later steps even if earlier steps are unstable: all tests are run on each test campaign which is not the case in the solution you ask for.