Pattern per l'interfaccia tra gli oggetti che eseguono la sequenza e gli oggetti di configurazione della sequenza

Has anyone had to deal with a case like this before?

La tua configurazione banco / prova è più complessa di quella che ho affrontato, ma è lo stesso problema, solo più strati di costruzione.

Avviso: non lasciarti coinvolgere nell'inventare la struttura per generare e astrarre qualsiasi struttura, qualsiasi test, in qualsiasi momento.

Identifica, classifica e organizza ogni test

Se un test è un singolo metodo o una serie di metodi, o un composito di classe, sono tutti test e ogni test dovrebbe essere esplicitamente identificabile.

Ogni test dovrebbe essere progettato per funzionare da solo. Può essere eseguito come parte di una serie di test consecutivi, ma ogni test identificabile deve essere fondamentalmente indipendente.

Coding too soon

Pensare in termini di "metodi" è troppo ristretto, troppo subatomico. Ecco perché stai vedendo "l'accoppiamento tra questi è più alto di quanto vorrei". Ottieni l'organizzazione logica e il framework del codice emergerà da quello.

Osservazioni sulla struttura del test

• TestBenches : crea una sezione di configurazione.
• TestBench è probabilmente la parte superiore della struttura. Questo può anche fungere da spazio dei nomi, i test in diversi banchi di prova possono avere lo stesso nome.
• La struttura si rifletterà direttamente negli elementi del file di configurazione.
• L'ordine di prova nel file di configurazione è l'ordine di esecuzione.

Osservazioni di fabbrica

• Avrai una fabbrica astratta. Potresti avere il modello di builder in base alle dinamiche di costruzione di ogni dato test.
• La struttura astratta della fabbrica verrà mappata direttamente alla struttura del file di configurazione. Conosce la struttura. Sarà necessariamente strettamente accoppiato al file di configurazione.
• I nomi degli elementi di configurazione verranno convertiti in enum s. I vari enum s rifletteranno la struttura di configurazione. Ad esempio TestBenchXFactory utilizzerà Xtests enum . Questo efficacemente convalida gli elementi XML prima che proviamo ad usarlo.

Osservazioni OO

• Un sacco di soldi, ma è tutto un codice semplice fino a quando non arriviamo alla costruzione di oggetti di prova concreti e dinamici.
• Il numero di fabbriche può sembrare eccessivo o del tutto inutile. Tuttavia, stiamo riducendo al minimo l'accoppiamento della costruzione di livelli
• Aggiungendo, la rimozione dei test può sembrare una violazione dei principi Open / Closed, ma "sinceramente mio caro, non me ne frega niente."
• La buona aderenza al principio di responsabilità unica nelle classi di fabbrica rende facile il cambiamento. Ancora, Ogni test logico è indipendente

<BenchTests>
    <!- BenchTestFactory gets <BenchTests> as a parameter -->
    <!- builds a BenchTestCollection. Instantiate sBenchTestXFactory, etc. -->
    <!- Adds concrete 'BenchTest's to the collection. -->
    <TestBenchX>
        <!- 'BenchTestXFactory' gets '<TestBenchX>' element as a parameter --> 
        <!- instantiates 'BenchTestX' object. Builds each test, adds to 'BenchTestX'. --> 
        <!- Certain tests may need their own builder -->
        <Test1 param1 = 2 param2 = "Hello".. />
        <Test2 />
        <ComplexTest ... >
            <Test1>
            <Test5>
        </ComplexTest>
    </TestBenchX>

    <TestBenchY>
    </TestBenchY>
</BenchTests>

Le classi

Da quanto sopra sembra che abbiamo:

public class testBenchCollection {
    List<TestBench> TestBenches;

    public void AddBench ( TestBench newBench ) {}

    public void Execute(){
        foreach( TestBench bench in testBenches )
            bench.Execute();
    }
}

public abstract class TestBench {
    List<Test> testCollection;

    public virtual Execute(){
        foreeach( Test aTest in testCollection )
            aTest.Execute();
    }

    public void AddTest( Test newTest )
}

public abstract class Test {
    public virtual Execute(params object[] myParms ){}
}

public enum TestBench{ X, Y, Z }
public enum GlobalTests { eenie, meenie, minee, moe }
public enum XTests { test1, testToo }
public enum YTests { Larry, Moe, CurleyJoe, test1 }