[unitTest c#] creare evento per messagebox che appare

venerdì 12 aprile 2013 - 17.06

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags C# | .NET 4.0

Amodio Profilo | Expert

525 messaggi | Data Invio: ven 12 apr 2013 - 17:06

salve a tutti
sto creando un progetto unitTest con Visual studio 2012 e c#
il problema che ho è che durante l'esecuzione del test
potrebbero apparire determinati messaggi (messageBox)
come posso gestirli?
è possibile creare eventi? se si, come?
non trovo niente nella documentazione (molto scarsa)

questo è un piccolo codice generato per l'assert del messaggio
ne dovrei fare un event...COME?

 Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

0v3rCl0ck Profilo | Guru

1.120 messaggi | Data Invio: dom 14 apr 2013 - 17:07

se stai testando l'interfaccia grafica, con visual studio 2012 ti consiglio ti guardarti i Coded UI Tests che hanno fatto considerevoli passi in avanti in fatto di semplicità e manutenibilità di UI tests:

http://msdn.microsoft.com/it-it/library/dd286726.aspx

e un video carino (però in inglese):

http://channel9.msdn.com/Events/TechEd/Europe/2012/DEV312

è importante aprire una parentesi dicendo che i test direttamente sulle interfacce utente, sono solo l'ultimo approccio che si dovrebbe seguire, o meglio sono parte integrante di un processo ben più completo di test, con questo voglio solo dirti che anche se ora le coded ui tests sembrano una vera ficata perchè rapide e manutenibili, non sostituiranno mai delle buone unit e integration tests, dove le prime servono a coprire test su singole parti di calcolo business, classe per classe per intenderci, dove una classe risolve solo un problema/obiettivo (e dove spesso si usano i famigerati Mock object sfruttando l'inversion of control IoC), mentre gli integration test per testare più classi dipendenti tra loro, esempio pratico, si ha una classe che controlla i dati di input ed effettua eventuali calcoli che ha dipendenza sulla classe di accesso al database che prende i dati calcolati e li salva, nel caso della unit test la classe BLL (business) avrà il suo test facendosi iniettare una classe "finta" (Mock) per la parte di accesso ai dati di fatto escludendola dal test, e poi la classe DAL (accesso dati) avrà a sua volta anche il suo test isolato (appunto unit test); nel caso invece dell'integration test, si avranno test direttamente sul BLL passando l'implementazione reale del DAL, testando che le due implementazioni comunichino correttamente tra di loro senza problemi. Questa immagine può darti un idea (la ritrovi anche nel link sopra):

675x322 13Kb

Attenzione perchè oltre ai metodi rappresentati dall'immagine, ce ne sono tanti altri, come quello di testare in maniera isolta solo parti di biz logic (unit tests), oppure testare solo parti di biz logic legata all'interfaccia utente, ma slegati dalla vera e propria interfaccia utente, e sono sempre unit tests, però legati alle logiche che stanno dietro ad un controllo oppure al popolamento dei dati, evitando di mettere in gioco l'interfaccia, per fare questo si deve adottare un pattern tipo MVVM (Model-View-ViewModel), dove le parti di elaborazione dell'interfaccia vengono racchiuse in una classe denominata ViewModel, che non ha minima conoscenza dell'interfaccia, ma che lavora solo con modelli di dominio o altri ViewModel, per generare i dati pronti per l'interfaccia, agire su comandi utente, e con l'aiuto di un framework di binding (WPF) il tutto è collegato all'interfaccia che mostra i dati e comunica con il ViewModel, e dato che uno strumento come le coded ui tests di microsoft, sono sempre state difficili da sviluppare, una delle tecniche più diffuse per testare la UI è proprio quello di testare le logiche che stanno dietro all'interfaccia, anche perchè sostanzialmente sono quelle che scrive lo sviluppatore e dove potrebbero esserci problemi, mentre l'interfaccia in se dovrebbe essere garantita da microsoft, ad eccezione di controlli completamente custom, che appunto a loro volta andrebbero testati prima di utilizzarli.

Detto questo le coded ui test credo siano un ottimo strumento che arricchisce ancora di più i test di una applicazione, ma a volte si può anche essere spinti ad avere solo quelli perchè veloci, ma questi tipi di test difficilmente metteranno in sicurezza l'applicazione da bug di regressione o alterazioni profonde del codice di business, dove codice scritto a più mani potrebbe mutare anche le specifiche più profonde senza che l'interfaccia necessariamente ne venga afflitta. Dipende dalle proporzioni dell'applicazione.

Ciao!

-------------------------------------------------------
Michael Denny
Lead Software Developer & Solutions Architect
http://blogs.dotnethell.it/Regulator/

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !