我的第一个真正意义上的测试

我的同事何尝不是这样，主要是他们写测试而不去遵循基本的写单元测试的原则，不去遵循一定的策略，因此，对与他们来说写测试代码只会是一种额外的工作，耽误时间。
此外，很多同事不愿去了解测试的相关理论，他不去了解为什么这么做，也不去实践，你跟他说了，他也不认同。跟何况，写测试代码对于生手来说的确很难，或者说TDD入门很难，我已经花了很多时间了，还没入门呢，不过我越来越喜欢它了。
还有，TDD的很多好处只有你去实践了，你才会体会的到，否则，你永远都体会不到的，我们同事，大多数对于测试的理解都停留在大学里的古老的软件工程里提到的那点测试而已，而且根深蒂固的认为，测试是测试组的事。他们宁愿花很多时间在调试，在debug，也不愿写测试。
7月份，我在我们的项目中引入持续集成，在引入之前我发了N多邮件，说了N多基本的原则，可是那有怎么样？出错了都邮件通知了，告诉你有bug了，可是没人去改，build几十次了，惟独成功过一次，而且那次还是花了很大的精力去复查的，可是过来几天，有回去了。对我们来说，持续集成有一定的效果，但是收效并不大。我现在面临的最大的困难就是怎么去说服其他人，可是有些事，我想我怎么也做不到。郁闷死了。幸好，我可以自娱自乐。

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

这里插句题外话：
根据我们老总几十年得出的经验

工资的优先级比 单元测试、重构、持续集成、模式、面向对象 。

这是他说的
不过话有说回来，足以证明测试在高手心目中的地位