在Selenium1.0處于開發階段的同時，另一款瀏覽器自動化框架WebDriver也正在ThoughtWorks公司的醞釀之中。WebDriver項目的初衷是把端對端測試與底層測試工具隔離開。通常情況下，這種隔離手段通過適配器（Adapter）模式完成。WebDriver正是來源于該方法在許多項目上的不斷實踐應用，初是HtmlUnit的封裝，工具發布后很快開始支持Internet Explorer和Firefox。WebDriver的初代碼在2007年初發布。
在WebDriver初發布時，與Selenium RC存在顯著差異，盡管它們都屬于瀏覽器自動化的API工具。對于用戶來說，明顯的區別在于Selenium RC提供基于字典的API，所有方法都在一個類中開放，而WebDriver的API更面向對象。此外，WebDriver僅支持Java，而Selenium RC提供廣泛的語言支持。技術差異也很明顯：Selenium Core（RC的基礎）基本上是JavaScript應用，運行在瀏覽器的安全沙箱之內。WebDriver則嘗試原生綁定到瀏覽器中，繞開了瀏覽器的安全模型，代價是框架自身的開發投入顯著增加。
在2009年8月，兩個項目宣布合并，Selenium WebDriver是合并的成果。
WebDriver的創建者Simon Stewart早在2009年8月的一份郵件中解釋了項目合并的原因:
為何把兩個項目合并？部分原因是WebDriver解決了Selenium存在的缺點（比如，能夠繞過JS沙箱。我們有出色的API），部分原因是Selenium解決了WebDriver存在的問題（例如支持廣泛的瀏覽器），部分原因是因為Selenium的主要貢獻者和我都覺得合并項目是為用戶提供框架的佳途徑。
目前，WebDriver支持的語言綁定包括Java、C#、Python和Ruby。它支持Chrome、Firefox、Opera和移動端Android、iPhone瀏覽器。此外，還有其他關聯項目，不在同一源代碼庫中維護，但是和主項目（Selenium WebDriver）緊密合作，例如提供Perl綁定支持、BlackBerry瀏覽器支持，以及“無頭”WebKit——用于持續集成的測試其無法正常顯示的情況。初的Selenium RC機制仍然維持，幫助WebDriver在瀏覽器不受支持的情況下提供支持。
在兩個項目合并中出現了哪些架構方面的問題？學到了哪些經驗和教訓？Simon Stewart在《The Architecture of Open Source Applications》一文中做了詳細的描述，本文參考了以下內容：
http://www.aosabook.org/en/selenium.html
http://www.infoq.com/cn/news/2011/07/selenium-arch-2
處理復雜性
軟件是模塊構造起來的。這些模塊很復雜，作為API的設計人員們，可以選擇如何處理這種復雜性。極端情況下，可能會傳播這種復雜性，這意味著API的每一位用戶都需要牽涉其中。另一個極端情況是承擔盡可能多的復雜性并將其隔離在某個地方。這個地方對于許多想一探究竟的API用戶來說黑暗而恐怖。折中方案則是API的用戶，如果無須深入了解實現細節，那么只需面對當前所遇到的復雜性即可。
WebDriver的開發人員更傾向于發現并在少數地方隔離這些復雜性，而不是傳播它。這么做的原因之一是為用戶著想。看看bug列表會知道，他們特別善于發現問題和缺陷，但是因為許多用戶不是開發人員，復雜的API不會受歡迎。開發人員試圖讓API正確地引導大家。例如，考慮下面來自早期Selenium API的方法，每一個都用于設置輸入元素的值：
• type
• typeKeys
• typeKeysNative
• keydown
• keypress
• keyup
• keydownNative
• keypressNative
• keyupNative
• attachFile
下面是WebDriver API中的等價方法：
• sendKeys
如前所述，這凸顯了RC和WebDriver之間的主要思想差異——WebDriver在努力模擬用戶，而RC在較低層次提供的API讓用戶難以或者無法使用。typeKeys和typeKeysNative之間的區別在于前者總是使用合成事件（synthetic event），而后者則嘗試利用AWT Robot輸入鍵值。令人失望的是，AWT Robot發送按鍵事件給具有焦點的任意窗口，也是說可能不是瀏覽器。相比之下，WebDriver的原生事件，直接把事件發送給窗口處理函數，避免了瀏覽器窗口必須具有焦點的要求。
