i just need to know what is the objective of Unit Testing.

Per assicurarti che il tuo codice funzioni dopo le modifiche.

what kind of result we expect from unit testing.

La tua mente sarà cambiata. Penserai a come testare il codice prima di crearlo, in modo che il codice diventi più efficiente.

code quality is checked by unit testing?

No. La qualità del codice non può essere misurata o verificata con il test dell'unità. La qualità del codice può essere migliorata tramite la revisione del codice.

unit testing is the job of developer of tester.

Entrambi. Di solito il tester crea test di integrazione (test black-box), lo sviluppatore crea entrambi (test white-box e black-box).

do i need to maintain a separate copy of the same project for unit testing?

Dovresti avere una copia separata del progetto per ogni sviluppatore (spero, ce l'hai?). Lo sviluppatore dovrebbe eseguire i test unitari prima di eseguire il commit nel repository. E il sistema di test di integrazione dovrebbe prendere le modifiche nella propria copia ed eseguire i test - il risultato mostrerà se tutti gli sviluppatori eseguono i test prima di impegnarsi.

I test unitari hanno diversi scopi correlati:

• Verifica che i requisiti siano soddisfatti;
• Sviluppa specifiche più precise per il codice;
• Prova le unità funzionali isolate;
• Rendi più semplice il test di regressione (ad esempio, assicurati di non interrompere il codice di lavoro).

Verifica che i requisiti siano soddisfatti

Ad esempio, sto lavorando su un codice per visualizzare la cronologia delle transazioni per un conto bancario. Ho il requisito che se ottengo un record di cronologia in cui commissioni, depositi o importi di interessi sono maggiori di 0, li suddivido in voci separate con i loro codici e descrizioni delle transazioni. Un metodo in una classe ne è responsabile, quindi scrivo codice che chiama direttamente quel metodo (o, se quel particolare metodo non è pubblicamente visibile, chiamo il metodo che chiama il metodo in prova) con input noti per ogni caso, quindi controllare i risultati per ciascuno di questi input per verificare che siano state create le sub-transazioni corrette, con i dati corretti.

Sviluppa specifiche più precise per il codice

Mentre sviluppi i tuoi test unitari, troverai inevitabilmente che i requisiti non coprono tutti i casi possibili. Ad esempio, ho un altro requisito che dice se il codice della transazione è X, fai una cosa, e se è Y, fai qualcos'altro. Ma non c'è nulla che mi dica cosa fare se il codice della transazione non è né X né Y. È un buco nelle specifiche che devono essere riempite, in questo caso dall'architetto. È un buon modo per controllare il tuo lavoro.

In un certo senso, il test unitario diventa la specifica per il codice.

Verifica unità funzionali isolate

Questo è un grosso problema. Il test unitario ti consente di testare il tuo codice mentre lo stai scrivendo ; non devi aspettare fino a quando tutti i pezzi sono a posto prima che il test possa iniziare. Se stai testando una parte di codice che si basa su un'altra classe o metodo, puoi scrivere un'implementazione fittizia di quella classe o metodo che restituisce valori noti o si comporta in modo noto, in modo da poter testare scenari specifici.

Ti incoraggia anche a considerare il tuo codice in modo più aggressivo, riducendo le dipendenze tra i componenti, il che rende il codice più facile da mantenere ed estendere.

Semplifica i test di regressione

Lo scenario da incubo sta rilasciando una patch che rompe il codice funzionante. Eseguendo i test unitari come parte di ogni build, si protegge da rotture accidentali perché il test associato fallirà. È quindi possibile analizzare l'errore e vedere se l'interruzione è reale (ad esempio, qualcuno codificato in un bug) o se il requisito / specifica è cambiato e regolare di conseguenza il test dell'unità.

L'obiettivo di UnitTesting è semplice - ridurre i costi di scrittura e supporto di un'applicazione. È di altissimo livello. Per lo sviluppatore ce ne sono altri come: scrivere codice migliore, risparmiare tempo sul debug, manutenzione più semplice, crescita professionale dopo tutto.

UnitTesting è lavoro per sviluppatori completamente, e sì è necessario mantenere un progetto addizionale con test, ma vale la pena. (questa non sarà una copia del tuo progetto btw)

Test unità è divertente. È divertente scrivere ed eseguire test. Non capirai fino a quando non ci proverai.

Test unitario è un modo completamente diverso di scrivere codice e lavorare con il codice base. Dovresti capire anche questo e tutti i membri del tuo team. Avrai bisogno di eseguire test spesso, configurazione CI, sentirsi felice.

Test unità è avere un buon tooling e una grande comunità, quindi iniziare a scrivere i tet non sarà molto difficile.

Quando hai Test unità non puoi dire che il progetto è brillante e tutto è ottimo, ma quando dopo ti coinvolgi in un progetto senza test inizi a capirne tutta l'importanza.

I test unitari assicurano che il contratto funzionale di ogni "unità" non venga modificato. Ecco un esempio:

For input "A", method X produces result "B"

I test unitari assicurano che, anche dopo molte modifiche al codice (correzioni di errori, nuove funzionalità), il metodo X produce ancora il risultato "B" quando viene dato l'input "A". Se tutte le funzioni del tuo sistema vengono convalidate in questo modo, la possibilità di creare bug o di rompere accidentalmente la funzionalità è molto più bassa.

È prassi comune creare un MyProj.csproj e un MyProj.Test.csproj , dove il progetto Test contiene una serie di test per ciascun contratto in MyProj.

Tipicamente dovrebbe esserci un test unitario per ogni ramo condizionale / logico all'interno della funzione in fase di test.

Abbiamo fatto un buon uso dei test unitari in alcuni dei progetti su cui sto lavorando. Non sono un ragazzo TDD in alcun modo, quindi quello che tendo a fare è scrivere test unitari dopo aver scritto il codice e verificare che il comportamento sia come previsto.

Quando viene rilevato un bug, viene scritto un test unitario per verificare che non riappaia.

Quindi integriamo i test unitari nel nostro server di integrazione continua (TFS 2010) in modo che ad ogni verifica del codice, tutti i test unitari vengano eseguiti se qualcosa da qualche altra parte nel codice base interrompe un test unitario, quindi tutti sappiamo e possiamo correggerlo prima del rilascio.

Avere un approccio disciplinato ai test unitari finisce anche per cambiare il modo in cui si codifica. Si tende a scrivere un codice progettato più coeso e liberamente accoppiato, perché è questo che facilita i test unitari. Come per prodotto, la qualità del codice è migliorata. Tecniche architettoniche come il DI / IOC facilitano le prove di unità.

Con il test delle unità, si desidera che il test sia totalmente prevedibile e non abbia dipendenze sull'ambiente come database ecc. Ciò significa che si utilizzano elementi come mock e stubbs per fornire tali servizi esterni.

I test di scrittura possono essere abbastanza complessi, in particolare quando si prendono in giro i componenti del sistema. IMHO è un lavoro per gli sviluppatori, perché è una programmazione e inoltre non dovrebbero riportare la logica del codice in primo piano. Il runnning del test, come ho detto prima, è il lavoro dell'agente di test come Visual Studio manualmente o TFS.

Ogni "unità" ha un contratto implicito: grosso modo, "se fornisci questi input, ti darò questi risultati". I test unitari servono a dimostrare che il contratto è stato rispettato, e avvisano quando è stato rotto.

Sono utili se li scrivi prima (tdd) in quanto sai che hai finito quando passano tutti i test (supponendo che tutti i test siano una rappresentazione corretta del contratto). Dopo che il codice è stato scritto, i test unitari ti diranno quando una modifica interrompe il contratto.

Ad esempio, diciamo che hai una funzione che converte una stringa in maiuscolo. I test unitari devono dimostrare che, data una stringa, fa esattamente questo. Successivamente, qualcuno passa in una stringa unicode e la tua funzione fallisce. Ciò significa che gli input unicode non facevano parte del contratto, quindi devi aggiungere una nuova funzione, oppure era parte del contratto e il test ti sta dicendo che il codice ha un bug e non è onorare il contratto

Non solo ottieni i benefici del rilevamento dei bug, ma l'atto stesso di scrivere i test unitari ti aiuta a comprendere appieno ciò che il tuo codice dovrebbe fare. Ti fa pensare a casi limite, a quali input sono richiesti e quali risultati sono previsti.

Come evitare le regressioni

(dovevo dichiararlo a voce alta e chiaro)

Le regressioni sono così incredibilmente rilevanti è incredibile la maggior parte delle scuole non si preoccupano nemmeno di menzionarle.

Qui, leggi l'articolo di Wikipedia su Test di regressione . È un'introduzione strutturata all'argomento ed evidenzia i test Unità e Funzionali . (una distinzione che molti tutorial ignorano, ma poi, i test funzionali, di solito non hanno bisogno di framework o di zucchero di sintassi)

Le regressioni nel codice ovviamente non vanno via magicamente con i test, ma i poteri combinati di VCS e Unit Testing aiutano a prenderli in anticipo e ad agire su di loro con furia vichinga.