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