Ruby/Rails測試實踐

Question

雖然我仍然認爲自己在ruby/rails空間中有些不自然，但我有興趣就如何測試rails應用程序形成意見 - 哪些技術和覆蓋級別使用和何時。我現在的政策是隨着我所處的任何項目的流動，但是這在技術和覆蓋水平上都產生了不一致的結果。唯一的一致性在於測試的第一種開發風格。

Rspec的對控制器，模型和助手，爲黃瓜函（以緩解測試第一的發展），並與測試::單位回填的代碼棘手位？所有黃瓜功能？放棄測試::單位？測試::模型和助手的單位，黃瓜的一切？

請分享您的觀點。

Answer 1

當涉及到測試應用程序時，比您的測試框架或方法更重要的一件最重要的事情是編寫可測試的代碼。

如果您使用的是測試驅動的方法來開發，你會自然地傾向於寫測試代碼，但你仍然需要把重點放在給自己適當的設施。目標是要有一個透明的應用程序。

一些事情要專注於有：

• 保持你的方法集中在一個特定的功能，並提供一個方法和彼此之間清晰的手客點。
• 爲單元級對象的內部提供足夠的反省，而不必不必要地暴露過多的信息。
• 通過應用一致的術語和命名約定，創建以更貼近控制器和模型空間的方式構建的HTML文檔。

我一直認爲測試是類似於一個魔術師一樣。魔術師明確表示他們在做什麼，結果如何，但這個過程本身並不一定要解釋。這就像你想知道結果的軟件，但不應該關注實現細節。

一個典型的魔法常規會告訴你所有的相關細節，比如表演者戴着帽子，帽子是空的，袖子上沒有東西，帽子很結實，重量很小，然後他們會不知何故地將兔子從帽子裏拿出來。我個人傾向於更傾向於編寫固體單元測試，並且保持控制器很薄，不太重視功能測試。功能測試可能非常棘手，因爲渲染頁面時系統可能處於不可能的大量狀態。由於您只能測試其中的一小部分，因此您需要優先考慮您的驗證。

集成測試工作以及成熟的應用是很好的定義，其中一個缺陷的成本是非常高的，但是，否則他們可能會採取顯著更多的時間來創造出比質量控制的紀律，嚴格的申請。不好的集成測試可能會給你一種錯誤的安全感，並可能實際上降低應用程序質量。

如果你有一個專門的QA部門可以專注於建立和維護一套完整的迴歸測試，然後集成測試是有一個偉大的事情。但對於普通開發人員來說，最終會造成巨大的工作重複，並可能嚴重阻礙工作效率。像許多事情一樣，它是關於權衡的。