最终目标是整洁可用的代码
我们不是从建立对象开始，而是从测试开始
了解需求-》设计测试 -》让测试通过
列出所有已知问题，然后一个一个解决；
培养将软件开发化为一小步一小步开发任务的能力
测试程序与代码所存在的问题不在于重复设计，而在于代码和测试程序之间的依赖关系
如何开始设计测试代码，通过方便测试的角度来修正程序的设计，如果两个方法之间有依赖关系怎么处理，
先写最简单的测试，只根据需求，然后发现实现有问题，修改测试，修改代码（or修改代码 修改测试）？
让测试迅速通过的方法：
伪实现，显明实现；
将一个设计缺陷（副作用）转化为一个由此缺陷导致运行失败的测试程序；
用伪实现使代码迅速编译通过；
输入正确的代码使测试尽快工作；
写一个测试程序；
让测试编译通过
测试程序运行失败
让测试程序可以运行
消除重复设计，优化设计结构；
Test DB：
1。 是否可以连接到数据库；
2。是否有权限执行存储过程；
DBTest test = new DBTest(connectstr);
MyTest mt = new mt(connectstr);
IsEquel(test.CanConnect(), mt.canconnect);
IsEquel(test.CanExe(sql), mt.CanExe(sql));
TDD的应用粒度：我觉得一个软件还是需要现有一个整体的设计，对于具体非常小的模块可以基于TDD来开发
光设计或做原型是不是比TDD更加清晰一点呢？TDD的似乎是摸着石头过河，高屋建瓴岂不是更好？
我觉得TDD最大的优点是从使用的角度而不是开发的角度来看待软件；能够生成更好的应用接口。
单元测试与Scrum：单元测试的优点是随着测试用例的累积，对于系统的修改有更多的质量保证，但是随着测试用例的增加，维护成本也是不断提升，特别是在scrum模型中，单元测试似乎很鸡肋了
安排，行动，断言
若在几个测试中用相似的对象，我们将一次创建所有对象来测试，但同时尽量避免测试用例之间的耦合
断言优先
什么时候写测试，在哪里写测试，什么时候停止写测试：
从计划列表里选择具有指导意义而且你有把握实现的测试；
从测试某个实质上不做任何工作的操作开始；
