摘要：前言在這次的博客中我們將著重于的許多集成性功能來(lái)討論中的種種設(shè)計(jì)模式。裝飾器模式裝飾器模式是為了在原有功能上加入新功能，在中絕對(duì)屬于使用最頻繁架構(gòu)中最核心的模式，等都是通過(guò)裝飾器模式來(lái)完成擴(kuò)展的。

在這次的博客中我們將著重于Junit的許多集成性功能來(lái)討論Junit中的種種設(shè)計(jì)模式。可以說(shuō)Junit的實(shí)現(xiàn)本身就是GOF設(shè)計(jì)原則的范例教本，下面就讓我們開(kāi)始吧。

裝飾器模式是為了在原有功能上加入新功能，在Junit中絕對(duì)屬于使用最頻繁架構(gòu)中最核心的模式，Runner、Filter、Rule等都是通過(guò)裝飾器模式來(lái)完成擴(kuò)展的。下就以Filter的實(shí)現(xiàn)機(jī)制來(lái)說(shuō)明。

首先從命令行中解析出來(lái)的FilterSpec生成各種Filter，如下：

    private Request applyFilterSpecs(Request request) {
        try {
            for (String filterSpec : filterSpecs) {
                Filter filter = FilterFactories.createFilterFromFilterSpec(
                        request, filterSpec);
                request = request.filterWith(filter);
            }
            return request;
        } catch (FilterNotCreatedException e) {
            return errorReport(e);
        }
    }

request的Filter方法將會(huì)返回一個(gè)新的Request，不過(guò)是Request的子類FilterRequest，它依然保留原有的request，只不過(guò)在返回Runner的時(shí)候，再采用Filter過(guò)濾，如下：

public final class FilterRequest extends Request {
    private final Request request;
   
    private final Filter fFilter;

    
    public FilterRequest(Request request, Filter filter) {
        this.request = request;
        this.fFilter = filter;
    }

    @Override
    public Runner getRunner() {
        try {
            Runner runner = request.getRunner();
            fFilter.apply(runner);
            return runner;
        } catch (NoTestsRemainException e) {
            return new ErrorReportingRunner(Filter.class, new Exception(String
                    .format("No tests found matching %s from %s", fFilter
                            .describe(), request.toString())));
        }
    }
}

Filter的apply方法會(huì)調(diào)用runner自身實(shí)現(xiàn)的filter方法并以自己作為參數(shù)，以ParentRunner為例，我們給出filter方法的一般實(shí)現(xiàn)。

public void filter(Filter filter) throws NoTestsRemainException {
        synchronized (childrenLock) {
            List children = new ArrayList(getFilteredChildren());
            for (Iterator iter = children.iterator(); iter.hasNext(); ) {
                T each = iter.next();
                if (shouldRun(filter, each)) {
                    try {
                        filter.apply(each);
                    } catch (NoTestsRemainException e) {
                        iter.remove();
                    }
                } else {
                    iter.remove();
                }
            }
            filteredChildren = Collections.unmodifiableCollection(children);
            if (filteredChildren.isEmpty()) {
                throw new NoTestsRemainException();
            }
        }
    }

顯然非原子的Runner通過(guò)維護(hù)一個(gè)filteredChildren列表來(lái)提供它所有通過(guò)過(guò)濾的child，每次有新的filter作用到之上，它都需要更新該列表。對(duì)于原子的測(cè)試，它會(huì)提供出它的description，由Filter實(shí)現(xiàn)的shouldRun方法來(lái)判斷是否會(huì)被過(guò)濾，這也是filteredChildren列表更新的原理。

當(dāng)我們先后有多個(gè)Filter時(shí)，可以不停地包裝已有的FilterRequest，每個(gè)FilterRequest在getRunnere時(shí)都會(huì)先調(diào)用其內(nèi)部的Request，然后執(zhí)行相同的附加操作，也即更新內(nèi)部Request返回的Runner的filteredChildren列表。使用實(shí)現(xiàn)同一接口繼承同一父類的各個(gè)過(guò)濾器相互嵌套就可以實(shí)現(xiàn)一個(gè)過(guò)濾鏈。

工廠模式也在Junit中被大量使用，主要用來(lái)生產(chǎn)各類Rule、Filter等。我們依然以Filter機(jī)制為例來(lái)介紹一次抽象工廠的使用。FilterFactory是一個(gè)工廠接口如下：

public interface FilterFactory {
    
    Filter createFilter(FilterFactoryParams params) throws FilterNotCreatedException;

    
    @SuppressWarnings("serial")
    class FilterNotCreatedException extends Exception {
        public FilterNotCreatedException(Exception exception) {
            super(exception.getMessage(), exception);
        }
    }
}

FilterFactories提供了各種由參數(shù)來(lái)生成不同工廠的方法，同時(shí)又使用生成的工廠來(lái)生成Filter，可以說(shuō)在廣義上這就是一個(gè)抽血工廠模式，不過(guò)FilterFactories完成了生產(chǎn)產(chǎn)品的過(guò)程，又集成了提供各類工廠的方法。下面給出代碼大家感受一下：

class FilterFactories {
    
    public static Filter createFilterFromFilterSpec(Request request, String filterSpec)
            throws FilterFactory.FilterNotCreatedException {
        Description topLevelDescription = request.getRunner().getDescription();
        String[] tuple;

        if (filterSpec.contains("=")) {
            tuple = filterSpec.split("=", 2);
        } else {
            tuple = new String[]{ filterSpec, "" };
        }

        return createFilter(tuple[0], new FilterFactoryParams(topLevelDescription, tuple[1]));
    }

    
    public static Filter createFilter(String filterFactoryFqcn, FilterFactoryParams params)
            throws FilterFactory.FilterNotCreatedException {
        FilterFactory filterFactory = createFilterFactory(filterFactoryFqcn);

        return filterFactory.createFilter(params);
    }

    
    public static Filter createFilter(Class filterFactoryClass, FilterFactoryParams params)
            throws FilterFactory.FilterNotCreatedException {
        FilterFactory filterFactory = createFilterFactory(filterFactoryClass);

        return filterFactory.createFilter(params);
    }

    static FilterFactory createFilterFactory(String filterFactoryFqcn) throws FilterNotCreatedException {
        Class filterFactoryClass;

        try {
            filterFactoryClass = Classes.getClass(filterFactoryFqcn).asSubclass(FilterFactory.class);
        } catch (Exception e) {
            throw new FilterNotCreatedException(e);
        }

        return createFilterFactory(filterFactoryClass);
    }

    static FilterFactory createFilterFactory(Class filterFactoryClass)
            throws FilterNotCreatedException {
        try {
            return filterFactoryClass.getConstructor().newInstance();
        } catch (Exception e) {
            throw new FilterNotCreatedException(e);
        }
    }
}

在Junit中組合模式主要用于管理Runner和Description的組合。由于測(cè)試的需求十分多樣，有時(shí)需要測(cè)試單個(gè)方法，有時(shí)需要測(cè)試單個(gè)類的所有方法，有時(shí)又需要測(cè)試多個(gè)類的組合方法，所以對(duì)于測(cè)試的表達(dá)必須是強(qiáng)大的。組合模式顯然符合這個(gè)要求，根部的runner會(huì)調(diào)動(dòng)子節(jié)點(diǎn)的run，向上只暴露出根節(jié)點(diǎn)的run方法。由于之前幾篇中對(duì)這一部分論述較多，此處就不再贅述了。

最典型的就是Notifier和Listener，當(dāng)測(cè)試開(kāi)始、結(jié)束、出現(xiàn)錯(cuò)誤時(shí)，Notifier將通知它管理的Listener執(zhí)行相應(yīng)的操作，但有趣之處就在于為了能夠處理在通知過(guò)程中出現(xiàn)的異常，Notifer使用了一個(gè)內(nèi)部類SafeNotifier，所有的對(duì)應(yīng)事件（測(cè)試開(kāi)始等）覆寫SafeNotifier里的notifyListener函數(shù)，在其中寫調(diào)用Listener的具體哪一個(gè)函數(shù)。相關(guān)的詳細(xì)內(nèi)容請(qǐng)參考上一篇博客，下面給出RunNotifier的源碼(刪去部分內(nèi)容)。

public class RunNotifier {
    private final List listeners = new CopyOnWriteArrayList();
    private volatile boolean pleaseStop = false;

    public void addListener(RunListener listener) {
        if (listener == null) {
            throw new NullPointerException("Cannot add a null listener");
        }
        listeners.add(wrapIfNotThreadSafe(listener));
    }

    
    public void removeListener(RunListener listener) {
        if (listener == null) {
            throw new NullPointerException("Cannot remove a null listener");
        }
        listeners.remove(wrapIfNotThreadSafe(listener));
    }

    RunListener wrapIfNotThreadSafe(RunListener listener) {
        return listener.getClass().isAnnotationPresent(RunListener.ThreadSafe.class) ?
                listener : new SynchronizedRunListener(listener, this);
    }


    private abstract class SafeNotifier {
        private final List currentListeners;

        SafeNotifier() {
            this(listeners);
        }

        SafeNotifier(List currentListeners) {
            this.currentListeners = currentListeners;
        }

        void run() {
            int capacity = currentListeners.size();
            List safeListeners = new ArrayList(capacity);
            List failures = new ArrayList(capacity);
            for (RunListener listener : currentListeners) {
                try {
                    notifyListener(listener);
                    safeListeners.add(listener);
                } catch (Exception e) {
                    failures.add(new Failure(Description.TEST_MECHANISM, e));
                }
            }
            fireTestFailures(safeListeners, failures);
        }

        abstract protected void notifyListener(RunListener each) throws Exception;
    }

    
    

    public void fireTestRunFinished(final Result result) {
        new SafeNotifier() {
            @Override
            protected void notifyListener(RunListener each) throws Exception {
                each.testRunFinished(result);
            }
        }.run();
    }
    
    public void fireTestFinished(final Description description) {
        new SafeNotifier() {
            @Override
            protected void notifyListener(RunListener each) throws Exception {
                each.testFinished(description);
            }
        }.run();
    }

    
}

可以參考之前的第三篇博客，Junit的Validator機(jī)制需要在三個(gè)層次——類、方法和域上進(jìn)行驗(yàn)證，采用了職責(zé)鏈模式。