我有一个简单的项目，主要由后端服务代码组成。我有完全的单元测试，包括我的DAL层...我应该单元测试我的网格渲染逻辑吗？
现在我必须写前端。我重新使用我的前端可以使用的业务对象，并且有一个网格呈现一些输出。我有我的DAL对象有一些称为DisplayRecords（id）的函数，它显示给定ID的记录...
所有这些DAL对象都经过了单元测试。但是为DisplayRecords（）函数编写单元测试值得吗？这个函数调用一个存储过程，它正在做一些连接。这意味着我的单元测试将不得不建立多个表格，其中一个具有15列，并且其返回值是一个DataSet（这是我的DAL中返回数据集的唯一函数 - 因为它不值得创建一个对象只是这个网格）...
这样的东西，甚至值得测试？一般前端逻辑怎么样？人们倾向于跳过ASP.NET前端的单元测试，就像人们跳过私有函数的逻辑一样吗？我知道后者有点不同 - 测试行为与实现以及所有......但是，我只是好奇一般的经验法则是什么？
非常感谢
有重达到是否应该编写测试的几件事情：
这是关于信心。您建立测试，以便您有信心进行更改。你可以自信地做出没有测试的变化吗？
此代码对应用程序的使用者有多重要？如果这对所有事情都至关重要，那就测试一下。
如果你有回归，这有多尴尬？在我的最后一个项目中，我的目标不是回归 - 我不希望客户必须两次报告相同的错误。所以每个重要的bug都会在测试修复之前进行测试。
编写测试有多困难？有许多工具可以帮助缓解疼痛：
硒的理解和直接设置。在硒中维护一个大型测试套件可能有点贵。你需要夹具数据才能工作。
假设在其他地方进行了测试，使用模拟来剔除DAL呼叫。这样可以节省创建所有灯具数据的时间。这是测试Java/Spring控制器的常见模式。
简单地将代码以其他方式分解，以便可以对其进行测试。例如，提取格式化特定网格单元的代码，并编写单元测试，而不考虑视图代码或实际数据。
我倾向于迅速做出Selenium测试和坐视不管应用程序做它的事 - 这就是它避免了所有的手动点击快速验证方法。
完全自动化的用户界面测试很乏味，应该只在更为成熟的应用程序中完成，因为用户界面不会有太大变化。关于'中间'代码，我会测试它是否被重用和/或复杂/引入了新的逻辑，但是如果它只是或多或少地是一个新的DAL方法调用序列并且特定于单个视图，我会跳过它。