Peter Tesler（前迪士尼軟件開發測試主管）最近發佈了Smashtest的第一個主要版本。Smashtest是描述和部署測試用例的一種新的領域專屬語言。Smashtest非常注重通過語言簡潔地表達開發人員執行的重複性測試任務來提高測試人員的工作效率。新語言帶有一個並行運行測試的測試運行器和一個REPL。
Smashtest的主要新特性包括允許測試人員以樹狀格式聲明性地描述他們的測試。Smashtest網站上給出了以下Smashtest腳本：
Open Chrome
Open Firefox
Open Safari
Navigate to 'site.com'
Click 'Sign In'
Type {username:} into 'username box'
{username} is 'joe'
{username} is 'bob'
{username} is 'mary'
Verify success
{username} is 'baduser'
Verify error
一次描述了3 (Chrome、Firefox和Safari瀏覽器)x(3 + 1) = 12個測試，在同一個描述中覆蓋了快樂路徑（joe、bob、mary）和錯誤路徑（baduser）：
因此，Smashtest是一種對空格敏感的語言，它使用空格將測試組織到樹中。要執行的測試是由樹的深度優先搜索推導出來的。Smashtest最好與能夠尊重現有空格的編輯器一起使用。該版本中提供了一個Atom編輯器的插件。
Smashtest語言包含一個模擬API，尤其是模擬時間和地理位置。網絡條件和節流也可以用這種語言來描述（只有Chrome瀏覽器纔可以使用這個功能）。該語言還包含一個API，用於查找頁面上的元素，並在其上執行斷言。
Smashtest命令行接口（CLI）包括用於持續集成/持續交付的工具和一個REPL（Read-Eval-Print Loop）解釋器。該CLI還可以使用自動生成的屏幕截圖創建報告：
關於Smashtest的價值定位，InfoQ採訪了Smashtest的創建者Peter Tesler。
InfoQ：是什麼驅使您編寫Smashtest？爲什麼要開發一種新的測試語言？
Peter Tesler：我們編寫、部署、更新和分解自動化測試的速度是最重要的。軟件變化很快，測試需要跟上。我想構建一種測試語言，使速度成爲優先考慮的因素。
我還希望它能反映出我們在測試時是如何思考的，即廣度優先。也就是說，當我在我的應用程序中處於一個特定的狀態時，我想到了接下來可能發生的所有排列。例如，如果我在一個登錄框中，我在腦海中列出所有我可以輸入的潛在用戶名。用戶首先考慮的是深度，或者是一系列的線性步驟。傳統的測試總是反映出後者，但是反映出前者（將測試作爲一個排列樹來編寫）使你可以更容易地按照你的想法編寫測試，查看你所涵蓋的內容，並快速地編寫（因爲要打印的內容要少得多）。
InfoQ：與基於Gherkin的解決方案相比，Smashtest是如何圍繞功能/場景（Feature/Scenario）和Given/When/Then三元組來組織的？
Tesler：Smashtest也處理 Gherkin。但傳統的BDD/TDD工具並不將測試存儲爲樹。
我們還把我們認爲不必要的東西作爲步驟本身之外的可選項，例如描述或命名測試。測試有一種與其他測試非常相似的趨勢，通常被命名爲“cart test 014”之類的無用名稱。必須想出名字只會減慢你的速度（儘管如此，如果你願意，你仍然可以添加名字和描述）。
InfoQ：您提到了測試速度的提高。Smashtest涉及測試過程的哪些部分？
Tesler：測試編寫和維護。現在編寫一個功能自動化測試所花費的時間非常長，尤其是當我們討論Selenium WebDriver測試時。開發新測試所需的時間越長，應用程序和/或需求更改的次數就越多，自動化帶來的好處就越小。以至於許多組織完全放棄自動化，而傾向於手工測試（在手工測試中，創建測試的成本很低）。
InfoQ：與手工測試或現有的測試解決方案相比，您是否有速度提升的經驗指標或硬指標？
Tesler：雖然我們還沒有具體的經驗度量，但是我花了一些時間，分別使用傳統的webdriverjs以及Smashtest編寫了一些測試場景，並看到了大約10倍的改進。在Smashtest中添加一行代碼非常容易，並且可以立即將覆蓋的排列加倍。
InfoQ：開發人員、測試人員和產品所有者採用Smashtest的三個理由？
Tesler：
1.編寫測試的速度。易於閱讀。
2.它本身可以做很多處理。UI和API測試、各種模擬，它甚至是一種描述頁面應該是什麼樣子的語言（所以你不需要20多個驗證步驟，一個接一個）。
3.實時報告。它們在測試運行時進行更新，將類似的故障組合成組（使調試更加容易），顯示所有的屏幕截圖/日誌，而且它們非常漂亮!
InfoQ：開發人員、測試人員和產品所有者不採用Smashtest的三個理由？
Tesler：
1.和任何語言一樣有學習曲線。
2.你必須打破傳統，以一種新的方式編寫測試。
3.現在，它內置了對Web UI（使用Selenium WebDriver）和HTTP API測試的支持。如果你想測試其他內容，就必須編寫一些自定義的js。不過，任何可以在nodejs中運行的東西都可以在Smashtest中運行。
InfoQ：Smashtest接下來會帶來什麼？
Tesler：現在我們專注於傳播信息和建立社區。我們可能會根據需要添加對更多編輯器和語言的支持。
原文鏈接：