2014 年从 Maven Central 下载了 4300 万次，JUnit 仍然是 Java 的默认测试库。数百万个项目依赖于它的稳定性和允许测试最新 JDK 的最新功能。此外，许多其他测试库都与 JUnit 挂钩，作为启用 IDE 和构建工具集成的一种方式。保持 JUnit 的良好状态对于那些维护和发展该库的人来说是一项主要任务。
截至今天，没有一位活跃的 JUnit 维护者因这项工作而获得雇主的报酬。毫不奇怪，许多未解决的问题堆积如山，更糟糕的是，在不久的将来，JUnit 都没有希望支持和利用 Java 8 中的所有功能。由于Lambda 是这些功能中最突出的，我们借用了它们的名字来命名这次活动。
这次活动将使一个由长期 JUnit 提交者组成的团队，在一些经验丰富的 Java 开发人员的支持下，专注于使 JUnit 为未来几年——以及 JDK——做好准备。
JUnit 的一个主要设计目标一直是简洁性。JUnit 4 于 10 年前发布，并且很好地实现了它的目的。从那时起，许多事情发生了变化：Java 获得了几个新版本，并且涌现了许多新的测试框架和关于测试的想法。
然而，JUnit 的基本设计自 2005 年以来一直保持不变。添加了一些像 Rules 这样的结构，但同时，向后兼容性一直是并将继续是 JUnit 发展的主要目标。许多问题日益减缓了它的发展
Runners 已被广泛使用，并成为扩展 JUnit 的关键概念。编写自定义 runner 是一种非常强大的方式，可以自定义测试类的实例化方式、其子项的收集方式、它们的运行方式、报告方式等等。但是，每个测试类只能有一个 runner。例如，目前不可能将 SpringJUnit4ClassRunner 和 Parameterized 组合在一起。我们希望将 runner 当前负责的不同关注点分离到单独的接口中。
当前的执行模型要求所有测试用例都是先验已知的。这阻止了响应测试执行期间观察到的行为而动态创建测试用例。这也意味着您不能使用 Streams (Java 8)，例如与 @Parameters 结合使用，来创建您的测试数据。
所有 IDE 和构建工具都包含对 JUnit 的支持。虽然这使得执行 JUnit 测试非常容易，但另一方面，IDE 和构建工具与 JUnit 内部结构紧密耦合。一些 IDE 和构建工具使用内部 JUnit 类甚至反射来规避 JUnit API 的缺失，以实现他们想要的功能。例如，如果没有 JUnit API，就无法以可扩展的方式链接到测试位置（如果它不是 Java 方法）。这些“技巧”极大地复杂化了 JUnit 的发展，甚至使某些更改几乎不可能实现。因此，我们希望与 IDE 和构建工具开发人员密切合作，以可扩展的方式添加用户需要的功能。
我们已经确定了在即将到来的 JUnit 改进中需要关注的两个主要领域
将测试执行和报告与测试定义和配置分离：这将大大简化 JUnit 的进一步发展，并允许用户更轻松地混合来自不同测试库（如 JUnit、Spock、ScalaTest 等）的测试规范。其他测试库应该只依赖 JUnit 的测试执行/报告 API，而不是测试定义 API（例如 Runner）。
重新思考 JUnit 的可扩展性方案：Runners、Rules、子类化和其他技术将被改造为一组有凝聚力的结构，以增强 JUnit，并允许（如果可能）无缝组合各个扩展。
利用 Java 8 功能（Lambdas、Streams、接口默认方法）来实现更好的断言、生成测试用例、制定测试层次结构、测试异步代码和其他功能：我们将在额外的库中提供这些扩展，以保持 JUnit 核心与旧 JDK 的兼容性。
所有开发都将在 GitHub 上公开进行，以便促进早期反馈并尽快发现问题。
