软件构造踩坑记录——测试

(3.4的修改忘了没传到git仓库，一起交了)中间几天都没有动实验，懒了。今天写了一下测试，测试真是毒瘤，踩了许多坑，不过好在终于完成了。记录一下踩的坑
为了读入时能够判断是否重名，我在Person类中添加了一个静态私有成员Setpeoples，用于记录已经添加过的人的姓名的集合，于是悲剧开始了，写完测试函数后一个一个测试完全没有问题,于是开开心心疯疯癫癫得开始一起测试，然后就输出了"Each person should has a unique name!"，然后发现每个测试把人名加到peoples里面后，之后的测试还是往同一个peoples加，就会出现重复。于是我想那就不加static了，恩，果然测试都没问题了；但是我转念一想，每个Person实例都有一个单独peoples，那就算真的重名了也不会出现"Each person should has a unique name!"吧！于是我造了个测试样例，输入了两个同名的人，果然测试还是通过了，没有显示错误信息。考虑到题目的逻辑，肯定要先输入人名，再加点，再加边，最后算距离，于是我想：本来每个测试函数都new一个FriendShipGraph，还要new很多也就4个，哪来很多Person实例，那我把这些都搞成全局变量不就好了！(不要模仿，不要乱搞全局变量，不然容易耦合度高)于是按照这个想法实现了一下，但是因为本人很蠢，实现的时候还把"全局变量"放在测试类里面，结果它们都变成数据成员了(事后记录的时候才发现的，也许放到类外就可以了，没有尝试)。结果测试的时候抛出了Null啥啥的异常，只有第一个测试的函数通过了。我又开始debug，发现从第一个函数结束，到第二个函数，我认为的"全局变量"们(实际上是数据成员)，都变成null了，不管它们原先的值是多少，而且我发现被测试的函数的顺序和我想的有所不同。一开始，我以为是测试函数的顺序的原因才导致出现null，因为按照我的想法只有先测试了addVertex函数后graph中才会有点(所以说不要瞎搞全局变量！耦合度太高了)，我就想着怎么控制测试顺序(还没意识到耦合度过高的我，是屑)。在网络上一番搜索，发现在从Junit 4.11版本开始，Junit的测试是按照一个固定的但是不可预测的顺序执行的。
但是Junit 4.11及之后的版本提供了改变测试顺序的方法

import org.junit.FixMethodOrder;
import org.junit.Test;
import org.junit.runners.MethodSorters;
    
@FixMethodOrder(MethodSorters.NAME_ASCENDING) public class FriendShipGraphTest {}

NAME_ASCENDING表示根据测试函数的函数名按照字典序从小到大进行测试，当然还有别的，在此不一一列举。于是我改了该函数名来改变测试顺序，又一次得到了Null啥啥的异常。又开始debug，结果发现从一个测试函数到另一个测试函数后那些"全局变量"们又双变成null了，察觉到不是顺序的问题，但也没去考虑自己"全局变量"位置放错了。我转念一想：每次clear一下Set不就不会出现不该出现的重复了吗(这句话貌似不有点多)！然后又把代码改回去，终于绿了​​