我一直在谷歌搜索整个下午，但一直在努力寻找一个可行的解决方案，我的问题。我的茉莉花测试太脆弱
基本上，我已经开始了一些Angular开发，并拥有约700行的控制器。我的规格文件大约2100行，我有100％的代码覆盖率。我一直在发现，任何时候我必须更换控制器，我必须修复大约5个单元测试。他们没有发现我的错误。 我不使用TDD方法，也许这是问题？代码被写入，然后测试被写入。 我问，因为我在网上阅读的任何地方，普遍的共识是单元测试是伟大的。我只是没有看到任何价值，他们花费我太多时间。
如果有人有任何建议，我将不胜感激。
A 700线控制器和2100线规格文件，你坚持小到separation of concerns principle（或single responsibility principle）非常手段。
这是Angular中的一个常见问题，开发人员倾向于污染范围和控制器，而不是将责任分配给服务和指令。一个好的做法是让控制器启动范围并提供事件处理程序，但大多数逻辑应该驻留在服务中，除非它特定于控制器的实际视图（可重用视图逻辑进入指令，可重用的“业务”逻辑进入服务）。
反过来，这通常意味着高水平的依赖关系，这表明5个测试失败并发生单一更改。从理论上讲，适当的单元测试意味着单个测试只能通过一次测试;在实践中这种情况很难实现，因为我们懒惰地嘲笑了一个单元的所有依赖关系，但没有什么大不了的，因为一旦我们修复了有问题的代码，相关的失败测试就会通过。
有测试，但不遵循TDD比没有在所有的测试中表现更好，但很少理想。
测试一般服务3个目的（3个DS）：
除非是TDD的一部分，否则你错过了设计位和大部分文档位。
将测试写成后思想通常不能确保代码正常工作，而是它的工作原理与此相同。在后编码测试中提供一个函数一个特定的输入是非常诱人的，使测试失败，但看看实际输出是什么，并使该输出成为预期的输出 - 这并不意味着输出是正确的，只是它就是这样。当你先写测试时，这不会发生。
单元测试没有价值回报。单元测试的目的是记录代码如何运行。当您的测试超出了这个范围时，它们成为维护的负担，但是如果做得正确的话，他们可以在未来使用，以在发生不可预见的操作时解决问题。他们没有发现错误，防止错误或提高代码质量。他们只是断言代码会执行程序员期望的操作，有时做出这些断言需要以测试友好的方式编写代码。就是这样。不要期望太多的测试。 – cgTag
@ThinkingMedia - 我完全不同意。错误测试向我透露的数量是巨大的。它们通过强制您在编写代码之前设计您的代码，从而提高代码质量。我已经编写了没有测试的代码，只是为了发现代码是不可测试的;那么在TDD的同一个目标中，代码的大小只有一半。老实说，虽然我开始使用TDD时感到怀疑和沮丧，但现在我无法想象编写代码。 – Izhaki
@Izhaki我认为这只是语义的辩论。错误和代码质量往往可以是非常自负的区别。单元测试找不到错误。他们只是断言代码按预期工作。当测试全部通过时，代码与这些期望保持一致，但是“错误”是一个并非预期的事件。然后更新测试以处理新的期望，并重复该循环。代码质量和可测试的代码不相关。我已经看到了足够多的编写了代码的单元测试知道这一点。你的代码质量得到了提高，因为你已经成为了一名更好的程序员，并且测试帮助:) – cgTag