程序演示TDD +嘲諷

我必須編寫一個程序，該程序需要一個整數並將其轉換爲其英文單詞版本。程序演示TDD +嘲諷

例如：

Input: 21 
Output: twenty one 
Input: 110 
Output: one hundred and ten

我需要的程序來演示TDD，所以我想用嘲諷。

我寫了一個具有轉換功能的類（基於2個英文單詞數組）。現在我需要用我可以用Easymock演示的方式來設計程序。

因此，我需要創建一個接口作爲我的模擬主題。任何人都可以給我任何指導我如何設計我的程序？

這會適合嗎？

編寫一個Converter類，該類引用了名爲ConverterInterface的接口。然後，我可以模擬界面並將其設置爲我的Converter類。

任何幫助，歡迎。

來源

2012-03-11 TheCoder

嘲笑通常用於模擬別的東西。你想要模擬什麼？輸出機制？ – 2012-03-11 17:34:14

如果你想演示TDD，你應該丟掉你的代碼並開始編寫測試。 – 2012-03-11 17:45:58

@vaughan：這是我的問題。我的程序可以很容易地編寫而不用嘲笑，但是我需要用一種方式來寫作，以演示嘲笑。因此，我需要這樣設計它。設計顯然會令人費解，但這個練習是爲了展示嘲笑。 – TheCoder 2012-03-11 17:57:52

您可以在不嘲笑的情況下演示TDD。事實上，嘲弄可能會混淆TDD新手。我會簡單地從測試中開始，嘗試開發您正在嘗試開發的功能，然後再擔心嘲笑。讓我們假設你已經測試驅動的數字爲英語轉換器（它不會出現你這樣做又根據您的描述），你有一個類，看起來是這樣的：

public class NumberConverterTest { ... } 

public class NumberConverter { 
    public String toEnglish(int number) { ... } 
}

你很可能也有一些主類：

public class NumberConverterMain { 
    public void main(String[] args) { 
    NumberConverter converter = new NumberConverter(); 
    System.out.println(converter.toEnglish(args[0]); 
    } 
}

你現在已經演示了TDD沒有嘲笑。在嘗試TDD時，嘲諷問題總會出現。爲了演示模擬，您可以在toEnglish方法中添加一些任意的業務規則，例如「所有大於1000的數字請求都必須記錄到大數部門」。知道大量部門託管在另一臺我們不想依賴的服務器上，我們可以測試驅動界面並將其模擬出來。

public class NumberConverterTest { 
    // .. 
    @Test public void theLargeNumberDepartmentIsNotifiedForLargeNumbers() { 
    LargeNumberDepartment department = new MockLargeNumberDepartment(1000); 
    NumberConverter converter = new NumberConverter(department); 
    converter.toEnglish(1000); 
    assertTrue(department.wasNotifiedWith(1000)); 
    } 

    public static MockLargeNumberDepartment implements LargeNumberDepartment { 

    private int valueRequested; 

    public void MockLargeNumberDepartment(int threshhold) { 
     this.threshold = threshold; 
    } 

    public int notificationThreshold() { 
     return this.threshold; 
    } 

    public void largeNumberReceived(int value) { 
     valueRequested = value; 
    } 

    public boolean wasNotifiedWith(int value) { 
     assertEquals(value, valueRequested); 
     return true; 
    } 
    } 
} 

// In NumberConverter.java 
public class NumberConverter { 
    public NumberConverter(LargeNumberDepartment department) { 
    this.department = department; 
    } 

    public String toEnglish(int value) { 
    if(value > department.notificationThreshold()) 
     department.largeNumberReceived(value); 
    return convertIt(value); 
    } 
}

來源

2012-03-12 15:07:37 bcarlso

謝謝所有回答。我現在已經在你的幫助下編寫了這個程序。 – TheCoder 2012-03-12 21:36:42

首先，我同意@Don Roby所說的最好的做法是首先實際編寫測試，然後看看哪些東西會成爲模擬某些東西的機會。

我看到這個程序的不同元素。

的「主」可執行部分
用於處理所述命令行參數
該算法對於數字轉換爲字
用於顯示輸出

第一機制中的邏輯兩個可能非常簡單。第三個可能足夠複雜以擁有自己的班級。第四種方法對於打印到控制檯可能非常簡單，但如果這是某種真正的程序，那麼在抽象它發送答案的位置時可能會有一些價值，因此您可以插入其他方法，如寫入文件或數據庫或其他任何東西，所以它不是完全有人設計一個具有獨立運行的具體實現的接口。

來源

2012-03-11 18:35:49 jhericks

所以你說我應該寫一個名爲'Converter'的接口，它有一個名爲'display'的抽象方法。然後模擬這個接口，並在單元測試中傳遞System.out？那麼在真正的程序中，顯示器可以顯示在網頁上？ – TheCoder 2012-03-11 20:19:46

我已經將我的程序分成如下：轉換器類與主要方法。 UserInput類+接口以從用戶獲得輸入。算法類+接口做轉換。仍然沒有找到一個理由來嘲笑一些東西... – TheCoder 2012-03-11 23:47:43

好吧，如果你正在測試你的主要方法，你不測試你的算法類和你的UserInput類，你只要確保它們被調用，如你所期望的與模擬），然後爲算法編寫單獨的單元測試，併爲UserInput分別進行單元測試。這樣，如果你有很多可能與UserInput出錯的地方（不好的格式，壞的管道，不管），你可以單獨測試所有那些路徑，而不是算法邏輯，它有一組完全不同的東西，可能會出錯。 – jhericks 2012-03-12 05:27:46

只有當組件之間有責任分離時，通過接口「關注」分離才能實現模擬。你所說的問題似乎太窄而無法說明這一點。一個可行的想法是擴展你的問題，並設計一個號碼翻譯到多種語言。在這種情況下，我期望一個策略模式出現，一個INumberTranslator接口暴露一個字符串Translate（int number）方法。

通過首先爲「translate to English」需求編寫測試，然後將需求更改爲「我們需要用西班牙語支持這個」，您可以從TDD非常順利地從移動到TDD的移動。

來源

2012-03-12 23:05:06 Mathias

程序演示TDD +嘲諷

回答

相關問題