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

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

裝飾器模式是為了在原有功能上加入新功能，在Junit中絕對屬于使用最頻繁架構中最核心的模式，Runner、Filter、Rule等都是通過裝飾器模式來完成擴展的。下就以Filter的實現(xiàn)機制來說明。

首先從命令行中解析出來的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方法將會返回一個新的Request，不過是Request的子類FilterRequest，它依然保留原有的request，只不過在返回Runner的時候，再采用Filter過濾，如下：

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方法會調用runner自身實現(xiàn)的filter方法并以自己作為參數，以ParentRunner為例，我們給出filter方法的一般實現(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通過維護一個filteredChildren列表來提供它所有通過過濾的child，每次有新的filter作用到之上，它都需要更新該列表。對于原子的測試，它會提供出它的description，由Filter實現(xiàn)的shouldRun方法來判斷是否會被過濾，這也是filteredChildren列表更新的原理。

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

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

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

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

FilterFactories提供了各種由參數來生成不同工廠的方法，同時又使用生成的工廠來生成Filter，可以說在廣義上這就是一個抽血工廠模式，不過FilterFactories完成了生產產品的過程，又集成了提供各類工廠的方法。下面給出代碼大家感受一下：

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的組合。由于測試的需求十分多樣，有時需要測試單個方法，有時需要測試單個類的所有方法，有時又需要測試多個類的組合方法，所以對于測試的表達必須是強大的。組合模式顯然符合這個要求，根部的runner會調動子節(jié)點的run，向上只暴露出根節(jié)點的run方法。由于之前幾篇中對這一部分論述較多，此處就不再贅述了。

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

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機制需要在三個層次——類、方法和域上進行驗證，采用了職責鏈模式。