我的问题主要与测试方法有关。我在一家实践TDD(测试驱动开发)的组织工作。我们使用AngularJS及其完整的测试堆栈——Jasmine进行单元测试,使用Protractor进行端到端测试。
在开发功能时,我们的流程始于先编写失败的端到端测试,然后使用TDD编写功能。这些测试仅针对公共方法编写(无论是控制器/指令/服务)。产品本身不包含任何复杂逻辑(除了几个异常情况)。
最近,我们开始讨论这样一个事实:为控制器编写单元测试没有意义,因为它们正在公开功能,100%的功能都暴露给视图,并且通过端到端测试进行了测试。基本上,单元测试和端到端测试是重叠的。起初,我们都同意了,但是这个决定引发了一个潘多拉魔盒。毕竟,指令也可以说同样的话。那么为什么也要测试它们呢?然后就出现了服务的问题。其中大部分服务(98%)只是进行后端调用并返回响应。那么为什么不简单地模拟httpBackend并在测试控制器时测试服务,而这些控制器已经通过端到端测试进行了测试呢?
你明白了吗?
尽管它们实际上是重叠的,但我确实看到了进行单元测试和端到端测试的好处。主要是即时反馈和“可执行文档”。
你在实践什么?您是否看到其他好处,并且“值得一试”——为了获得上述两个好处而编写重叠测试是否值得呢?
在开发功能时,我们的流程始于先编写失败的端到端测试,然后使用TDD编写功能。这些测试仅针对公共方法编写(无论是控制器/指令/服务)。产品本身不包含任何复杂逻辑(除了几个异常情况)。
最近,我们开始讨论这样一个事实:为控制器编写单元测试没有意义,因为它们正在公开功能,100%的功能都暴露给视图,并且通过端到端测试进行了测试。基本上,单元测试和端到端测试是重叠的。起初,我们都同意了,但是这个决定引发了一个潘多拉魔盒。毕竟,指令也可以说同样的话。那么为什么也要测试它们呢?然后就出现了服务的问题。其中大部分服务(98%)只是进行后端调用并返回响应。那么为什么不简单地模拟httpBackend并在测试控制器时测试服务,而这些控制器已经通过端到端测试进行了测试呢?
你明白了吗?
尽管它们实际上是重叠的,但我确实看到了进行单元测试和端到端测试的好处。主要是即时反馈和“可执行文档”。
你在实践什么?您是否看到其他好处,并且“值得一试”——为了获得上述两个好处而编写重叠测试是否值得呢?