是否值得努力编写与浏览器一起使用的测试（如使用selenium或其他东西）？

Question

为服务器端的内容编写测试非常值得，但我听说为UI内容编写单元测试真的很难，而且它们很脆弱且不可靠。我希望更有信心，我所做的更改不会破坏我网站上导入页面的主要部分。

任何想法或经历？

Answer 1

UI测试可能是缓慢，脆弱和难以维护的，但是一些错误只能在UI测试中捕获。重要的问题不是编写UI测试是否值得，而是如何保持UI测试的有用性，稳定性和可维护性。

常见的错误是使用UI测试代替其他测试。从理论上讲，您可以通过UI测试测试许多功能，但这种方法存在许多问题。对于初学者来说，在UI中直接测试某些功能可能非常困难（特别是在特殊条件下）。其次，如果测试失败，通常很难看出问题的根源是什么。最后，您在UI测试中测试的代码路径越多，UI测试就越慢。如果你只依靠缓慢的测试，你的工作效率会变差，这会增加“暂时”关闭破坏测试的诱惑。

我的建议是尽可能在单元测试和集成测试中进行测试，在UI和业务逻辑之间建立良好的分离，并使用UI测试来捕获/防止在其他类型的测试中无法测试的错误

如果您有很多测试，请考虑创建多个套件。我为UI测试创建了一个套件，一个用于集成测试，一个用于单元测试。单元测试非常快，所以我在开发代码时运行它们（通常通过TDD）。这些测试可以帮助我提高工作效率。

我经常运行的集成测试（可能在我完成了一些更改之后）。我正准备提交更改时运行的UI测试（或者当我写更多UI测试时，显然）。

最后一点建议：考虑使用Domain Specific Language编写UI测试。这使得更容易理解测试（因为它们读作一组用户步骤而不是一堆低级浏览器操作）。它还可以使代码更容易维护。例如，您可能会看到：

，而不是让每个测试都通过逐步浏览器操作来记录用户。

LoginPage loginPage = new LoginPage(selenium);
HomePage homePage = loginPage
    .enterUserName(TestUsers.Alice.USER_NAME)
    .enterPassword(TestUsers.Alice.PASSWORD)
    .submit();
assertThat(homePage.getBreadcrumbs(), equalTo("Home"));

Answer 2

这很容易，可以由不那么技术的人来完成，绝对值得付出努力。 UI测试很难用于桌面应用程序，对于Web应用程序来说并不难，因为您可以移动控件并且selenium仍然可以在HTML中找到它们。对于糟糕的桌面开发者来说，没有这样的好运。

当然，总有一种可能性，你过度使用它不会给你很多回报，但它与正常的单元测试相同。你应该知道什么时候停止。

Answer 3

我将它们作为开发的一部分。很酷的事情是你可以在IE中执行它们（你需要selenium服务器）。我只在开发阶段使用它们，不要像单元测试那样对待它们。如果我做一些UI特定的逻辑，他们确实帮助很多。

最重要的是为所有使用过的html元素分配id。没有它，测试非常脆弱。使用评论也有帮助。

Answer 4

您编写的测试越多，覆盖应用程序的不同动态就越好。当您需要更改应用程序生成的页面上的内容时 - 您的测试将告诉您是否有任何中断。

是的，他们是脆弱的，是的，这让痛苦的选择路径工作得恰到好处......

Answer 5

您可以使用browsershots.org检查几乎所有浏览器中的网页外观。