Tag: TotT

原文網址：https://testing.googleblog.com/2014/08/testing-on-toilet-web-testing-made.html Tuesday, August 12, 2014 by Ruslan Khamitov 在每個元素中增加 id 可以讓針對網頁的測試更易於操作 DOM (e.g. WebDriver tests)。考慮到下面兩個只有內文有差異的 DOM： Save button Edit button [crayon-6568404c86172817844666/] [crayon-6568404c8617a261436066/] 在這個例子中，你會如何使用 WebDriver 來與 "Save" 按鈕互動呢？你有許多的選項。其中一個選擇是使用 CSS selector 來互動： [crayon-6568404c8617c913208976/] 但是，這個方法並不足以認出一個特定的按鈕，而且沒有其他機制可以讓你在 CSS 中以其中的文字過濾。另一個選樣是使用 XPath，這個方法非常的脆弱且不鼓勵使用： [crayon-6568404c8617d936166891/] 你的最佳選擇是增加一個獨特的階層式分類 ID，每個 widget 會有一個 base ID，而這個 base ID 會成為其子元素的前綴。以剛剛的按鈕為例，他們的 ID 將會是： [crayon-6568404c8617f378694502/] 在 Google Web Toolkit (GWT) 中，你可以在你的 widgets 覆寫 […]

原文網址：https://testing.googleblog.com/2014/10/testing-on-toilet-writing-descriptive.html by Andrew Trenk 先來個問題：你要花多久時間來理解下面這個測試程式要做什麼？ [crayon-6568404c86596624722901/] 你大概閱讀了每一行程式 (說不定不只一次) 然後才理解每一行在做什麼。不過，如果一個測試有好的名子，你需要多少時間來理解下面這個測試想要做什麼呢？ [crayon-6568404c8659d886675510/] 透過良好的命名，你應該可以只透過閱讀測試程式的名稱，了解這個測試程式的想要測什麼，你甚至不用閱讀他的程式碼。前面提到的測試程式名稱只說明了他想要測試的情境 (scenario) 是 "invalidLogin"，但沒有真正的說明他期望的測試結果是什麼，所以必須要閱讀所有程式碼才能了解他的意圖。 將情境以及預期結果放在測試名稱還有其他的好處： - 如果想要了解一個類別所有的可能的行為，只要閱讀他的測試類別 (Test class) 中的測試名稱就可， 相比於原本需要花費數分鐘甚至是數小時來閱讀測試程式甚至是該類別本身來理解其行為。這對於 code reviews 也是有幫助的，因為你可以快速的了解是不是測試都已經覆蓋到所有可能的 cases。 - 藉由給予測試更為顯式的名子，可以強迫你把一個測試許多不同行為的 testing 拆分為不同的測試。 不然，你可能會想要把針對不同行為來測試的斷言放在同一個測試程式內，時間一久，這會讓整個測試程式膨脹且變得難以理解與維護。 - 測試的行為不一定每次都能從程式碼中清楚的了解其精確行為。如果測試名稱沒有顯式的告知其精確行為，有時候你會需要猜測這個測試到底在做什麼。 - 你可以簡單的了解到還沒有涵蓋進測試的功能。如果你沒有看到測試名子有那個你想要看或測試的行為，那你就知道，這個測試還沒有被實作。 - 當一個測試失敗的時候，你可以立刻知道是什麼功能失效，而不用去看測試程式碼。 . 有許多的 common patterns 來維護一個 test 的名子 (一個方式是，用英文句子中 "should" 的方式來命名，e.g., shouldLockOutUserAfterThreeInvalidLoginAttempts). 不論你用那種 pattern，同樣的建議依然適用：確保測試程式的名子包含了測試情境以及預期的結果 (Make sure test names contain both […]

原文網址：https://testing.googleblog.com/2014/03/testing-on-toilet-what-makes-good-test.html by Erik Kuefler 對於程式的正確性驗證來說，單元測試 (Unit tests) 是一個非常重要的工具。不過，撰寫好的測試遠比只驗證程式正確性還要重要 ─ 好的單元測試要有某些特徵來讓其易於閱讀與維護。 好測試的其中一個特徵是清晰 (Clarity)。 清晰的意思是指一個測試程式，應該被當作是一個易於人類閱讀的文件，描述其正在測試的 API 功能。 測試本身不應該直接介入實作的細節。一個類別的測試名稱，應該要能夠說明這個類別的用途；而他的測試應該被當作是如何使用這個類別的範例。 另外兩個重要的特徵是完整性 (completeness) 與精簡性 (conciseness) 一個測試在包含所有讓你了解其用途的資訊時為完整，以及沒有包含任何會讓你分心的資訊時為最精簡。 下面這個測試範例在並沒有剛剛提到的兩個重要特徵： [crayon-6568404c867cf364282677/] 許多會分散注意力的資訊被放入建構子中，且整個測試中最重要的部份被隱藏在一個 helper method 內。 我們可以透過變更 helper function 的方式使其目的更為清晰，讓整個測試更完整，而透過另一個 helper function 來隱藏不相關的建構子資訊使這個測試更精減： [crayon-6568404c867d5957901065/] 最後一個好測試的重要特徵是有彈性。當一個測試完成，有彈性的測試不必再做任何更動 ─ 除非被測試的類別之目的(purpose) 或行為 (behavior) 有所變更。增加新的行為時應該只需要增加新的測試，而不是更動舊有的。前面提到的測試是沒有彈性的，因為當你新增一個不相關的建構子參數時，你需要去更新他 (大概還有一堆其他的測試也要更新!) 。把這些細節移到另一個 helper method 可以解決這個問題。   6 comments: Srivaths SankaranMarch 19, 2014 at 1:38:00 […]