假设厨师可以制作食谱，副厨师长可以制作必须由主厨批准的食谱。
您想测试一下，当主厨查看她的主页时，她会看到她自己创建的食谱。您还想测试她是否看到有等待她批准的食谱。
我可以想到两种方法来做到这一点：
我非常不喜欢这两种方法。
可能还有更多的原因，但这两个是相当大的。
仅仅为了测试而有多余的标记是多么烦人！用户不应该为了测试而增加下载大小。
对此有什么好的方法？我很想听听任何替代方案，无论您使用哪种语言。我主要使用 Ruby、Test::Unit、Minitest、RSpec 和 Cucumber（尽管我的 Cuke 技能已经过时），但如果其他语言/框架弄清楚了，我也很想看看他们在做什么。
使用页面范例。
尽可能以人性化的方式表达这些步骤，尽可能在能力级别（高级），并使用具体示例。例如，如果我使用 Cucumber，我可能会说：
鉴于副厨师长创建了青蛙派的食谱
当厨师寻找要批准
的食谱时，青蛙派的食谱应该在列表中。
在这些步骤的代码中，实例化或找到您要查找的特定页面，其中该页面是表示页面功能的对象。然后，该页面可以包含用户可以对该页面执行的所有操作 - 查找食谱、批准食谱、移动到另一个页面等。
这样，如果您需要更改步骤的底层代码，您只需在一个地方更改它，特定页面的所有更改都会一起进行。因为您已经根据您要交付的功能来表述该场景，所以该场景不太可能需要进行太多更改（除非您发现您的业务需要与您所交付的功能不同的功能）。
这对于基于窗口的应用程序也很有效，每个小部件或模块都是一个特定的页面。
有额外的 id 只是为了测试也很好。有时设计师也喜欢使用它们。
我看到至少两个选项：
避免通过 UI 测试业务逻辑。编写返回纯数据结构的“服务”或“用例控制器”对象。换句话说，你为你的系统构建了一个 API。您的单元测试通过 API 访问系统。您的 UI 通过相同的 API 访问系统，但是视图中应该几乎没有逻辑。请参阅http://www.confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-years或http://www.cleancoders.com/codecast/clean-code-episode-7/show。
使用“页面对象”模式。编写一个对象，读取您的应用程序生成的 HTML 代码，对其进行解析，并通过 getter 提供有趣的数据。这将为您的测试创造奇迹代码清晰。你的反对意见可能是你仍然有问题#2。事实上，我不认为这真的是一个问题。如果您使用结构化 HTML 标记，那么提取您需要的信息应该相当容易。如果您将 ID 附加到页面的关键元素会容易得多；在您的示例中，我将有一个 id="my-recipes" 的 div 和另一个 id="to-be-approved" 的 div。这应该足够了；使用 xpath 或 css 选择器应该很容易找到其他任何东西。为什么你觉得这令人反感？这些 ID 可能对其他用途有用，例如使用不显眼的 JavaScript 附加行为或使用 CSS 样式表附加样式。
我个人尽量不测试视图。我的意思是生成的标记，因为这些测试看起来非常脆弱。
相反，我专注于“数据提供者”方面，如果 MVC Web 框架是控制器。一旦控制器被单元测试覆盖，检查控制器准备了什么类型的数据，你就非常安全了。您创建的视图很容易测试，只需运行应用程序并查看它看起来是否正常。
尽管如此，还是有一些视图测试的方法。第一个是基于 Selenium Driver 的“端到端”测试模拟。它运行浏览器并初始化对您的应用程序的请求。测试正在检查输出 HTML。测试登录到“已知”版本，这意味着测试知道当前本地化是EN，例如。
您应该基本上结合使用 HTML 标记值（“Recipies”）的方法，否则使用 HTML 元素 id 或类。我不会为测试添加任何额外的标记。
您可以尝试的另一种方法是批准测试。我相信有一个 Ruby 驱动程序 - http://approvaltests.sourceforge.net/。获得批准后，您可以渲染视图并将 HTML 保存为黄金母版。如果 View 已更改，测试将失败。它比 Selenium 测试更容易实现。
与＃2一起生活，也许使用简短的评论（没有i18n问题并且对最终用户不可见）：
<!-- APPROVAL -->
simpletest的文档对此有很好的理解：
下一个机会，看看电路板，也许是你现在正在看的计算机的主板。在大多数电路板上，您会发现奇怪的空孔，或者没有任何连接的焊点，或者可能是没有明显功能的引脚或插座。其中一些可能用于扩展和变化，但其余大部分将用于测试。
如果少量多余的标记使您的产品更可测试和更可靠，那就忍受它吧！