Selenium 2.0的由来及设计架构（一）

就在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的用户，如果无须深入了解实现细节，那么只需面对当前所遇到的复杂性即可。

就在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的用户，如果无须深入了解实现细节，那么只需面对当前所遇到的复杂性即可。

最新内容请见作者的GitHub页：http://qaseven.github.io/

前端工程化中重要概念之测试框架 前端工程化中测试框架的选择及其作用 在前端开发中，测试是确保代码质量和可靠性的重要环节。前端工程化中的测试框架可以帮助开发者编写和运行各种类型的测试，例如单元测试、集成测试、端到端测试等，从而确保代码的正确性和可靠性。下面介绍一些在前端工程化中常用的测试框架及其作用：