单位测试你自己的htmlhelpers是否有任何实际价值？这些东西中的许多只是吐出一堆html标记 - 如果没有逻辑则几乎没有。那么，你只是比较一个大的HTML字符串到另一个？我的意思是，其中一些要求你在浏览器中查看生成的标记，以验证它是你想要的输出。
似乎有点无意义。
答案 0 :(得分：2)
是
虽然现在可能几乎没有逻辑，但这并不意味着将来不会有更多的逻辑。添加该逻辑后，您需要确保它不会破坏现有功能。
这是编写单元测试的原因之一。
如果您正在关注测试驱动开发，请先编写测试，然后编写代码以满足测试要求。
这是另一个原因。
您还需要确保使用Helper识别和测试任何可能的边缘情况（例如未转义的HTML文字，未编码的特殊字符等）。
答案 1 :(得分：0)
我想这取决于有多少人会使用/修改它。我通常会为一个html助手创建一个单元测试，如果我知道很多人可以得到它，或者逻辑很复杂。如果我将成为唯一一个使用它的人，我不会浪费我的时间（或我雇主的钱）。
我可以理解你不想编写测试...编写几行需要5X的html生成代码可能会很烦人。
答案 2 :(得分：0)
它需要一个简单的输入并公开一个简单的输出。对于TDD来说，这是一个不错的选择，因为你将花费在build-＆gt; start site-＆gt;上来修复那个愚蠢的问题 - >再次开始 - > oops，错过了这个小小的东西 - ＆gt;开始。 ..我们完成了，快乐:)。 Dev 2出现并做了一些小改动，以“修复”它为那些当时不起作用的东西，同样的循环继续，dev 2在它打破你的其他场景时没有注意到。
相反，你可以快速执行v。简单的简单文本，即简单的输出为您提供了所期望的所有结束标记和引号的简单输出。
答案 3 :(得分：0)
为站点地图菜单编写HTML帮助程序，或者为向导框架编写按钮，我可以向您保证，某些帮助程序有足够的逻辑需要测试才能可靠，特别是如果打算供其他人使用。
所以这取决于你对他们的所作所为。只有你知道答案。
一般的答案是，Html Helpers可以任意复杂（或简单），具体取决于你在做什么。因此，与其他任何事情一样，毫无疑问就是在需要时进行测试。
答案 4 :(得分：0)
是的，有价值。要确定多少价值。 ; - ）
您可以从基本的“返回SOME”测试开始，而不是真正关心什么。基本上只是快速的健全测试，以防一些基本的破坏。然后当出现问题时，添加更多细节。
还要考虑让你的测试将HTML解析成DOM，这比DOM更容易测试，特别是如果你只是寻找一些特定的位。
或者......如果您对webapp本身进行了自动化测试，请确保有专门针对助手输出的测试。
答案 5 :(得分：0)
是的，应该进行测试。基本的经验法则，如果不值得测试则不值得写。
但是，在编写测试时，需要注意一点。他们有可能非常“脆弱”。
如果您编写测试以便返回特定的字符串，并且您有一些调用其他帮助程序的帮助程序。其中一个核心助手的更改可能会导致很多测试失败。
因此，最好测试一下是否返回非null值，或者特定文本是否包含在返回值的某处。而不是测试一个确切的字符串。