Testing

TestMethod per metodi privati?

Visual Studio Team Test, ed alcune altre SKU, propone un'interessante feature: genera l'accessor per poter testare anche metodi privati. Il codice generato usa sostanzialmente reflection. Dal mio punto di vista, questa feaure e' sostanzialmente dannosa se usata abitudinariamente. I metodi e le proprieta' da testare sono internal e public, punto! Se testando questi non si arriva mai a testare il metodo privato (vedasi code coverage), vuol dire che quel codice non serve a niente e va eliminato. Meno codice inutile piu' facile manutenzione! Come in tutte le cose di buon senso ci sono dei casi particolari, come ad esempio testare l'interfaccia (non...

posted @ mercoledì 19 marzo 2008 05:50 | Feedback (5)

TDD

Alcuni lo chiamano Test Driven Development, altri Test Driven Design, eppure la differenza e' sostanziale. Nel caso di Test Driven Development il codice di test e' inteso come strumento di validazione. Viceversa nel caso di Test Driven Design il codice di test e' inteso come strumento di analisi. Quindi si passa da due concetti radicalmente differenti e con obiettivi diversi, validazione vs analisi. Quindi, nell'ottica del Test Driven Design possiamo pensare al codice di test come le nostre specifiche tecniche, le quali verranno validate dallo stakeholder e visionate, nonche' approvate, durante la prima code review.

posted @ mercoledì 12 marzo 2008 15:19 | Feedback (13)

DateTime.Now non e' adesso, ma domani!

Sarebbe possibile pensare che DateTime.Now non sia esattamente adesso, ma che so, fra un'ora, domani, ieri, ...? Non sto delirando e non ho bevuto vino (sono tendenzialmente astemio)! L'esigenza di avere un concetto dell'istante corrente di tempo variabile nasce soprattutto per il testing. Molto spesso il nostro domain model e' dipendente dal tempo. Si immagini ad esempio l'orario di partenza di un volo o del treno, l'inizio di un programma televisivo, l'orario di una transazione bancaria, ecc. ecc. Nasce quindi l'esigenza di testare il nostro modello ad oggetti in condizioni di tempo differenti, per verificare se a quella certa data ed ora...

posted @ martedì 22 gennaio 2008 16:34 | Feedback (5)

Testare web services con Visual Studio Team Test

Sin dalle prime versioni di Visual Studio Team System (parlo della beta 1) ho notato una grossa mancanza: un test type dedicato ai web services. Ho sempre pensato (sperato) che prima o poi l'avrebbero introdotto, ma ahimè siamo arrivati all'RTM e niente. Quindi, la mia scelta è caduta sullo Unit testing. Perchè unit testing ? Semplice, la classe proxy (del web service) è una classe che può essere testata come un OM, al pari di qualsiasi class library. Nota: E' importante ricordare che se volete il supporto dei wizard per la generazione automatica dello scheletro delle test classe e test methods dovete...

posted @ giovedì 1 dicembre 2005 08:59 | Feedback (2)

Web Testing extraction rule

Quando si sviluppa un progetto web test in Team System vi è la possibilità di utilizzare le regole di estrazione (extraction rules) le quali permettono di estrarre valori dei messaggi scambiati fra client e server. By default troviamo delle regole preconfezionate, come l'estrazione di un valode nel campo nascosto, piuttosto che un testo e così via. Manca la possibilità di estrarre un parametro dalla query string (in realtà è  fattibile ma un poco laborioso). Ecco allora che mi sono scritto una nuova regola (in C#). Tempo di implementazione circa 30 minuti (senza sapere come si facesse!). Il codice è disponibile...

posted @ giovedì 22 settembre 2005 04:34 | Feedback (547)

Test case per misurare le performance

Un test case è un insieme di condizioni attreverso le quali il tester determina se l'applicazione soddisfa i requisiti oppure no. E' definito da tre elementi, elementi di input, path e risoltato (elementi di output). Normalmente, ogni applicazione deovrebbe avere un insieme test case per tutti gli scenari applicativi che possono avvenire, errori compresi. Nel caso del performance testing non è necessario utilizzare tutti i test case applicativi, in quanto non è in discussione la funzionalità applicativa, bensì la sua resistenza. Allora dovremo sceglere i test case che hanno un uso significativo (almeno oltre il 5%) e quelli dove il...

posted @ lunedì 19 settembre 2005 06:20 | Feedback (1)

Utenti concorrenti - utenti simultanei

Nei test di performance c'è una netta distinzione fra utenti concorrenti ed utenti simultanei. I primi sono quel gruppo di utenti che utilizzano il sito (o l'applicazione o il servizio) nello stesso attimo di tempo. Gli utenti simulntanei sono invece tutti quelli che hanno una connessione attiva (sessione) con l'applicazione. In generale si segue l'equazione Utenti Simultanei  = Utenti Concorrenti * 10 Il numero di utenti concorrenti ha una forte incidenza nello stress test mentre gli utenti simultanei sono importanti per il load test. In Team System è possibile scindere i due scenari azzerando (utenti concorrenti) od incrementando (utenti simultanei) il Think time, come...

posted @ mercoledì 7 settembre 2005 07:12 | Feedback (1)

Performance test

Vi siete mai chiesti, dopo aver sviluppato l'applicazione multi-user (es. web, smart client, ecc.), quanti utenti può reggere la vostra soluzione ? Se un cliente ha 100 utenti quanti server e che tipo di server gli proponete ? E se questi diventano 200 dopo un'anno di attività ? C'è chi usa la logica del pollicione (che però funziona solo per sapere da che parte arriva il vento) e chi invece fa acquistare i server della Nasa...tanto per stare tranquilli. In realtà esiste la possibilità di fare dei test di perfomance. I test di performance sono generalmente di tre tipi (molti ancora...

posted @ martedì 6 settembre 2005 07:43 | Feedback (9)