很快我们将开始一个新项目。它将是基于 Spring MVC 的 Web 应用程序。我们第一次决定开始在应用程序中编写测试。
我们将使用 Junit、Mockito 和 Hamcrest 来编写测试。
由于这将是我们第一次编写测试，而且我们团队中也没有任何人具有编写测试的经验，因此我们正在寻找一些可以用作参考的示例应用程序。
我们已经浏览了几篇关于如何使用 junit 等编写测试的网络和红色文章。编写测试等时的最佳实践是什么，但到目前为止还没有看到任何现实世界的应用程序。
我们不想开始编写糟糕的测试。
请帮忙。
到目前为止，这不是最终列表，而是我的经验中的一些建议
真正尝试测试单元，特别是因为您使用的是 JUnit（例如，与 testNG 相反）。这意味着如果您在测试中发现需要一些运行顺序，那么您不是在测试单元，而是在测试集成或功能
与#1 相关，我强烈建议您使用模拟库，您似乎也这样做了。我，我使用Mockito，它使用起来非常简单，并且测试结果非常易读。你需要这个的原因是任何合理的类都依赖于其他类（如果不是顺便说一句，你的类可能不是很有凝聚力）或外部资源（数据库等），因为在单元测试中你应该只测试一个类一次，您需要模拟其他未测试的类。
可测试性设计。这很棘手，因为我认为您不应该仅仅为了测试而公开（即公开）方法，但有时您可能需要使一些私有方法受包保护，以便单元测试可以直接调用它们。当您的方法执行您不想在测试环境中执行的事情（例如创建文件）时，这非常有用，因此您可以将这些特定部分分成单独的方法，然后您可以在测试中避免使用这些方法。当不应该在单元测试之外使用方法时，请确保在 javadoc 中进行注释
尽量避免在您的工作方法中创建/打开资源。例如，不要使用随后在方法中打开并创建 InputStream的File参数，而是直接传递 InputStream。这样，当您测试时，您可以传递一个内存流。或者以更一般的方式，依赖注入非常适合单元测试。每次你调用new你的方法时，它可能会让你的单元测试更难运行和/或断言
如果您注意到要为某个方法运行测试，您需要首先调用许多外部方法来配置被测单元的状态，那么您最好进行一些重构。这很好地表明了高耦合。这是我最喜欢的单元测试之一，你为你的类创建第二个用户有助于你仔细检查你的设计。
当然，很多人不会同意其中的部分或全部，对那些人来说，不要对自己保密，对这个答案发表评论，以便附近有另一个 POV。它也会帮助我
我也推荐这本书，它有很多好的实践和味道，可以帮助你在单元测试中找到不好的实践。