Con quanto segue andremo ad approfondire il concetto di unit test e, nella fattispecie, del testing tramite il framework free tSQLt, utilizzando t-sql e SQL Server Management Studio.

1. Testing your databases
Effettuare unit testing con SQL Server database e tSQLt

2. Alessandro Alpi
Microsoft MVP – SQL Server dal 2008
Blog ITA: http://blogs.dotnethell.it/suxstellino
Blog ENG: http://suxstellino.wordpress.com/
Website: http://www.alessandroalpi.net
CTO Engage IT Services S.r.l.
www.engageitservices.it
Team leader (Agile)
Communities
Getlatestversion.it

3. Agenda
• Concetti di Unit Testing
• Perché Unit Testing su database
• Unit Testing framework
• Unit Testing solution
• Conclusioni
• Q&A

4. Parleremo di
• Development teams
• Codice e funzionalità
• Evitare e prevenire le regressioni
• Evitare i down e gli stop presso i nostri clienti
• Ridurre i bug
• Perdere il meno tempo possibile
• Migliorare la qualità
• Affinchè non sia solo un’opzione, ma una costante

5. I nostri obbiettivi
• Considerare team di QA
• Un team o una parte di esso che controlla la qualità
• Implementare la retrocompatibilità
• Seguendo pattern di refactor ben definiti
• Coprire con unit test
• Unit test ancor prima dell’implementazione della feature
• Qualità sì, ma con produttività
• Tool e framework “integrati” ed integrabili

6. Concetto di unit test
• In computer programming, unit testing is a software testing
method by which individual units of source code, sets of one
or more computer program modules together with
associated control data, usage procedures, and operating
procedures are tested to determine if they are fit for use. The
primary purpose of this approach is to find out bugs and
prevent regressions.
(source: Wikipedia)

7. Perchè unit test
• Focus sulle attività Mission-critical
• Supporto allo sviluppo evolutivo
• Con continuous improvement
• Prevenzione delle regressioni
• Riduzione del numero di bug
• Riduzione dei costi di sviluppo
• Altrimenti impiegato in fix

8. Best practices
• «Fix bugs as soon as you find them»
• Non rimandare a domani quello che potresti fare oggi
• I bug non risolti camuffano altri potenziali bug
• I bug non risolti indicano che “la qualità è un’opzione”
• Discutere dei bug è una perdita di tempo
• I bug non risolti sono anche un costo in termini di effort

9. Lezioni derivanti
• I bug non risolti viziano le metriche del team e del progetto
• I bug non risolti portano il team ad essere distratto (discussioni)
• I bug non risolti ostacolano i ritmi di release
• I bug, così come per le metriche, viziano le stime preventive
Perciò
• Più il codice è “buono” più è leggibile
• Più il codice segue regole, più è comprensibile
• Più il codice è familiare, più è semplice intervenire
• Scrivere fix il prima possibile costa molto meno che “più avanti”
• Qualità!

10. Cosa facciamo di solito su database
• Esecuzione di codice in ambienti di produzione o estratti di dati
• Test manuale
• T-SQL debug, check su valori variable
• PRINT, PRINT, SELECT…
• Non ripetibile, soggetto ad errori umani
• Alcuni test non sono più validi appena cambia la situazione
• Alcuni test sono fatti su vincoli che bloccano l’operatività del test
stesso, viziando, di fatto, la sessione di test manuale per intero

11. Cosa dovremmo testare
• Calcoli in procedure e funzioni
• Constraints (schema)
• Casi limite di DML e dati
• Comportamenti attesi dalle regole sui dati e dai DLM
• Error Handling
• Security
• Standard (SQLCop)

12. Una soluzione possibile
• tSQLt (free)
• Semplice da installare
• Struttura comune (Assemble, Act, Assert)
• Framework in t-sql
• SQL Server Management Studio
• Via t-sql
• Con Red Gate SQL Test
• Integrato anche con il framework SQLCop

13. Struttura di un test tSQLt
• Built-in
• tsqlt schema
• Classes
• Gruppi di stored procedure (i test)
• User defined schema
• Convenzioni
• Naming: test*
• Tool
• Run
• NewTestClass/DropClass
• Fail/Assert
• Uninstall

14. tSQLt test – Pipeline
Assemble Act Assert
Creazione fake
Set opzioni fake
Popolamento fake
Esecuzione comandi
Business logic
Esecuzione proc/func
Valori attesi
Metadati attesi
Comportamenti attesi

15. DEMO - tSQLt + SSMS + SQL Test

16. Conclusioni
• Nessuna scusa per non testare
• Esattamente come per ogni metodo lato codice
• I tool esistono
• Ed esistono anche i generatori di dati
• I processi di test aumentano la qualità
• I requisiti di business sono più rispettati e «coperti»

17. Q&A
• Domande?

18. Risorse
• http://www.red-gate.com/products/sql-development/sql-test/
• http://tsqlt.org/
• http://sourceforge.net/projects/tsqlunit/
• http://msdn.microsoft.com/en-us/library/dd172118(v=vs.100).aspx (VS 2010)
• http://blogs.msdn.com/b/ssdt/archive/2012/12/07/getting-started-with-sql-server-database-unit-testing-in-
ssdt.aspx (SSDT)
• http://msdn.microsoft.com/en-us/library/jj851200(v=vs.103).aspx (VS 2012)
• http://channel9.msdn.com/Events/Visual-Studio/Launch-2013/QE107 (VS 2013)
• http://msdn.microsoft.com/it-it/library/dn383992.aspx (Article on CI)
• http://msdn.microsoft.com/en-us/library/jj907294.aspx (DLM)
• http://en.wikipedia.org/wiki/Unit_testing
• https://www.simple-talk.com/sql/t-sql-programming/getting-started-testing-databases-with-tsqlt/
• http://utplsql.sourceforge.net/ (PL-SQL)
• https://github.com/chrisoldwood/SS-Unit

19. GRAZIE!
Continuate a seguire i PASS GLOBAL Italian Virtual Chapters
http://globalitalian.sqlpass.org/