Unit Testing e PostSharp

Question

Mi chiedo quale sia il modo migliore per farlo ... Sono interessato a introdurre PostSharp in uno dei miei progetti, ma non sono sicuro di come classi di test unitari contrassegnati con un attributo propriamente.

Ad esempio:

public class hello { 

    [MyAspectThatDoesSomethingToTheDatabaseWhenThisMethodGetsCalled] 
    public int omg(string lol) { 
     //fancy logic in here 
    } 
} 

mi piacerebbe testare la logica nel metodo OMG(), ma nei test di unità che ho bisogno di fare in modo che l'aspetto non viene chiamato, perché ci non è davvero un database.

Pensieri?

Answer 1

Probabilmente è possibile utilizzare l'iniezione di dipendenza e introdurre una proprietà statica per la classe di aspetto in cui si decide quale tipo di provider di accesso al database verrà utilizzato (ad esempio utilizzando una fabbrica), impostando quello falso nell'ambito di un test.

Answer 2

La mia opinione è che dovresti testare il codice come se l'aspetto fosse codificato manualmente - cioè testare la piena funzionalità del metodo, incluse le funzionalità implementate dall'aspetto.

la questione è ora documentato nella documentazione in linea PostSharp a http://doc.postsharp.net/postsharp-3.0/Content.aspx/PostSharp-3.0.chm/html/2ad6cf92-08eb-4537-a434-d88a3e493721.htm

Answer 3

non sono d'accordo con Gael. Ho imparato da un amico che devo testare il codice che scriverò e, in generale, solo una volta.

Answer 4

Non sono del tutto sicuro di come funziona postsharp, ma come capisco al momento, si invoca un processo di post-build per tessere gli aspetti nell'IL.

Se la mia comprensione è corretta e se si può saltare la tessitura post-build, si dovrebbe testare il metodo ignorando l'aspetto (e testando l'aspetto separatamente altrove).

Perché?

Se si prova l'aspetto e il metodo, si sta testando 3 cose in una volta:

1. il metodo
2. l'aspetto
3. la tessitura dell'aspetto nel codice

Questo è un cattivo karma e può portarti giù nella tana del coniglio se qualcosa va storto (così come fare il test dell'unità in un test di integrazione).

Guardando la lista di cui sopra:

• si fare necessità di prova il metodo, in isolamento senza altre distrazioni come questo vi permetterà di concentrarsi sul assicurandosi che il metodo non esattamente quello che ti aspetti - né più né meno.
• si non necessità di prova l'aspetto ogni volta viene utilizzato, solo testare una volta e assicurarsi che non quello che pensi lo fa
• si non lo fai necessario per verificare che la tessitura funzioni; è (dovrebbe essere) testato come parte dell'implementazione post-sharp.

Answer 5

Per disattivare gli aspetti relativi al database nel mio codice, ho introdotto una classe statica denominata TestingEnvironment con una proprietà booleana denominata TurnOffAspects. Il codice in aspetto controlla questa proprietà e se è impostata su "true", l'aspetto ritorna senza fare nulla. Durante l'installazione di prova, ho impostato la proprietà TestingEnvironment.TurnOffAspects su true e, durante il test teardown, su false. Naturalmente puoi rendere le cose più granulari introducendo una proprietà per ogni aspetto che hai. Dovresti scegliere con molta attenzione quali aspetti disattivare, dal momento che può avere un grande impatto sul tuo test e far fallire il tuo codice di produzione anche quando il test passa.

Answer 6

Se si desidera scrivere un puro test UNIT, prendere in considerazione la disattivazione di PostSharp per il modulo durante i test di UNIT TESTING impostando il simbolo di compilazione "SkipPostSharp" nel progetto o impostare la proprietà MSBuild "SkipPostSharp = True".

Se sei felice di fare integrazione di test, è possibile verificare la piena funzionalità del tuo metodo e attributo PostSharp, compreso l'accesso DB (come suggested by Gael).

Answer 7

Il mio approccio attuale prevede l'esecuzione dei test come parte del processo di compilazione sul nostro TFS. Questo potrebbe non essere utile per tutti gli scenari, ma ho passato un po 'di tempo a trovare una soluzione che mi permettesse di eseguire i test unitari della nostra logica aziendale senza alcun impatto di PostSharp.

Ho creato due diverse definizioni di build, una delle quali ha gli argomenti di MSBuild impostati su /p:SkipPostSharp=True (questo è quello che esegue i test di unità) e l'altro su False rispettivamente. In aggiunta, ho impostato l'opzione Disable Tests su True per la definizione di build utilizzando PostSharp.

So che questo non è l'ideale (soprattutto perché ora ho il problema di non essere in grado di eseguire i test localmente senza alcuna modifica), ma non ho potuto trovare alcun altro modo per aggirarlo. Sembra che non ci siano troppe persone con gli stessi problemi. Dato che sono un novizio assoluto in termini di MSBuild e della sua configurazione, forse qualcuno con una conoscenza migliore potrebbe aiutare.

Ho anche giocato con lo Configuration Manager in Visual Studio per creare un'altra definizione di build, ma tutti i miei tentativi hanno prodotto solo più problemi di qualsiasi altra cosa.