測試 - 術語

Question

類通常使用以下語法編寫的測試進行測試，這些測試由大量測試框架（例如Ruby的Unit :: Test;或者如本示例中的MiniTest）提供：

class TestLolcat < MiniTest::Unit::TestCase 
    def setup 
    @lolcat = Lolcat.new 
    end 
    def test_that_lolcat_can_have_cheezburger 
    assert_equal true, @lolcat.i_can_has_cheezburger? 
    end 
end 

或者代替通過使用寫入第二排序語法的，它是由一組重疊的測試框架的提供測試（例如RSpec的;或如在此實例中，MINITEST再次）：

describe Lolcat do 
    before do 
    @lolcat = Lolcat.new 
    end 
    it "must be able to have cheezburger" do 
    @lolcat.i_can_has_cheezburger?.must_equal true 
    end 
end 

（也許還有其他語法系列，它們也適用於測試類的方法和屬性，但這些是我感興趣的兩個。）

我想知道的是：什麼是每個這兩個語法族？

如果你想知道更多關於爲什麼我在問，看到下面的行。

---

的原因，我問這個問題是在網上搜索還沒有產生明顯的共識。例如，MiniTest documentation是指如上文所「單元測試」語法和秒如「規格」語法第一語法。相比之下，邁克爾哈特爾describes class method and attribute tests written in the second sort of syntax as "unit tests"。在用這種語法編寫的測試測試多個類的交互所產生的更高級別的功能時，他稱它們爲「集成測試」。

我還看到有人形容第一和第二各種各樣的語法爲"Test::Unit style" and "RSPec-esque", respectively，或「TDD」語法和「BDD」語法。對於秒那種語法的其他名稱包括：「'should'-like syntax」和「it syntax」。

我的理解（這隱約表明哈特爾是正確的）如下：

• TDD是實踐，而不是測試語法。具體而言，通常是編寫一個失敗的測試（例如單元測試或集成測試），然後編寫代碼以使測試通過，然後重新合適，然後重新開始循環。
• BDD也是練習，但它確實對測試語法做了一些有限的處方。具體而言，遵循TDD的做法是使用「should」作爲測試名稱中的第一個單詞，並嵌套測試代碼以在適當的情況下提供上下文。
• 單元測試是練習，而不是測試語法。特別是測試單個代碼單元（例如，類方法或屬性）
• 單元測試是測試在單元測試過程中編寫，無論採用何種語法。
• 集成測試是練習，而不是測試語法。特別是測試由多個類的交互產生的更高級功能的做法。

然而，這還不完全清楚的事情了。很明顯，我不是測試實踐，測試類型或測試語法術語的專家。我已經能夠拿出最好的名字了兩種語法我已經給出了上面的例子分別是「‘斷言’語法」和「‘這......做’語法」， 。除非這些名字被廣泛使用，否則我需要你的建議，StackOverflow用戶！

Answer 1

我不確定每個人都有可接受的定義。

我喜歡用這些方式來思考它們。

迷你測試版更多的是一個assertation

RSpec的版本更是一個規範

後者炮製引導你遠離強調「測試」和的更多地從利益相關者的角度推出要求。

Answer 2

測試方法沒有全局接受的語法名稱。大多數單元測試工具都鼓勵某種約定，比如JUnit鼓勵用「測試」來啓動所有的測試方法名，現在通過@Test註釋已經不必要了。

大多數的單元測試工具提出了一定公約哪個開發商同意。測試方法名稱沒有語法，因爲目標受衆是應該輕鬆掌握測試方法的開發人員。

如果您正在尋找在測試情境定義看看這本書「的xUnit測試模式」傑拉德梅薩羅斯。作者根據不同的條款提供了一些說明。他對「測試雙打」的定義多次被引用。

Answer 3

在與軟件打交道，一個需要「什麼」和區分「如何」：應該怎樣程序做的，它是如何工作的。

恕我直言，這要牢記這兩者之間的區別在開發的各個階段是非常重要的。這種區分支持幾個原則，例如coding against interface,responsability-driven design,design by contract and assertions和單元測試。

唉，它並不總是那麼容易分離這兩個概念。經典的例子比如排序很容易處理：存在幾種算法來排序（如何），這些算法都會產生一組有序的元素（what），這些元素可以很容易地表達爲一個斷言，契約，不變量。對於商業代碼，情況可能變得不那麼清晰。

我相信這兩種語法實現了大致相同的事情，但第二種方法便於思考「什麼」而不是「如何」。讓我們考慮兩種說法：

斷言值％2 = 0

應爲偶數

他們執行相同不變，但第二人把更多的empahsis在「做什麼」 ，並且更具人類可讀性。

Smalltalk使用例如should的措辭，但測試是像Ruby中的命令式代碼。

SetTestCase>>testAdd 
    empty add: 5. 
    self should: [empty includes: 5] 

不幸的是，我的離題仍然不能回答你的問題，太長的評論。

Answer 4

如果我們分享一點關於BDD和TDD的歷史，可能會澄清一些事情。

早在2003年，TDD的首選單元測試框架就是JUnit。丹北開始writing JBehave as a replacement for JUnit，使用"should" instead of "test" - 所以，BDD語法。現在，在Ruby中看起來與你正在做的事情（以及RS​​pec的做法）沒有太大的相似之處，但是，RSpec被創建爲Ruby版本的同一事物。 JBehave從不嵌套測試代碼;它對於單元級別的例子以及其他一些用於運行全系統場景的gubbins只有「應該」。 Dan將情景分析人員遷移到了Ruby，在那裏它成爲了RSpec的故事跑者，然後是Cucumber。

因此，「它......應該」語法絕對是單元級別的BDD。大多數人都熟悉BDD是全系統場景，但它不是BDD開始的地方。現在BDD並不是真正的一種做法，這是一個mini-methodology that goes right up to project visioning - 以防萬一你遇到任何令人困惑的事情。 JBehave 2.0被重寫爲與場景和步驟一起工作，並且隨着嘲笑框架丟失了單元級測試，因爲JUnit和Mockito當時運行良好。但是，這是「應該」開始的地方。

現在......只要您使用「必須」而不是「應該」，就會丟失「應該」提供的sense of uncertainty。使用「should」可以讓你提出很多問題，其中最重要的是「應該嗎？」所以，任何使用「must」而不是「should」的東西都不再是真正的BDD語法;這是一個混合動力車。順便說一下，當我們談論BDD時，我們試圖避免使用「test」這個詞，所以它們不是在測試過程中編寫的單元測試;他們是一個例子，說明了一個類在代碼設計過程中會如何表現。