设计模式_28
1. 有过一次失败的单元测试经验：好不容易申请到了2周的预研时间，我开开心心地研究怎么把JUnit引入项目，刚开始了两天，新的开发任务打断了我的计划，然后就再也没有继续了。。。

2.
代码：
/**
 * 查找递增数组中第一个大于等于某个给定值的元素
 * @return -1: 未找到
 */
public int findFirstEqualOrLargerIndex(int[] array, int num) {
    if (array == null || array.length == 0) return -1;

    int start = 0;
    int end = array.length - 1;

    while (start != end) {
        int middle = start + (end - start) / 2;

        if (array[middle] >= num) {
            if (start == middle) return middle;
            else
                if (array[middle - 1] < num) return middle;
                else end = middle -1;

        } else {
            start = middle + 1;
        }
    }
    //start == end
    if (array[start] >= num) {
        return start;
    } else {
        return -1;
    }
}

测试用例:
findFirstEqualOrLargerIndex(null, 1)
findFirstEqualOrLargerIndex(new int [0], 1)
findFirstEqualOrLargerIndex(new int [] {0}, 1)
findFirstEqualOrLargerIndex(new int [] {1}, 1)
findFirstEqualOrLargerIndex(new int [] {0, 0}, 1)
findFirstEqualOrLargerIndex(new int [] {0, 1}, 1)
findFirstEqualOrLargerIndex(new int [] {1, 1}, 1)
findFirstEqualOrLargerIndex(new int [] {0, 1, 2}, 1)
findFirstEqualOrLargerIndex(new int [] {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}, 1)
findFirstEqualOrLargerIndex(new int [] {0, 1, 1, 1, 1, 1, 6, 7, 8, 9}, 1)
findFirstEqualOrLargerIndex(new int [] {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}, 10)

我估计应该有漏洞，请老师和同学们指正~

以前在开发中，没有写单元测试的意识。开发完功能后，直接去测试一个完整的流程。即前端发请求，服务端处理，看数据库数据。如果功能正确就过。这是从一个功能宏观去考虑测试。而单元测试是更细粒度的测试，它在保证各个“单元”都测试通过的情况下整个功能模块就测试通过了。这样的方式对于我们自己来说对代码可控粒度更细。更能比较清楚的理解某个“单元”在整个功能模块调用链路上的位置，承担什么职责，以及有什么行为。而不是一开始就站在模块宏观角度来思考。通过一个个单元测试的编写，将整个功能模块串联起来，最终达到整个功能模块的全局认知。 这也体现了任务分解的思想。通过单元测试，可以从另外一方面实现对已编写的代码的CodeReview，重新梳理流程。也为以后有重构需求打下基础。
       目前参与的项目中有单元测试，但是不够完备。可能由于某些原因（开发人员意识问题，团队对单元测试的执行落地程度不够等）。在写单元测试的过程中，遇到单元测试依赖数据库查询问题，因为存在多套环境，如开发环境，仿真环境，线上环境。对于依赖数据查询的单元测试，只能自己造假数据来解决。不知道还有什么好的解决办法。