一个不过百行的程序导致多花费2天时间的原因剖析

1.写的junit test code在Eclipse中能通过，但在命令行的ant test中不能通过。最后重写了junit test code (由于没有预计到这一问题，导致多花费了4小时：重写测试代码，去掉继承与抽象类)。

2.在Eclipse中把测试资源(src/test/resources)会编译到classpath下，而ant脚本却不编译，提交代码后导致build失败。问题分析与定位花费3小时（仔细阅读ANT脚本和Ecllipse工程buildpath设定），重写code花费10分钟，重新测试10分钟。总计多花费近3个半小时。

3.由于没有理解用户登录过程和我们的代码流程，导致代码不正确。发现这一问题并想到原因所在和弄清楚登录过程和代码的处理的关系导致多花费4小时。

4.没有理解junit4的@Before @BeforeClass @After @AfterClass导致代码丑陋和重构多花费2小时（1个小时看junit4的文档，1个小时重写code）

5.没有理解derby数据库的原理和AE使用它的机制导致多花费4小时。（之后仔细阅读Derby文档，研读例子程序，并写程序验证它的使用）

问题总结：

自己的问题：

1.注意Eclipse中测试代码运行行为和命令行build命令运行测试代码的行为应保持一致。在Eclipse中跑完后，再在CLI 跑ant test来看效果。

2.对于自己似是而非的问题一定要彻底弄懂，比如junit @Before @BeforeClass 

3.误以为自己看一眼derby就知道怎么用，其实没有真正理解，比如为什么嵌入式Derby不能被两个程序同时访问，derby.system.home的意义。

4.测试要保持独立性，把以前遗数据清空后再测试，这个跟3有关系。

5.没有理解用户登录流程和我们的代码处理逻辑。

6.沟通需要加强，对自己模糊的问题要打破砂锅问到底

项目中的问题：

1.build脚本应该考虑到测试资源的编译问题

2.build脚本应该和开发工具的运行结果一致

3.应该有设计文档和需求文档，以帮助开发者快速理解其工作内容

项目中未来改进点：

1.完善build脚本，要考虑测试资源的编译问题。

2.团队间加强沟通。定期举办心得体会，经验交流，陷阱与规避，开发注意事项等交流。

---- 一年后，2014年1月份，对一年前的这篇总结的反思---
1.对于问题1的原因是什么，总结没有说清楚。 在开发工具中能通过的case在命令行中不能通过，应该说跟代码关系不大，即使改代码也应该最多改一两行代码，不至于重写全部代码，并去掉继承和抽象等的面向对象特性。 一定是根本原因没找对，或者方案不够好，需进一步思考：真的需要改这么大么？
2. 既然你在开发工具中设定将测试资源编译到classpath中， 那么应检查ant脚本是否也考虑到这一点，不可想当然。
 1和2本质是同一个问题引起的，测试资源未编译到classpath下，导致本地的命令行 ant test 不能通过。在没有意识到这个问题的前提下，在开发工具中运行test case通过后，就将代码签入到代码库后，又导致了问题2的产生。
3.磨刀不误砍柴工，在用某个工具或技术前把它的原理，基本概念等弄清楚是很重要的。这些上多花费3小时，但可为你节省18个小时的返工和改错。