就在代码写完，开始写测试代码的时候，我们项目组内的人都遇到了相同的问题：
1、系统中程序之间的偶合度太强，业务层，UI，数据层依赖了太多的环境因素，很难分开，所以写测试代码前，还需要去虚拟很多东西
2、花了一天把需要虚拟的东西都做完后，又出现了一个最重要的问题，测试代码太多了，实在写不下去了，一个测试方法(业务比较复杂的)花了半天的时间，这比我写代码时间还多
之后为了完成任务只写了几个简单的测试代码提交。不久，其他项目组也遇到了这些问题，所以公司最后停止了这个过程。我当时听到这个消息的时候，心里有点不好受，因为从那时起我就觉得这是很好的过程，出现的这些问题只因为我们的实力还不够，同时它对于开发人员来说也是一个挑战，一个提高。可现在停止了，意味着失去了一个很好的锻炼平台。
出于不甘心失败，自己暗暗下决心，一定要提高自己的实力，一定要在设计前就写好测试代码!.....
迷茫
在之后的一两个月的时间内是很迷茫的，虽然自己下了决心，却不知道从何开始，盲目地在网上找资料，发现有意义的资料太少，身边虽然有牛人在，但是这个东西是只能意会不能言传的。去公司的图书馆找了些关于敏捷开发和极限编程的书，看完后体会还真是挺深的，加强了对"测试驱动开发"的认识，可自己还是不会.......!!
那时的自己连设计模式都不会几个，好象连接口interface都不太会用，至于抽象还是刚刚理解的阶段，对于单元测试，还没有学会MOCK。
不过我的运气还真好，就在这个时候，有个朋友找到我说，有个小项目需要帮忙，问我是否参与呢，由我来负责架构和设计(现在想想，他还真有魄力，敢让我这个菜鸟来架构)，我那时也很闲，而且正想找个实验的项目呢!于是就答应下来了。
项目其实很简单，外贸公司用于发布产品和网上销售的网站。用户数也没有要求，小公司要求可以用就可以了。花了一段时间接触客户，做出了简单的项目计划，基本完成了用户需求，然后就开始做基本架构了，架构还是用经典的三层模式，数据库选的是MYSQL，没有用O/R Mapping....这些第三方的框架。因为出于实践和学习，所以希望都通过自己手写来完成。接下来开始做具体的设计了，花了几天的时间做完了大概的设计，画完了UML图.....，就剩下代码了!
"单元测试"，任然加入了我的开发过程，在这里我总结了一开始失败的原因，加上自己这段时间的学习，知道了要减少程序之间的偶合度，减少依赖。可是真到写的时候，又迷茫了.....
文章来源于领测软件测试网 https://www.ltesting.net/