我整个下午一直在谷歌搜索，但一直在努力找到解决问题的可行办法。
基本上，我已经开始了一些Angular开发并拥有大约700行的控制器。我的spec文件大约是2100行，我有100％的代码覆盖率。我发现无论何时我需要更换控制器，我都要修理5个单元测试。他们没有找到我的错误。 我没有使用TDD方法，也许这就是问题所在？编写代码然后编写测试。 我问，因为我在网上阅读的任何地方，普遍的共识是单元测试很棒。我任何时候都没有看到任何价值，他们花了我太多时间。
如果有人有任何建议，我会非常感激。
答案 0 :(得分：4)
700线控制器和2100线规格文件几乎意味着您很少遵守separation of concerns principle（或single responsibility principle）。
这是Angular中的常见问题，开发人员倾向于污染范围和控制器，而不是将责任分配给服务和指令。一个好的做法是让控制器启动范围并提供事件处理程序，但是大多数逻辑应该驻留在服务中，除非它特定于控制器的实际视图（可重用的视图逻辑在指令中，可重用的“业务”逻辑进入服务）。
反过来，这通常转化为高水平的依赖性，这一事实表明5个测试在单个变化时失败。从理论上讲，适当的单元测试意味着单个测试只能在单个测试中失败;实际情况并非如此，因为我们懒得模拟一个单元的所有依赖关系，但这并不是什么大问题，因为一旦我们修复了有问题的代码，依赖的失败测试就会通过。
进行测试但不遵循TDD比完全没有测试要好，但不太理想。
测试通常有3个目的（3个D）：
除非是TDD的一部分，否则您缺少设计位和大部分文档位。
以后考虑编写测试通常不能确保代码正常工作，而是确保代码工作正常。在后编码测试中非常诱人的是为某个输入提供一个函数，使测试失败，但看看实际输出是什么，并使这个输出成为预期的输出 - 这并不意味着输出是正确的，只是它它是什么。首先编写测试时不会发生这种情况。