xunit設(shè)計思路是什么

這篇文章的內(nèi)容主要圍繞xunit設(shè)計思路是什么進行講述，文章內(nèi)容清晰易懂，條理清晰，非常適合新手學(xué)習(xí)，值得大家去閱讀。感興趣的朋友可以跟隨小編一起閱讀吧。希望大家通過這篇文章有所收獲！

設(shè)計思路

任何一個系統(tǒng)，模塊，處理單元的工作模式都可以簡化為IPO模型，即把一定的輸入通過模塊定義的動作，轉(zhuǎn)化為一定的輸出：

input --> process --> output。

由于input和output從數(shù)據(jù)本身的屬性來看沒有本質(zhì)區(qū)別，xunit把輸入數(shù)據(jù)/輸出數(shù)據(jù)統(tǒng)一抽象為Context接口。

package com.xrosstools.xunit;

public interface Context {

}

接著把輸入到輸出之間的轉(zhuǎn)化行為定義為接口，這種接口稱為行為組件。

最基本的Converter接口，其工作就是把輸入Context轉(zhuǎn)化為輸出Context。

如果輸入與輸出是相同的具體類型（Context的具體實現(xiàn)類），則Converter接口可以簡化為Processor接口。即僅僅接收輸入Context，但沒有返回值。Processor一般對輸入的Context的內(nèi)部屬性做處理。

由于功能的劃分，需要將多個行為組件組合成為更大的結(jié)構(gòu)，這種結(jié)構(gòu)稱為結(jié)構(gòu)組件。

將不同的Converter或Processor依次串聯(lián)起來，讓Context從第一個處理單元一直流動到最后一個處理單元，以此完成一系列動作，這種最基本的結(jié)構(gòu)就是結(jié)構(gòu)組件Chain。

如果需要在兩個行為組件之間選擇一個，則需要對Context進行判斷，這種封裝了判斷的行為組件就是Converter的另外一個變種Validator。Validator對Context進行判斷操作，返回的是一個Boolean類型的輸出。有了Validator，即可以組合成BiBranch這種結(jié)構(gòu)組件。

同理，有時我們需要基于Context在多個行為組件之間進行選擇，這種封裝了選擇行為的組件就是Converter的另一個變種Locator。Locator對Context進行標識符的識別判斷，返回的是一個String類型的輸出。有了Locator，即可組合成Branch這種結(jié)構(gòu)組件。

基于Validator和單個行為組件，我們還可以構(gòu)建While Loop和Do While loop結(jié)構(gòu)組件，完成前置或后置條件判斷的循環(huán)操作。

如果希望復(fù)用某個已有的行為組件，但接口與我們需要的不一至則可以通過Adapter來做適配

如果希望對某個組件做修飾，可以使用Decorator組件。Decorator的行為自動與被修飾的組件保持一致。

組件

xunit的組件可以分為行為組件和結(jié)構(gòu)組件。行為組件定義針對Context能做的處理；結(jié)構(gòu)組件則對行為組件進行組合，將多個行為組件結(jié)合為更大，結(jié)構(gòu)更復(fù)雜的行為組件。與行為組件不同的是，結(jié)構(gòu)組件的行為模式需要手工指定，缺省是Processor。

行為組件

processor

對Context進行處理，但沒有返回值

public interface Processor extends Unit{
	void process(Context ctx);
}

converter

對傳入的context進行轉(zhuǎn)換，轉(zhuǎn)變?yōu)樾碌腃ontext。也可以返回原來的Context

public interface Converter extends Unit{
	Context convert(Context inputCtx);
}

validator

對Context進行true或者false的判斷

public interface Validator extends Unit{
	boolean validate(Context ctx);
}

locator

對Context進行分類的判斷。支持缺省值

public interface Locator extends Unit{
	String locate(Context ctx);
	void setDefaultKey(String key);
	String getDefaultKey();
}

dispatcher

對Context進行復(fù)制，分發(fā)，以及合并

public interface Dispatcher extends Unit{
    void setCompletionMode(CompletionMode mode);
    CompletionMode getCompletionMode();

    void setTimeout(long timeout);
    long getTimeout();

    void setTimeUnit(TimeUnit timeUnit);
    TimeUnit getTimeUnit();

    Map<String, Context> dispatch(Context inputCtx, Map<String, TaskType> taskInfoMap);

    // For CompletionMode.none, the results will be empty list
    Context merge(Context inputCtx, List<Context> results);

    Context onInvokeError(Map<String, Context> dispatchedContexts, Exception exception);

    Context onTaskError(Context taskCtx, Exception exception);
}

每個分支可以指定Task Type屬性，目前一共有三種：

• normal：普通的任務(wù)，是否必須完成根據(jù)CompletionMode來決定

• mandatory：必須完成的任務(wù)，與critical CompletionMode配合

• standalone：單獨執(zhí)行的任務(wù)。無需關(guān)注是否完成，不參與dispatcher的merge操作

CompletionMode是并發(fā)任務(wù)的執(zhí)行方式，目前有四種：

public enum CompletionMode {
    all,
    any,
    critical,
    none;
}

• all: normal的全部執(zhí)行完畢

• any: 任意normal執(zhí)行完畢

• critical: 全部mandatory執(zhí)行完畢

• none：調(diào)用所有的分支并且不等待返回既執(zhí)行下面的操作

結(jié)構(gòu)組件

chain

對內(nèi)部的unit順序調(diào)度處理。Context將被順序處理。

if-else

通過Validator決定調(diào)用內(nèi)部那個unit。也即BiBranch

branch

通過Locator判斷調(diào)度內(nèi)部那個unit

parallel branch

通過Dispatcher并發(fā)調(diào)度部分或全部unit

while loop

通過Validator判斷的while結(jié)構(gòu)

do while loop

通過Validator判斷的do while結(jié)構(gòu)

decorator

在操作前后處理

public interface Decorator extends Adapter {
	/**
     * Extends this method to provide decoration before decorated unit executed
     * @param ctx
     */
    void before(Context ctx);

	/**
     * Extends this method to provide decoration after decorated unit executed
     * @param ctx
     */
    void after(Context ctx);
}

adapter

將某種unit的行為轉(zhuǎn)換為另一種

public interface Adapter extends Unit{
	void setUnit(Unit unit);
}

單元引用

如果流程圖比較復(fù)雜，可以把圖的某些部分抽離出來成為單獨的圖，然后再原圖上進行引用。xunit會缺省的把與當前xunit文件同一個目錄下的其他xunit文件識別出來作為可以選擇的模塊。

例如：

如果這個單元已經(jīng)選擇了某個xunit文件，則會在已選擇的模塊前面顯示標記。 

如果要選擇的模塊與當前文件不是同一個目錄，可以通過“Reference to module”對話框指定具體路徑。

選擇了某個模塊后，其內(nèi)部可選的單元會都列出來。已經(jīng)選上的會有標記

如果沒有選擇任何外部模塊，缺省情況下會顯示當前模塊所有可以被當前被選中的單元引用的單元 

屬性自動識別

任何組件只要定義了PROP_KEY開頭的靜態(tài)String常量，則在通過編輯器打開后，其定義的常量的內(nèi)容可以被編輯器識別和顯示為該組件可配置的屬性。這些屬性會通過UnitPropertiesAware接口在組件被創(chuàng)建時設(shè)置進去。

例如DefaultUnitImpl的屬性定義：

 * public static final String constant with name start with PROP_KEY will be displayed 
 * in "Set property" context menu
 */
public static final String PROP_KEY_SHOW_MESSAGE = "showMessage";
public static final String PROP_KEY_SHOW_FIELDS = "showFields";
public static final String PROP_KEY_SHOW_APP_PROP = "showApplicationProperties";

// The method take higher priority
public static final String PROP_KEY_EVALUATE_METHOD = "evaluateMethod";
public static final String PROP_KEY_EVALUATE_FIELD = "evaluateField";

public static final String PROP_KEY_VALIDATE_DEFAULT = "validateDefault";

這些屬性在編輯器中可以顯示出來：

這樣做的好處是可以讓組件自解釋，方便其他用戶集成。當然沒有定義，用戶也可以在任何時候自行創(chuàng)建。

結(jié)構(gòu)不一致處理

結(jié)構(gòu)組件一般要求其內(nèi)部包含的行為組件與結(jié)構(gòu)組件自身定義的行為模式一致。不一至的情況下，可以通過Adapter來保持一致。為高效的復(fù)用現(xiàn)有組件，避免頻繁的配置大量簡單重復(fù)的Adapter，結(jié)構(gòu)組件內(nèi)置了簡單的適配機制。以Chain為例：

如果Chain的行為模式是Converter，而Chain中包含Processor，則Processor的輸入Context會當作Convert的結(jié)果傳遞到下一個單元。

如果Chain的行為模式是Processor，而Chain中包含Converter，則Converter的convert方法會被調(diào)用，但是轉(zhuǎn)化的輸出Context則會被丟棄。最開始輸入的Context會傳遞到下一個單元。

感謝你的閱讀，相信你對“xunit設(shè)計思路是什么”這一問題有一定的了解，快去動手實踐吧，如果想了解更多相關(guān)知識點，可以關(guān)注億速云網(wǎng)站！小編會繼續(xù)為大家?guī)砀玫奈恼拢?/p>