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