我開發了一種gem，它封裝了一個控制遠程燈開關和調光器的C api。當我開發這個gem來做測試時，我在編譯時用一些鏈接魔法嘲笑了底層C api，並且在我沒有正確硬件的情況下我可以在我的桌面上開發很好的工作，等等。控制硬件的TDD web api
現在我想在另一個項目中使用這個gem來包裝更高級別的REST API，但我正在努力測試。
我應該如何在不需要硬件的情況下測試我的REST API。我是否應該在項目中將我的低級別api作爲git子模塊並加載負載路徑，以便我可以重新使用低級別模擬？
或者我應該再次嘲笑新項目的整個API？我在這裏完全失敗。
對此有何建議或討論，歡迎
如果我理解正確的話，你想換行與公開的REST API又一層包裝了C API相同的「寶石」。我對嗎？ 如果是這樣，您應該嘲笑寶石或C API，就像您對寶石所做的一樣。
「純粹」TDD從業者通常建議隔離最小的碎片（即模擬寶石）以便驅動SRP（單一責任原則）。另一方面，當我添加的層（在這種情況下是REST API）主要是一個包裝器，並且沒有很多自己的「業務邏輯」，那麼我個人更喜歡把我的測試寫得更像集成測試而不是單純的單元測試，這樣我才能在正確的上下文中測試新的層。 （即測試Rest API + gem在一起，並模擬唯一的C API）
如果這個REST API純粹是一個包裝，那麼你可以重新使用你的測試，把它們推到一個基類並派生2兒童：一個用來測試寶石本身，一個用來測試它通過REST API。 我的任何情況下，我總是重構我的測試和我的代碼，以消除重複。有時候，這導致我改變了我的模擬和我不想做的，並改進了CUT和測試本身的總體設計。
HTH ...