我需要测试在每个步骤都有一些特定退出条件的多步骤（大约70-90步骤）过程。我对幸福路径（一切成功）进行了测试，并且希望将其用作对不太幸福路径建模的基础（即对于每个可能的退出条件，我需要一个测试用例，它是幸福路径的细微变化）。处理分支测试
我已经想过使用模板模式的变化（即模拟通用测试用例司机为模板，立足关每个单独测试），但是这很快变得相当笨拙。
由于这是一个纯粹基于事件系统（通信协议），我可以模拟测试的事件流，但是这并不能帮助我在组织特定测试用例通用序列的变换。
您提出的这个问题看起来很像数据驱动的测试策略的一个很好的候选人。 “xUnit Test Patterns: Refactoring Test Code”由杰拉德梅萨罗斯，定义了条件测试，以符合数据驱动测试策略如下（P 288）：
上 data-driven testing例如，我们可能需要运行基本上与 相同的测试稍有不同的系统输入并验证实际输出 相应地变化。这些测试中的每一个都包含完全相同的步骤 。
Wikipedia条目还指出：具有可能改变（也称为“变异”， 和包括诸如环境，结束点，测试数据， 位置
什么，等等）从测试逻辑（脚本）中分离出来并且移入“外部资产”。这可以是一个配置或测试 数据集。脚本中执行的逻辑取决于数据值 。
用于数据驱动测试建议的实现策略是用于数据从测试逻辑分离。每个测试的输入和期望输出数据一起存储在文件或数据库中并键入测试。测试逻辑以模块化方式组织，以提高重用性。使用适当的实现语言/工具，测试逻辑可以发展成DSL（特定于域的语言）或者甚至是一个完整的解释器（在xUnit Test Patterns p288中推荐）。这样做的结果是：您的测试的制定将基本上是声明性的，并且对意图和正在执行的功能是明确的，这也会将您的测试转换为您的系统的另一个有意义的文档源。
延伸阅读：
@RunWith(Nested.class)
public class NestedJunitTest {
@Test public void testWithoutLogin() { // expect 401
public class LoggedInTests {
Session session;
@Before public void login() { session = new Session(..)
@Test public void testLoggedIn() { ...
类似：
用于测试类的来的一系列事件的变化响应，我已经使用junit-nested，这让你窝setup()和teardown()方法与嵌套静态内部类有很好的效果到Jasmine's nested describe blocks。
我认为作文在这里可能更有用：将通用测试代码基础结构分解为一致分组函数，并在重用相同测试基础结构的同时用输入数据驱动测试用例。但是除非您在不考虑通用性或重用性的情况下运行几个案例，然后再仔细观察并找出，那么在整个测试用例中分解和重用意味着什么是有意义的。 – ylabidi