摘要:
这段时间整理了一下TDD的一些认识:TDD路线需求(不清晰、不完整)-》设计(不清楚、不完整)-》测试(需求清晰化、设计清晰化)-》实现-》重构不是一开始就写测试,而是一开始分析需求,这个需求往往不清晰也不完整。针对这个需求我们要做大体的设计。然后开始针对某个需求编写测试用例,写测试用例的时候你会发现隐藏在背后的需求,这也是需求清晰化的过程。这样开发人员一开始就可以接触需求,而不是一开始搭框架。针对测试用例编写实现代码,然后适当重构。再继续针对下个需求编写测试,如此往复。这样不但紧紧的抓住需求,保证你的代码都的可测性,最后还留下监护代码质量的测试工程。这就好比造飞机按照当前我们的软件开发方式。 阅读全文
摘要:
尽管在传统测试理论中,测试几乎已经伴随了整个开发周期:单元测试、集成测试、系统测试、验收测试。但是,更多的时候我们遇到的情况是:至少在项目开始集成之前,测试是基本不存在的。程序员不愿意在模块完成之后再花时间来写测试代码(事实上,很多程序员连文档都欠奉),而测试人员则不会写测试代码(能写代码的话通常都已经被抓去写代码了)。事实上,即使测试人员愿意写测试代码来完成对代码的单元测试,这样的分工也是不划算的,因为这引入了额外的人与人之间的交流成本。于是我们的测试通常是在集成阶段开始进入的,于是我们不得不在这个时候在来面对可能的模块质量问题、模块设计问题以及其他许多早在那之前就应该已经解决的问题。 这个 阅读全文
摘要:
先考虑它是否可以单独到一个类,再考虑使用反射class Stranger { public Stranger(final String name) { this.name = name; } private final String greet(final String hello) { return hello + name; } private String name = "";}public class PrivateTest { public static void main(String args[]) throws Exception { Stranger testObj = ne 阅读全文