我需要測試在每個步驟都有一些特定退出條件的多步驟（大約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