Robotframework的Best Practice/Do與Don't

Introduction

幾年前剛開始用Robotframework時，並沒有明確的規範大家的coding style；但隨著開發人員的增加，不管是測試的分類、測試涵蓋規範、測試或關鍵字的命名，都隨著時間慢慢歪掉。為了:

測試利於維護；

測試容易閱讀；

容易建立user story與測試的連結。

以上原因，必須建立一些共識。而我認為面對到以下問題:

TestSuite、TestCase、變數、Keyword等命名準則。

如何決定一個TestSuite與其內的TestCases?

命名以外的Coding Style。

Naming

節錄自官方參考文件Robot Best Practice:

• Suite Name: lower_case_with_underscores。
• Keyword Name: Cap Words style。
• Global Variable: ${CapWord}。
• Page Element Variable: ${CapWord Locator}，包含xpath、id、name、text、css class等。
• Test Steps: 使用Given/When/Then。

這是Robot建議的方式，假如有自己的規範也不一定要使用他們建議的。

Structure

Suite Structure

節錄自官方參考文件:

• 要避免Testcase相依性，減少另一測試導致的錯誤；如果建立測試資料成本較大，可將共用行為放到Testsuite中。
• 如果無法避免相依，相依chain別超過4-5個。後面的測試可以透過${PREV TEST STATUS}變數去確認前一個測試結果，以略過接下來的測試。

我認為其它可實踐的:

• 在SuiteTeardown中，可放入抓取log或截圖動作。依照過往經驗，有時在SuiteSetup建置資料或最後TestTeardown都有可能發生錯誤；此時的抓取動作會有幫助的。

Test Structure

節錄自官方參考文件:

• 嘗試使用Gherkin Style去描述測試: Given/When/Then。
• Testcase第一層以Keyword組合而成，不牽扯底層實作。
• 透過Test Template形式，去避免重複的workflow。
• 每個Testcae都應該要伴隨著驗證行為，且要避免Testcase驗證其不相關的行為。
• 在使用Template情況下，透過setup或teardown可減少重複動作執行。
• 善用Teardown去還原測試環境，以避免影響到下一個測試。
• 避免testcase level的變數賦予。

個人看法:

• 使用Gherkin Style後，應能達到 1. 行為抽象化避免牽扯底層實作，只需寫必要表達的部分；2. 必會伴隨驗證行為； 3. 增加可讀性；Gherkin Style寫法本身就已經避免掉某些don't。
• 當Test第一層Keyword夠淺顯易懂後，Test本身應不需特別寫文件的。
• 在寫測試時，常會把相關的assertion放在同一個testcase中，這會因前面的錯而無法得知後面的是否正確。Data-Driven的方式也許可以解決這問題，但在keyword的設計上，就要仔細思考了；另外個方法就是一個測試驗證一個主要目標，但Testsuite的粒度就很重要了，否則會讓測試數量變得非常龐大。
• Gherkin Style的作法會產生大量的新keyword，Robotframework本身提供兩個方法可減少此問題(reference):
• Ignoring Given/When/Then/And/But prefixes: 舉例來說，keyword名稱假設為User login，你可以寫成Given User Login，也可以寫成When User Login。
• Embedding data to keywords: 舉例來說，通常都是以參數型式寫成Click Element | ${link}，現在也可以寫成Click ${link}。這讓你keyword更像是一個句子。

練習

[TestSuite]
user_management.txt
[TestCase]
Add a user 
     Given User login
     When Interact with add user command
     Then You see the new user
Add an invalid user
     Given User login
     When Interact with add user command 
     And Input an invalid Name
     Then You see a feedback show the name is invalid

Thinking..

1. 共用的行為該如何放置到Setup或Teardown中? 參考此篇
2. data-driven方式該如何撰寫? 參考此篇

data-driven可搭配tempalte寫成以下形式:

*** Test Case ***
WebLinks are clickable
     [Template]     WebLink is clickable
     ## link name ##     ## expect content ##
     Home                 home content
     About                about content               
     EMail                email@hotmail.com
     
*** Keyword ***     
WebLink is clickable
     [Arguments]     ${link}     ${expect_content}
     Given I login the system
     When I click ${link}
     Then I can see ${expect_content}

命名以外的Coding Style

• 如果會被重複使用的數值，可以透過變數減少Hardcode。
• 避免透過複雜的邏輯去產生測試資料。
• 將複雜的邏輯放到test libraries中。
• 使用polling的方式去等待事件；避免使用sleep方式去等待事件。

Reference

與Coding Style相關的文章

• Do ant Don't
• 中文介紹
• How to write good testcaes?
• smelly-cucumbers 這篇探討如何寫好Gherkin Style，我認為是keyword精細度的問題吧!

Gherkin Style基本知識

• BDD
• Gherkin language
• GivenWhenThen
• data-driven testing using cucumber