关于项目的自动化测试思考

    最近在做一个敏捷性项目开发，大家基本都在trunck开发，开发环境提交很快就要在生产环境运行 。  这让我第一次明白什么叫“有五个bug，改了一个bug，还有七个bug”。项目迭代的很快，却没有一个自动化的测试工具，帮助开发人员完成测试，测试基本靠手，当然还有测试人员。

    测试主要有单元测试，集成测试。 单元测试框架有mocha  karma   集成测试框架有CasperJs代码覆盖率有istanbul，理想的情况是做好测试的框架，新来的员工完全不需要学习，可以直接使用。 现在的想法是这样的，在svn上修改pre-commit文件，在代码提交之前运行一下mocha（引用Chai作为断言库），通过则提交，失败则回滚。这样不用每次提交代码都要小心的手动测试，眼睛死盯，完全靠目测。  

  本文因篇幅有限，只讨论单元测试，既然是单元测试当然不能发送真正的ajax请求了，不然那就是端对端测试了，大家可以参考下mockjs等造数据的框架，这里不再赘述。单元测试的核心是： 对于给定的输入，其输出也是确定的。单元测试做的好，还可以强制你把代码写的耦合性低（不然怎么测^_^）

  学过java的都知道TDD，TDD是“测试驱动的开发”（Test-Driven Development）的简称，指的是先写好测试，然后再根据测试完成开发。使用这种开发方式，会有很高的测试覆盖率。这是一种对实现的具体细节写测试的方法，但是我认为并不是特别适合前端的测试，这里我推荐书写BDD（Behaviour-Driven Development）也就是行为驱动开发，将父组件作为一个Test Suit  所有测试的方法作为一个个test case. 

   那什么样的需要写testCase呢？具体到我做的项目中，我认为react的render中使用变量（再具体点就是大括号括起来的）的可变区域应该做单元测试。如果render的变量输入符合预期，那么我认为他是通过了测试。

整体的项目应该是这个样子：

（一个test文件夹，下面是文件名.test.js || 文件名.test.jsx）