Testing
Questo è un post di test, non consideratelo. :)
Personalmente non posso vivere senza fiddler, ed un’altra prova della potenza di questo tool la trovate qui, nel blog dell’Ace Team, in cui viene mostrato come fiddler possa anche registrare il traffico producendo poi un bel Web Test che potete includere in visual studio. Il processo è un po macchinoso, ma in alcune situazioni può pagare decisamente la fatica spesa. alk. Tags: Testing
Effetturare log estesi delle proprie applicazioni è decisamente conveniente, solo che ogni tanto è necessario andare a controllare il file di log anche se tutto va bene……giusto per capire la dimensione
Su una macchina di produzione stavo per zippare una vecchia versione di un servizio prima di mettere la nuova e ho visto che lo zip richiedeva 3 ore…ho notato che la dimensione della cartella era di più di 4 GB,………. Mi debbo segnare quindi come promemoria di controllare ogni tanto il file di log dei miei applicativi :D
Alk.
Giovedi mentre tornavo da Luserna, nell'ultimo tratto di treno non ho resistito a tenere il portatile chiuso ed ho un po esteso quello che avevo iniziato in un precedente post. L'argomento è quello di fare test con interfacce fluenti, ed un post di adrian il giorno dopo cade a fagiolo. In sostanza le interfacce fluenti permettono di scrivere codice che è sicuramente più chiaro e quindi più semplice da mantenere, meno error prone e cosi via. In una mezzoretta di treno regionale sballottante ho preso il progetto relativo al post precedente, ed ho modificato un paio di cose per permettere...
Molto spesso nei test si deve verificare se una collezione di entity contiene un oggetto con una proprietà di un dato valore, in questo caso non si può utilizzare il classico Contains della collection ma nunit ci viene in aiuto fornendo alcuni syntax helper interessanti. Considerate una classe chiamata AnEntity con due proprietà di tipo stringa, chiamate rispettivamente PropertyA e PropertyB, ecco un test interessante
[Test]
public void AnotherCollectionTest() {
List<AnEntity> al = new List<AnEntity>();
al.Add(new AnEntity("A", "B"));
al.Add(new AnEntity("C", "B"));
al.Add(new AnEntity("A", "B"));
Assert.That(al, Has.All.Property("PropertyB", "B"));
Assert.That(al, Has.Some.Property("PropertyA", "C"));
Assert.That(al, Has.None.Property("PropertyB", "KK"));
}
Come potete vedere ho una lista tipizzata, ci metto dentro tre entità e poi faccio tre test. Il primo verifica che tutti gli oggetti abbiano la proprietà PropertyB pari a B, il secondo controlla...
Stasera mi faccio un giro su www.nunit.org, controllo e dico…ancora siamo alla versione 2.4.3….ma è una vita che non aggiornano..poi ale che è a due passi da me fa, ma io nel sito vedo la 2.4.5….????? morale della favola, su www.nunit.org il sito non è più aggiornato per cui andate su www.nunit.com , solo che in questo sito purtroppo i link sono tutti down per ora e non mi fa scaricare nulla sigh.
Alk.
Ricordo che al TechEd si parlava proprio con Mauro di questo problema. Non sono un fanatico del TDD e lo utilizzo raramente, però sono un accanito sostenitore dei test, senza fare fondamentalismo, talvolta scrivo i test prima, talvolta invece li scrivo dopo, non testo tutto ma cerco di creare una batteria di test che sia in grado di verificare le parti più delicate del codice. In generale mi piace avere un supporto di test quando faccio re factoring.
Talvolta, soprattutto per le strutture MVC in cui ho interfacce complicate, i test iniziano perl a diventare decisamente complessi, con forte uso di...
Il test double, è una tecnica utilissima per aumentare la "testabilità" del codice, ma come fare per usare questa tecnica in maniera efficiente. Un pattern che uso costantemente è quello dell'override per le istanze singleton. Faccio un esempio. Se in un progetto ho un DAL molto standard che usa un Dao per tabella (un table module) gli oggetti Dao sono solitamente senza stato, per questa ragione utilizzo il pattern Registry in cui tengo le istanze singleton dei miei Dao. (Questo quando non posso usare Nhibernate :P). In sostanza ovunque il codice necessiti di un dao non fa altro che chiamare...
Nella scrittura di unit test una delle cose più importanti è l'assoluta indipendenza dei test, un test non deve essere influenzato dal risultato di altri test. Particolarmente importante è quindi l'esecuzione di una serie di operazioni, che vanno sotto il nome di fixture teardown, necessarie per riportare lo stato di ogni parte di una shared fixture allo stato iniziale. Si consideri questo banale esempio
Queste due banali classi rappresentano il concetto generico di classi che hanno internamente una shared fixture. In un caso reale chiamando il metodo AddSomething della classe SomeClass si modificano alcune parti del sistema...
I progetti costruiti con TDD oppure pensati per il "design for testabiliy" sono creati e pensati per essere "testati" con facilità, purtroppo così non è per i sistemi legacy. Quando si mette mano ad un sistema preesistente per rifattorizzarlo è di primaria necessità costuire una batteria di test i più dettagliati possibile, ma spesso si incontrano difficoltà. Un caso tipico è una funzione di questo tipo:
In questo caso il SUT (System Under Test) esegue codice in base ad un settaggio che è memorizzato su un database. Questa tipologia di codice è molto comune e rende difficile effettuare il test, soprattutto...
Uno dei problemi maggiori che si incontra nello unit testing di codice già esistente e non scritto secondo I principi del "design for testability" è l'impossibilità di verifcare lo stato interno di un oggetto. Talvolta infatti per verificare che un test è andato a buon fine è necessario andare a verificare il valore di una variabile privata del SUT (System Under Test), ma naturalmente questo non è possibile farlo dal test. Questa necessità emerge più spesso del previsto, ad esempio se il SUT è un oggetto a stati ed il chiamante non ha necessità di conoscere lo stato corrente, è...