Test di unità di Visual Studio di Windows Form

Question

Stiamo lavorando a un progetto qui in Visual Studio 2008. Stiamo utilizzando la suite di test integrata fornita con esso (lo spazio dei nomi Microsoft.VisualStudio.TestTools.UnitTesting). Si scopre che con nostro grande dispiacere, una grande complessità (e quindi errori) si è conclusa codificata nel nostro livello di interfaccia utente. Mentre i nostri test unitari svolgono un lavoro decente nel coprire il nostro livello aziendale, il nostro livello UI è una costante fonte di irritazione. Vorremmo idealmente testare anche questo. Qualcuno sa di un buon " compatibile con Microsoft " modo di farlo in Visual Studio? Introdurrà una sorta di conflitto per "mescolare" framework di unit test come nUnitForms con le cose Microsoft? Ci sono delle ovvie trappole per orsi di cui dovrei essere a conoscenza con i moduli di unit test?

Answer 1

Dovresti refactificare l'interfaccia utente in modo che l'interfaccia utente non necessiti di test unitari. L'interfaccia utente deve contenere una logica aziendale minima o assente. Esistono molti modelli che affrontano questo problema. Martin Fowler ha un ottimo articolo che spiega molto su questi schemi: http://martinfowler.com/eaaDev/ uiArchs.html

C'è un piccolo capitolo nel libro Refactoring di Martin Fowler che parla del refactoring dell'interfaccia utente non testabile. Puoi anche leggere Lavorare in modo efficace con il codice legacy.

Nota: esistono strumenti che potrebbero essere utilizzati per automatizzare il test dell'interfaccia utente. SilkTest mi viene in mente. Ma non li userei se possibile.

Answer 2

Questo va bene per i test periodici delle unità applicative ... ma se si stanno creando controlli utente che richiedono test unitari per i comportamenti e gli stati di controllo, è necessario anche un framework di unit test. NUnitForms potrebbe essere la risposta per te - personalmente devo verificarlo da solo.

Answer 3

Uso l'architettura Vista passiva come dettagliato qui http://martinfowler.com/eaaDev/PassiveScreen. html

Fondamentalmente sposta tutto il tuo codice nei moduli in una classe separata chiamata xxxUI. Il modulo implementa quindi un'interfaccia IxxxUI ed espone tutto ciò di cui ha bisogno la classe xxxUI. Probabilmente puoi semplificare le cose e aggregare la gestione di diversi controlli in un unico metodo.

Il flusso va quindi L'UTENTE fa clic su un pulsante. Il pulsante chiama un metodo sulla classe UI corrispondente. Passando tutti i parametri necessari. Il metodo Classe UI modifica il modello. Quindi l'utilizzo dell'interfaccia aggiorna l'interfaccia utente.

Per i test unitari sono disponibili classi di test o fittizie che implementano le interfacce e si registrano con le classi UI. Puoi fare in modo che queste classi di test generino qualsiasi tipo di input e rispondano di conseguenza. In genere ho elenchi di sequenze che fanno le cose in un ordine preciso. (Tocca A, fai clic su questo, scorri quello, quindi digita B, ecc.).

Answer 4

È abbastanza facile testare Winforms con ApprovalTests (www.approvaltests.com o test di approvazione nuget) e sono compatibili con MsTest e Nunit.

C'è un video qui su come farlo: https://www.youtube.com/ watch? v = hKeKBjoSfJ8

Ma il processo è semplice. 1) crea il modulo che desideri testare nello stato in cui desideri verificarlo. 2) chiama WinFormApprovals.Verify (modulo)

ApprovalTests utilizza il paradigma del golden master per catturare lo schermo del risultato. se ti piace semplicemente rinominare il file in .approved e il test passerà.

Il bello di questo per il refactoring del codice esistente è che non devi nemmeno preoccuparti di quale sia il risultato, dal momento che sei solo preoccupato di non cambiarlo.

Answer 5

Dai un'occhiata al WIP di Jeremy D. Miller Pagina wiki dei pattern di presentazione per ispirazione di refactoring: )

Miller sta scrivendo un libro e sembra che sarà un must per questo genere di cose.

Answer 6

Ho usato NUnitForms per testare i miei controlli UI con buoni risultati! Concordo con gli altri sul refactoring se si utilizzano controlli UI standard (o ben testati).

Se l'obiettivo è testare i controlli effettivi, utilizzare NUnitForms in quanto può essere esteso per supportare i nuovi controlli. Ad ogni modo, se non devi coinvolgere alcun test manuale, avrai bisogno di una libreria in grado di eseguire "basato su immagini" analisi del risultato finale visualizzato.

Ho provato TestComplete per questo, ma ho pensato che fosse un po 'troppo costoso poiché potevo codificare una lib simile per il solo confronto delle immagini in c #. Quindi il mio piano sarebbe quello di testare i controlli separatamente e quindi refactoring dell'interfaccia utente come menzionato negli altri.

Answer 7

Dovresti usare l'interfaccia utente codificata Microsoft per testare il livello dell'interfaccia utente. Ciò comporta la scrittura (o la registrazione) di test che imitano le azioni che un utente eseguirà e la scrittura di dichiarazioni di asserzione per garantire il raggiungimento dell'output corretto.

Ovviamente, questo non è discutibile per i test unitari, poiché è difficile creare azioni dal front-end che testano una singola unità di lavoro e non sostituiscono altri test unitari. Concordo anche sul fatto che la logica aziendale del front-end dovrebbe essere la più sottile possibile. Tuttavia, ciò colmerà eventuali lacune in cui i test unitari non coprono. Si spera che solo le piccole unità di lavoro non saranno coperte dai test delle unità, in modo che i test codificati dell'interfaccia utente cattureranno le unità non testate rimanenti.

L'interfaccia utente codificata è integrata con le ultime versioni di Visual Studio Premium. Ti suggerisco di non solo utilizzare la funzionalità di registrazione, ma di imparare a scrivere tu stesso i test in quanto ciò ti dà maggiore flessibilità.