邁向原子化：為什麼？
分類
這是我撰寫的關於 Selenium WebDriver 內部結構的一系列技術文章中的第一篇。如果您對技術細節不感興趣，那麼現在就可以離開了。
還在這裡？太棒了。
讓我們回顧一下 Selenium 和 WebDriver 專案合併之前。很明顯，有兩個獨立的程式碼庫。更仔細地看，並以稍微不同的角度來看，有更多的不止於此。我們使用 webdriver 的測試套件來定義多個、基本上獨立的驅動程式程式碼庫的行為。 IE 驅動程式是用 C 語言編寫的，HtmlUnit 驅動程式是用 Java 編寫的，而 Firefox 驅動程式主要是 Javascript，等等。
這表示存在大量的「同餘程式碼」：執行相同功能但以不同方式實作的程式碼。這樣做的自然結果是，驅動程式之間的行為可能會有所不同。更糟的是，這表示當發現錯誤時，我們必須在每個瀏覽器中檢查它，而且不確定個人是否真的可以修復程式碼。畢竟，並非每個人都熟悉我們在專案中使用的所有語言，或者熟悉所有技術。對於像 Selenium 這樣的開放原始碼專案來說，這是一個主要問題：我們依賴於相對較小的核心開發人員，並由更大的團隊提交小的變更和修復來支援。任何使我們更難以作為開發社群有效運作的事情都是一件壞事。
因此，我們想要一種擺脫困境的方法；一種機制，可以輕鬆地在各種驅動程式和 selenium 核心之間共享程式碼，讓我們只需在一個地方修復錯誤，並讓該修復擴散到每個使用此機制的驅動程式。更重要的是，它必須易於使用，並且對於不熟悉大量語言和技術的人來說，可以快速上手。
這種機制會是什麼樣子？嗯，有一些因素促成了這一點，但最重要的一個因素是，我們認為要合併的大部分程式碼都在查詢瀏覽器的狀態（「尋找元素」、「取得此屬性的值」），而且，正如 Jason Huggins 會隨時向我指出的那樣，查詢瀏覽器狀態的自然語言是 Javascript。Javascript 的優點之一是，它有可能實現良好、快速的開發週期。只需修改測試，儲存，然後在瀏覽器中點擊「重新整理」。這有點吸引力。更好的是，有很多開發人員熟悉 Javascript。
因此，我們決定使用 Javascript。
由於此共享程式碼將由瀏覽器自動化所需的最有用功能片段組成，因此我們決定將它們稱為「瀏覽器自動化原子」，或簡稱為「原子」。與其從頭開始編寫，最簡單的方法是從現有程式碼中提取它們——這些東西都經過實戰測試，因此我們知道它們是穩健的。
有一個非常明顯的缺點：並非每個驅動程式都是用 Javascript 編寫的。雖然我們在每個瀏覽器中都有一個可用的機制 (http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/JavascriptExecutor.html) 用於執行 JS，但每當您想要查詢 DOM 時，將大量程式碼轉儲到瀏覽器的 JS 引擎中是非常沒有效率的。畢竟，大多數程式碼都不需要，而且並非所有 JS 引擎都是相同的。有些速度極快。有些則不然。
將程式碼分解為可管理大小的模組也很好，而不是放在單個、龐大的檔案中，這意味著需要一些聰明的「模組載入」功能。除非此程式碼不一定總是在可以編寫「script」標籤以載入其他腳本的環境中執行。您無法在 firefox 擴充功能的內部執行此操作，儘管您可以透過其他方式載入檔案。但是，我們將模組連結在一起的方式需要應對這一點。
啊！這些相互對立的需求：包含我們想要使用的功能的小模組，沒有多餘的程式碼，以及為了最大限度地減少載入其他模組的痛苦，所有內容都放在一個檔案中。這聽起來不像是一個非常相容的列表。我們如何解決這些差異將是我下一篇文章的主題…。
