差異處
這裏顯示兩個版本的差異處。
rf:rf:best_practice [2016/12/05 23:31] tony |
rf:rf:best_practice [2023/06/25 09:48] |
||
---|---|---|---|
行 1: | 行 1: | ||
- | {{tag>RobotFramework}} | ||
- | ====== Robotframework的Best Practice/Do與Don't ====== | ||
- | ===== Introduction ===== | ||
- | 幾年前剛開始用Robotframework時,並沒有明確的規範大家的coding style;但隨著開發人員的增加,不管是測試的分類、測試涵蓋規範、測試或關鍵字的命名,都隨著時間慢慢歪掉。為了: | ||
- | - 測試利於維護; | ||
- | - 測試容易閱讀; | ||
- | - 容易建立user story與測試的連結。 | ||
- | 以上原因,必須建立一些共識。而我認為面對到以下問題: | ||
- | * TestSuite、TestCase、變數、Keyword等命名準則。 | ||
- | * 如何決定一個TestSuite與其內的TestCases? | ||
- | * 命名以外的Coding Style。 | ||
- | ===== Naming ===== | ||
- | 節錄自官方參考文件[[https://github.com/idumpling/robotx/blob/master/docs/ROBOT_BEST_PRACTICE.md|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本身應不需特別寫文件的。 | ||
- | === 練習 === | ||
- | <code> | ||
- | [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 | ||
- | </code> | ||
- | Thinking..\\ | ||
- | - 共用的行為該如何放置到Setup或Teardown中? [[http://morelia.readthedocs.io/en/latest/gherkin.html|參考此篇]] | ||
- | - data-driven方式該如何撰寫? [[https://blog.codecentric.de/en/2009/11/givenwhenthen-and-example-tables-using-the-robot-framework/|參考此篇]] | ||
- | 這兩個問題等到有足夠經驗後,再來分享。 | ||
- | ===== 命名以外的Coding Style ===== | ||
- | * 如果會被重複使用的數值,可以透過變數減少Hardcode。 | ||
- | * 避免透過複雜的邏輯去產生測試資料。 | ||
- | * 將複雜的邏輯放到test libraries中。 | ||
- | * 使用polling的方式去等待事件;避免使用sleep方式去等待事件。 | ||
- | ===== Reference ===== | ||
- | ==== 與Coding Style相關的文章 ==== | ||
- | * [[http://www.slideshare.net/pekkaklarck/robot-framework-dos-and-donts|Do ant Don't]] | ||
- | * [[http://blog.castman.net/programming/2016/07/28/robotframework.html|中文介紹]] | ||
- | * [[http://code.google.com/p/robotframework/wiki/HowToWriteGoodTestCases|How to write good testca | ||
- | es?]] | ||
- | * [[https://www.sitepoint.com/smelly-cucumbers/|smelly-cucumbers]] 這篇探討如何寫好Gherkin Style,我認為是keyword精細度的問題吧! | ||
- | ==== Gherkin Style基本知識 ==== | ||
- | * [[http://www.jollen.org/blog/2014/11/mokoversity-farm-1.html|BDD]] | ||
- | * [[http://docs.behat.org/en/v2.5/guides/1.gherkin.html|Gherkin language]] | ||
- | * [[https://github.com/cucumber/cucumber/wiki/Given-When-Then|Given-When-Then]] | ||
- | * [[http://martinfowler.com/bliki/GivenWhenThen.html|GivenWhenThen]] | ||
- | * [[https://sukesh15.gitbooks.io/cucumber-jvm-test-framework-/content/cucumber_-_more_details/data_driven_testing_using_cucumber.html|data-driven testing using cucumber]] | ||
- | |||
- | ===== ===== | ||
- | ---- | ||
- | \\ | ||
- | ~~DISQUS~~ |