<<测试驱动开发的艺术>>读书笔记

1. TDD通过边测试边编写代码，然后重构来防止重构所引起的错误

2. 通过自动化测试和持续集成工具,随时保持可以发布

3. TDD第一步:

    1. 需求分解
    2. 将需求转化成测试
    3. 写一个失败的测试
    4. 逐步通过测试，再写一个测试
    5. 开始消除重复代码 (由于这个时候有测试在了，所以不用担心更改会引起集成错误)
   

看到这里感觉在国内公司已经很难实现这个了，因为时间很难让你去做这些事情

1. 交互测试，并不验证结果的正确性，而是验证代码与其协作对象的交互行为的正确性
2. 重构代码的时候不要直接用调试器调试，而是要把代码分为一个严格地软件开发活动
   
   1. 确定变更点
   
   2. 确定测试点
   
   3. 覆盖测试点
   
   4. 修改代码
   
   5. 重构代码

先分析程序再写测试再重构，以前都搞反了，先重构再写测试所以很难去保证重构后代码正确，因为思维方向就不对，先重构再测试时按照自己的思路来写测试，更倾向于为了通过测试而写测试，而 先测试再重构思路更倾向于根据业务来进行测试

1. 数据库测试，增量式DDL脚本。一次只添加一个列或者一张表，每个步骤都可以回滚
2. 数据库测试使用脚本或者其他方法添加进数据，然后进行测试