数据驱动测试(一) – 开篇
数据驱动测试(一) – 开篇
(Note: 本篇讨论的是基于数据库的系统的单元测试问题)
这个话题说起来应该是一个老生常谈的话题了，再开此帖是想与大家探讨大家的处理方式，同时也来验证我们团队4年来的做法是不是可以有更多的改进。
在实践的过程中，很多项目并不能有效地坚持单元测试，即使书写了，也不能够持续也去维护这些单元测试，最后，这些单元测试代码将被废弃不再使用。长此以往，团队将不再愿意去写单元测试。
咎其原因，在我看来最重要的不外乎两点。
第一点，也是最重要的一点，团队并没有意识到书写单元测试是一件非常有必要，有意义，有价值的事。这个话题就不展开探讨了，网上一搜一大把。在这里，我分享我最最最喜欢的一句话：越好的单元测试会让我们的老板和我们自己能够睡得越踏实。
第二点，单元测试比较麻烦，编写单元测试麻烦，维护单元测试麻烦。
以我实际工作的经验来看，第二点是确确实实存在的，说是麻烦，还是比较客气的，有的时候在受压于项目进度和项目成本的情况下，几乎可以用做不到来形容。
举两个例子来说明
1．A表的STATUS字段从PENDING改成ACCEPTED
2．关连A, B, C, D表后实现查询功能
大家会怎么做？
大家的项目中会对这两种情况进行完整的单元测试，并有效地维护了这些单元测试用例吗？
我们项目的做法是
1．准备数据
2．每次跑单元测试之前导入这些数据
3．跑完单元测试之后清理这些数据
欢迎大家一起探讨，特别是结合自己项目中的实际情况一起探讨。
我在接下来的文章中也将我实际使用的方法和工具和大家分享。
大体思路是设计一个工具能基于具体的业务需求方便地准备数据，从而能让单元测试在这些数据的基础上能够有效和低成本地实现。
工具的设计要求是：
1．能方便地设计和准备测试数据
2．在数据库变更的情况下能方便地维护已存在的测试数据
3．测试团队和开发团队都能够方便都使用
4．所有团队成员之间设计的数据要能够避免冲突
具体实现是：
1．在Excel中设计数据
2．能使用一些API在集成工具中导入数据，如Hudson, Ant, Maven
3．能在图形界面中导入全部或特定测试用例的数据
4．能自动同步数据库表结构的变更到Excel中
5．分配指定的主键区间给每一个团队成员
