[*] Librerie per "testing" con i linguaggi C++ e C#

[giuseppe500]

esistono delle librerie per i 2 linguaggi sopracitati(il visual c++ mfc e il c# tutti facenti parte del visual studio 2003)per effettuare il testing dei programmi?
ho letto che esistono liberie del genere ad es per php(articolo nella home page di html.it).
grazie.
ciao

[andbin]

Originariamente inviato da giuseppe500
esistono delle librerie per i 2 linguaggi sopracitati(il visual c++ mfc e il c# tutti facenti parte del visual studio 2003)per effettuare il testing dei programmi?
ho letto che esistono liberie del genere ad es per php(articolo nella home page di html.it).
grazie.

Per C# so che esiste NUnit.
Per C++ c'è CppUnit.

Questi sw non li conosco comunque e sicuramente non sono gli unici.

[giuseppe500]

grazie mille.
Solo che sono di nuovo al punto di partenza , non riesco a capire precisamente come funzionino, cosa fanno e cosa devo aggiungere al mio codice per farli funzionare.
soprattutto cosa aggiungere al codice e che filosofia ci sta dietro.
purtroppo le guide sono in inglese e non ho capito tutto.
grazie.

[andbin]

Originariamente inviato da giuseppe500
Solo che sono di nuovo al punto di partenza , non riesco a capire precisamente come funzionino, cosa fanno e cosa devo aggiungere al mio codice per farli funzionare.
soprattutto cosa aggiungere al codice e che filosofia ci sta dietro.

La filosofia è abbastanza semplice, come concetto, ed è più o meno comune a tutti questi framework di test (parlo di JUnit per Java, NUnit per C#, ecc...).

Innanzitutto questi framework consentono di scrivere dei test, chiamati "test case". L'obiettivo di questi test case è quello di effettuare dei test sui possibili casi di utilizzo di certe funzionalità di un codice.

Esempio: hai fatto una piccola libreria in cui c'è un metodo che data una stringa in input la restituisce rovesciata al contrario. Come testi se il metodo funziona correttamente e come ci si aspetta? Bene, tramite questi framework, puoi creare una apposita classe di test, in cui scriverai dei metodi dove, per ognuno, verificherai tutti (o quasi) i possibili casi di utilizzo del metodo. Ad esempio testare se data una stringa "abc" la rovescia correttamente in "cba" e magari anche un altro caso con un numero di lettere pari. E magari un altro caso ancora che verifica che se passando al metodo un null, lancia effettivamente una eccezione come ci si aspetta.

In genere, specialmente per Java e C#, questi framework si basano sulle annotazioni/metadati. Le classi e i metodi di test sono definiti con nomi specifici e/o con metadati particolari affinché l'applicazione di test fornita con il framework possa eseguire i test e segnalare quali test case hanno avuto successo e quali sono falliti.

Il succo è questo. Il Quick Start qui di NUnit mi sembra molto chiaro, ti consiglio di leggerlo se non l'hai già fatto.

Originariamente inviato da giuseppe500
purtroppo le guide sono in inglese e non ho capito tutto.

Nel campo dell'informatica l'inglese è praticamente obbligatorio ....

[billiejoex]

A quanto detto da andbin aggiungo solo una cosa (devo :-)): un qualunque progetto che sia qualcosa di più di un semplice script ha bisogno di una test suite. E' sicuramente una delle cose più importanti.
Tempo addietro stavo per fare l'errore di rilasciare un programma senza test suite. Sotto insistente pressione di un altro programmatore mi sono deciso ad aggiungere una test suite (tempo speso per apprendere la libreria apposita: 1 oretta circa) col risultato che dal programma principale sono spuntati fuori bug di cui non mi ero minimamente accorto e di cui non immaginavo neanche lontanamente l'esistenza.

[giuseppe500]

emm..
grazie mille ragazzi ma non capisco fino in fondoerchè con una test suite possono saltare fuori errori che altrimenti testando nel modo normale non apparirebbero?
Voglio dire perchè non testare tutto a mano invece( e qui penso sia il mio fraintendimento)che fare la stessa cosa da codice?
grazie

[giuseppe500]

up

[billiejoex]

emm..
grazie mille ragazzi ma non capisco fino in fondoerchè con una test suite possono saltare fuori errori che altrimenti testando nel modo normale non apparirebbero?
Voglio dire perchè non testare tutto a mano invece( e qui penso sia il mio fraintendimento)che fare la stessa cosa da codice?
grazie

Descrivere i vantaggi di usare una test suite non è semplice. Provo a fornirtene alcuni (quelli che mi vengono in mente).

Logica: prendiamo l'esempio più classico: una funzione. Testare una funzione "manualmente" significa leggere il codice dall'alto verso il basso e capirne la logica, assicurandosi che quello che è stato scritto sia effettivamente corretto. La difficoltà di intraprendere questo tipo di controllo è direttamente proporzionale alla complessità e alla lunghezza della funzione ed è molto facile che alcuni tipi di errori sfuggano all'occhio umano (provato sulla mia pelle). Con una test suite utilizzi un approccio profondamente diverso: non vai più ad indagare sulla logica interna della funzione ma su quello che tu ti aspetti che essa ritorni e/o sulle eccezioni / errori che ti aspetti che essa sollevi se in input vengono forniti determinati parametri.
Sebbene quest'ultimo possa apparire un po' fuorviante in quanto il concetto di "errore" o "eccezione" è un qualcosa di tipicamente negativo e da evitare, all'interno della test suite esso è perfettamente legittimo in quanto tu stesso crei delle casistiche che lo sollecitano espressamente.
Esempio da due soldi: su una funzione che somma due numeri:

def somma(a, b):
    return a + b

...puoi andare a testare le seguenti casistiche:

# che chiamando la funzione usando come agomenti 2 e 3 sia effettivamente ritornato 5.
# che un intero sommato ad una stringa (2 + '3') ritorni effettivamente un errore di "tipizzazione" (non puoi mischiare interi e stringhe).

In questo esempio particolare utilizzare una test suite non sarebbe conveniente in quanto la logica della funzione è troppo semplice, ma più le funzioni sono complesse, lunghe e numerose, più è conveniente adottarla.


Manutenibilità: la crescita di un software include migliorie, bug fixing, varie modifiche strutturali al codice e ovviamente il versionamento. Tipicamente le funzioni "cardine" di un programma subiscono spesso modifiche al loro interno (es: correzione di bug) ma quello che tu ti aspetti da loro rimane bene o male sempre le stesso (nel dettaglio: cosa ritornano e in quali casi sollevano errori/eccezioni).
Il vantaggio in questo caso consiste nell'avere una suite che sarà ragionevolmente valida per tutte le versioni future.
Tipicamente la test suite che scrivi per la prima versione del tuo software resta bene o male invariata (o cmq strutturalmente molto simile) e valida per tutte le versioni a venire, ovviamente escludendo le parti aggiuntive al codice per le quali dovrai aggiungere casistiche alla struttura originale della test suite.


Qualità: un SW fornito di test suite è indice del fatto che "tu l'hai testato". Scaricare un progetto open source, specialmente se una libreria "da programmatore per programmatore" e vederlo corredato di test suite è sicuramente una sicurezza aggiuntiva per l'utilizzatore.


Portabilità: la test suite può essere provata da altre persone su sistemi operativi e piattaforme differenti dalle tue. Distribuendo un programma open source corredato di test suite dai ad altre persone la posisbilità di testare "on the fly" il corretto funzionamento del tuo software sul loro sistema e notificarti eventualmente bug nel caso in cui uno o più test falliscano.


Versatilità: Il più grande vantaggio: la test suite la scrivi "una volta per tutte" e "una volta per tutti". Immagina che per il tuo software intendi testare 40 casistiche di comportamento ("la funzione x ritorna y?" ecc...) e che le stesse le intendi provare su 3 sistemi operativi differenti (es: linux, windows, osx) e 3 piattaforme differenti (es: Java 1.4, Java 1.5, Java 1.6) per testare la portabilità del tuo software. Non utilizzando una test suite dovresti compiere la bellezza di 360 test a mano:

40 * (Java 1.4, Java 1.5, Java 1.6) = 120
120 * (Linux + Windows + OSx) = 360

Con una test suite il tutto si ridurrebbe a lanciare un solo script 9 volte:

1 * (Java 1.4, Java 1.5, Java 1.6) = 3
3 * (Linux + Windows + OSx) = 9

...in un tempo ovviamente di molto minore e sopratutto in maniera affidabile. Il computer non sbaglia: quello che hai scritto la test suite fa. A te dopo la 30 esima casistica di test verificata 'a mano' incominciano ad incrociarsi gli occhi.

[or_alberto]

Ciao a tutti io voglio imparare il linguaggio C pero voglio cominciare da 0
come posso iniziare con che programma che guide?

iniziare da zero e avere un buon risultato al 100%

[LeleFT]

Originariamente inviato da or_alberto
Ciao a tutti io voglio imparare il linguaggio C pero voglio cominciare da 0
come posso iniziare con che programma che guide?

iniziare da zero e avere un buon risultato al 100%

Questo non ha nulla a che fare con la natura della discussione in corso.
Puoi aprire tu stesso una nuova discussione con l'argomento che intendi trattare.
In questo caso, però, dato che l'argomento è già stato trattato più e più volte ti consiglio di leggerti le Pillole presenti in rilievo sul forum e prendere spunto da quelle. Inoltre effettua una ricerca sul forum per poter visionare le altre discussioni già aperte sull'argomento.


Ciao.