我的junit测试看起来像一个长故事：
优点： 这些测试非常有效（非常擅长检测错误），并且非常稳定，因为它们仅使用API。如果我重构代码，则测试也会进行重构。由于我不使用“卑鄙的伎俩”，例如在给定状态下保存和重新加载数据库，因此我的测试对架构更改和实施更改视而不见。
缺点： 维护测试变得越来越困难，对任何测试的更改都会影响其他测试。测试用例运行8-9分钟，这对于持续集成非常好，但对开发人员来说有点沮丧。无法隔离地运行测试，最好的方法是在运行您感兴趣的测试后停止，但是必须绝对运行先前所有的测试。
您如何改进我的测试？
更新2：根据其他答案，我想澄清一些关于进行TDD的事情。假设您必须检查某些给定逻辑是否发送电子邮件、记录信息到文件、保存数据到数据库并调用Web服务（我知道不是同时进行，但您开始为每个添加测试）。在每个测试中，您不希望命中外部系统，您真正想要测试的是逻辑是否会调用您期望它执行的这些系统。因此，当您编写一个检查创建用户时是否发送电子邮件的测试时，您测试的是逻辑是否调用执行此操作的依赖项。请注意，您可以编写这些测试和相关逻辑，而无需实际实现发送电子邮件的代码（然后访问外部系统以了解发送了什么...）。这将帮助您专注于手头的任务，并帮助您获得解耦合的系统。它还将使测试发送到这些系统的内容变得简单。
单元测试应该是独立的，并且能够以任何顺序运行。因此，我建议您：
如果创建几个用户并发送几条消息需要8分钟，那么性能问题可能不在测试中，而是系统本身存在性能问题的症状 - 只有您的分析工具才知道！
[注意：我不认为这些测试是“集成测试”，尽管我可能是少数派；我认为这些测试是功能的单元测试，类似TDD]
创建用户账户
登录
发送消息
@RunWith(JExample.class)
public class MyTest {
@Test
public Object a() {
return new Object();
}
@Test
@Given("#a")
public Object b(Object object) {
// do something with object
return object;
}
@Test
@Given("#b")
public void c(Object object) {
// do some more things with object
}
}
免责声明，我是JExample开发人员之一。
选择另一个更好支持“讲故事”式测试的测试框架，就像其他用户已经建议的那样。您需要评估并找到一个合适的测试框架。
使您的测试更像“单元测试”。因此，您需要拆分测试，并可能更改当前的生产代码。为什么？因为单元测试旨在测试小的代码单元（单元测试纯粹主张一次只测试一个类）。通过这样做，您的单元测试变得更加独立。如果您更改了一个类的行为，您只需要更改相对较少的单元测试代码。这使得您的单元测试更加健壮。在此过程中，您可能会发现您当前的代码不太支持单元测试--主要是由于类之间的依赖关系。这就是您还需要修改生产代码的原因。
如果您正在进行项目并且时间不足，这两个选项可能无法帮助您进一步。然后，您将不得不接受这些测试，但您可以尝试减轻痛苦：
消除测试中的代码重复：就像在生产代码中一样，消除代码重复，并将代码放入辅助方法或辅助类中。如果有什么变化，您可能只需要更改辅助方法或类。这样，您将收敛到下一个建议。
为您的测试添加另一层间接性：生成操作于更高抽象级别的辅助方法和辅助类。它们应该作为您测试的API。这些辅助程序正在调用您的生产代码。您的故事测试应该只调用这些辅助程序。如果有什么变化，您只需要更改API中的一个地方，而不需要触及所有测试。
您的API示例签名：
createUserAndDelete(string[] usersForCreation, string[] userForDeletion);
logonWithUser(string user);
sendAndCheckMessageBoxes(string fromUser, string toUser);
对于一般的单元测试，我建议参考Gerard Meszaros的XUnit测试模式。
如果想要在生产测试中打破依赖关系，请参考Michael Feathers的《高效处理遗留代码》。