我继承了一个中等大小的 Angular 应用程序。它看起来组织得很好，写得很好，但没有实现文档或单元测试。
我将努力在死后编写单元测试，并最终通过 ngdoc 从事 e2e 测试和文档工作。
我想知道事后编写单元测试的最佳方法是什么。你会从服务和工厂开始，然后是指令等或其他策略吗？我计划使用 Jasmine 作为我的测试框架。
我还应该提到，我只使用代码几天，所以我还不能 100% 确定一切是如何联系在一起的。
【问题讨论】：
标签： angularjs unit-testing jasmine protractor
归根结底，您需要知道的是，您的软件工作正常、始终如一，并且在业务限制范围内。这才是最重要的，TDD 只是帮助您实现目标的工具。所以，这就是我接近这个答案的心态。
如果有任何已知的错误，我会从那里开始。通过测试覆盖当前或预期的功能，并在进行中修复错误。
在那之后，或者如果没有任何当前已知的错误，那么当您开始维护代码并进行更改时，我会担心添加测试。添加测试以涵盖当前正确的功能，以确保您不会以意想不到的方式破坏它。
一般来说，编写测试来覆盖看似有效的东西，只是为了获得测试覆盖率，不会很好地利用时间。虽然感觉可能很好，但测试的目的是在出现问题时告诉您。所以，如果你已经有了工作代码并且你从不改变它，那么编写测试来覆盖它不会减少代码的错误。手动检查代码可能会发现尚未发现的错误，但这与 TDD 无关。
这并不意味着永远不要在事后编写测试，但事后进行详尽的测试似乎有点矫枉过正。
如果这些建议都不适用于您的特定情况，但您仍想添加测试，那么请从代码中最关键/最危险的部分开始——如果出现问题，您将成为特别是拧紧，并确保这些部分坚如磐石。
【讨论】：
我最近在使用 AngularJS 应用时遇到了类似的情况。显然，AngularJS 开发的主要规则之一是TDD Always。不过，我们直到后来才知道这一点，因为开发已经进行了六个多月。
我后来确实尝试添加一些测试，但很困难。最困难的方面是您的代码不太可能以易于测试的方式编写。这意味着大量的重构（或重写）是有序的。
显然，您不会有太多时间花逆向工程来添加测试，因此我建议您遵循以下准则：
确定应用程序中最有问题的区域。每当有人进行更改时，这似乎总是会破坏。
按重要性排序此列表，以便最重要的组件位于列表顶部，次要项目位于底部。
接下来，按不太复杂的项目排序。
从列表顶部开始慢慢添加测试。
您想从最重要但最不复杂的事情开始，这样您就可以轻松取胜。依赖很多的东西在这个过程中也可能需要重构，所以已经依赖less的东西应该更容易重构和测试。
最后，似乎最好从一开始就进行单元测试，但是当这不可能时，我发现这种方法很有帮助。
【讨论】：