标签：实现 测试 合并 cer inter tostring 修改 开头 check
测试：
1、 每个测试单元上面标好各个变量满足的条件，比如name is nonexistent之类的，不然回来检查的时候会很头晕。
2、 在1的基础上，每个测试单元的命名直接用testMethodNameX就好，其中X是编号（1，2，…）。之前试过把测试的内容放到名字里，但是这样名字就会太长，还不如1那样方便。
3、 observer的测试优先级要低于producer、mutator，一些复杂综合的等价类划分和边界值的测试用例都可以在后两者中测试，observer中只做最必要的测试。毕竟编写测试用例是一个很让人头秃和烦躁的事，需要大量的复制粘贴……
4、 每个测试单元都要用到的实例可以在类内声明为private的field，例如需要声明被测试类的实例之类的，减少在各个方法中声明所带来的重复代码行数的增加。虽说有时候代码行数多也不是什么坏事XD。
5、 在测试抛出异常时，如果期望它抛出异常，则在try的末尾加上assert False；反之，则在catch的末尾加上assert False。
6、 小型的测试（只针对一个方法的测试）比大型的测试效果（多个方法综合的测试）要好得多，后者的设计难度大，且覆盖程度低，但是会给人心理上测试了所有方法的安慰。我个人只会在最上层使用大型的测试，例如API的测试、客户端的测试等等。
7、 Test文件最开头最好有一个testAssertionsEnabled，不过这个在生成Junit文件的时候会自动生成，问题不大。
架构
1、 具体写代码之前，最好先在草稿纸上写写画画，在脑海中对需要多少类，每个类需要实现的功能有个大体的估计。
2、 尽量从interface写起，可以让自己不用纠缠于各种field声明，或者处理各种warning，毕竟看着一堆红色和黄色下划线还是挺烦人的。
3、 能用工厂方法就用工厂方法，减少暴露是其次，打Class.getClass()要比new Class()快很多，因为有代码自动补全。
4、 protected要比private好用得多，如果不确定将来需不需要扩展，那最好用protected。
5、 每个类都重写一遍toString、equals、hashCode，因为List、Set之类的都会用到。
6、 如果有一个方法在各个子类中名称/功能相同，但因为参数的不同，在各个子类中都需要自己实现，那最好也在父类中声明这个方法，然后直接扔出一个异常——毕竟子类大概率也是要扔异常的。
实现
1、 尽量不要合并判断语句，每个抛出的异常都要提供尽可能详细的信息。
2、 每个方法最好都要带checkRep，而且这个里面的判断是随着调试不断增加的，因为一开始的RI考虑得并不会很全面。
3、 在用类内的field时，前面尽量带this，一是提高代码的可读性，二是有代码自动补全，很方便。
4、 producer千万别忘了defensive copy。
5、 我个人会将各种异常一直往上扔，直到某一层统一处理。
6、 如果一个循环既可以用迭代器，也可以用枚举角标，那最好枚举角标，因为迭代器的修改和删除会需要很多技巧，不然会导致很多意料之外的问题。如果前者用的很熟练，那请随意。
7、 如果某个变量不知道该用List还是Set，那就用List，因为会有类似“取出任意一个元素”的操作，List会很方便。
8、 常用ctrl+s，常用ctrl+shift+f。
本来这三部分每一部分都要拿出来写一篇博客，但因为各种各样的原因（笑），就暂且写为总结了。
标签：实现 测试 合并 cer inter tostring 修改 开头 check
原文地址：https://www.cnblogs.com/WDZRMPCBIT/p/13215592.html
