![\"\"](\"https:\/\/cloudsurfers.it\/wp-content\/uploads\/2020\/06\/unit-test-header.png\")
<\/p>\n\n\n\n<\/p>\n\n\n\n
Unit Testing \u00e8 il nome dato ad una metodologia di test del software che aiuta a determinare se i moduli di un programma funzionano correttamente.<\/p>\n\n\n\n
Data questa definizione, \u00e8 abbastanza facile capire l’importanza di suddividere ed isolare correttamente il codice in piccole unit\u00e0, con pochi input e un singolo output, cos\u00ec da ottenere componenti adatti al riutilizzo ed al testing. Nella programmazione ad oggetti (OOP), in cui il codice sorgente del programma \u00e8 suddiviso in classi, un’unit\u00e0 lo \u00e8 spesso un metodo di una classe o pu\u00f2 anche essere una funzione statica di una classe di supporto.<\/p>\n\n\n\n
STD<\/strong> (Standard Testing Development<\/em>), questo approccio prevede che prima venga scritto il codice e poi (forse) i test. In altre parole, il nostro codice sorgente pu\u00f2 essere (e quindi solitamente viene) scritto prima (o anche senza) test case.<\/p>\n\n\n\n TDD<\/strong> (Test Driven Development<\/em>) \u00e8 pi\u00f9 una pratica di programmazione che un approccio di test e pu\u00f2 essere un\u2019ottima pratica, almeno per determinati scenari. In breve, uno sviluppatore che adotta la metodologia TDD convertir\u00e0 tutti i requisiti software in test case specifici, quindi scriver\u00e0 il nuovo codice (o migliorer\u00e0 il codice esistente) in modo che i test vengano superati. BDD<\/strong> (Behavior-Driven Development<\/em>) \u00e8 un processo di sviluppo software che condivide lo stesso approccio test-first di TDD, ma concentrando i test su quella che dovr\u00e0 essere la prospettiva dell\u2019utente finale anzich\u00e9 sull\u2019implementazione. Se vogliamo testare l\u2019implementazione effettiva dei nostri metodi\/unit\u00e0, TDD potrebbe essere la strada giusta da percorrere. Tuttavia, se puntiamo a dei test pi\u00f9 orientati all\u2019utilizzo dell’utente finale, il solo approccio TDD potrebbe dare dei falsi positivi, specialmente se il sistema evolve (come spesso fanno i progetti guidati da Agile).<\/p>\n\n\n\n TDD ha lo scopo di imporre agli sviluppatori il controllo sul codice scritto, mentre BDD mira a soddisfare sia lo sviluppatore che l\u2019utente finale. Partendo dal back-end, prenderemo in esame un esempio di come poter realizzare un server sviluppato in .NET Core utilizzando come framework di test xUnit.net<\/strong>.<\/p>\n\n\n\n Moq<\/strong>: \u00e8 un mocking<\/em> framework, ovvero \u00e8 uno strumento che permette di creare oggetti sostitutivi che simulino il comportamento di quelli reali. Il concetto di mocking quindi \u00e8 strettamente legato allo unit testing.<\/p>\n\n\n\n Microsoft.EntityFrameworkCore.InMemory<\/strong> \u00e8 un database provider per Entity Framework Core che pu\u00f2 essere utilizzato a scopo di test in quanto inizializza una base dati che rimane solamente in memoria, di fatto risulta essere un finto database<\/p>\n\n\n\n Una volta terminata la configurazione dell\u2019ambiente, possiamo procedere con l\u2019implementazione dei test. Come prima cosa, aggiungere al progetto UnitTestSample.Test la dipendenza a UnitTestSample.<\/p>\n\n\n\n Nel mondo Web API, quello che solitamente viene testato sono i metodi esposti dai Controller, ovvero le chiamate che vengono esposte all\u2019esterno. Le API per\u00f2 sfruttano due importanti dipendenze solitamente, che sono l\u2019HttpContext<\/em> e l\u2019ApplicationDbContext<\/em>. Supponiamo di voler testare un\u2019API GetCar()<\/em> che ha come funzione quella di ritornare una citt\u00e0. Per scrivere questo test, creo un nuovo file CarsController_Test.cs<\/em> all\u2019interno del progetto di Test ed inizializzo la classe nel modo seguente:<\/p>\n\n\n Vediamo come popolare le tre region affinch\u00e8 venga popolato il context EntityFramework con un record di Car, il tutto senza andare per\u00f2 ad utilizzare il database finisco, ma lasciandolo solo in memoria.<\/p>\n\n\n Ora \u00e8 possibile mandare in esecuzione il test appena scritto; ci sono due modi per farlo:<\/p>\n\n\n\n Partendo dagli stessi principi elencati in precedenza, anche per la parte del front-end possiamo pensare di utilizzare esattamente lo stesso tipo di approccio per andare a testare la nostra app. I Karma test vengono scritti sfruttando il framework Jasmine e solitamente sono costruiti utilizzando queste 3 principali API:<\/p>\n\n\n\n Queste API sono utilizzabili all\u2019interno dei files *.spec.ts<\/em>. Alcune note riguardo questo schema:<\/p>\n\n\n\n Una volta definiti questi elementi, si pu\u00f2 procedere alla creazione di un mock service; \u00e8 possibile utilizzare uno strumento messo a disposizione da Jasmine chiamato Spy<\/em><\/strong>. Tramite Spy \u00e8 possibile creare un mock di un oggetto e fare override dei suoi metodi. Nel nostro esempio, andremo a creare un mock service per simulare ci\u00f2 che il CarService dovrebbe fare, ovvero recuperare le informazioni dal server. Di seguito un esempio di come inizializzare un service tramite Spy<\/p>\n\n\n Una volta inizializzato il service, ricordarsi di referenziarlo nella sezione providers di TestBed<\/p>\n\n\n Terminata la configurazione di TestBed all\u2019interno del metodo beforeEach<\/em> asincrono, spostarsi nel beforeEach<\/em> sincrono ed aggiungere l\u2019istruzione fixture.detectChanges();<\/em>.<\/p>\n\n\n Questo comando solleva il trigger di rilevamento modifiche lato client. In questo modo, avverr\u00e0 correttamente il popolamento delle parti di codice che sono costruite dinamicamente (ad esempio la tabella che mostra i risultati provenienti dal mock service). Come prima cosa assegno una descrizione al test che andr\u00f2 ad eseguire, dopo di che utilizzo la variabile fixture<\/em> per interrogare il DOM. Nel caso specifico, mi voglio assicurare che esista almeno una riga nella tabella. Ultimata la definizione dei test, si \u00e8 pronti per mandarli in esecuzione. Protractor \u00e8 un test framework di tipo end-to-end, quindi di fatto simula a tutti gli effetti le azioni che l\u2019utente dovrebbe compiere sul browser. A questo punto spostarsi nel file protractor.conf.js<\/em> ed impostare come parametro di baseUrl l\u2019URL del sito che si vuole andare a testare (impostare l\u2019url della webapp che viene creata da Visual Studio). Notare la sequenza delle operazioni programmate:<\/p>\n\n\n\n A questo punto tutto \u00e8 pronto per poter eseguire il test appena definito. Eseguire questa sequenza di comandi per avviare Protractor nel modo corretto:<\/p>\n\n\n\n Se tutto \u00e8 stato svolto correttamente, comparir\u00e0 nella console un riepilogo simile al seguente:<\/p>\n\n\n\n Certo che \u00e8 possibile, per\u00f2 non lo si pu\u00f2 fare solamente aggiungendo un classico breakpoint Spesso testare il codice \u00e8 una pratica che viene messa in secondo piano perch\u00e8 la frenesia di avere risultati porta a sacrificare “ci\u00f2 che non \u00e8 necessario”. Testare il codice ha un costo effettivamente sia in termini di tempo di analisi che di implementazione, ma \u00e8 un investimento per il futuro. Se i test vengono scritti nel modo corretto e funzionale, pi\u00f9 il software evolver\u00e0 e pi\u00f9 il tempo speso inizialmente torner\u00e0 come tempo risparmiato nel bugfixing. Un altro vantaggio importante che porta lo Unit Testing \u00e8 l’agevolare l’integrazione di moduli di software scritti da diversi membri del team di sviluppo. L’esempio presente in questa guida \u00e8 scaricabile a questo link<\/a>.<\/strong><\/em><\/p>\n\n\n\n Lo Unit Testing \u00e8 spesso sottovalutato perch\u00e8 ritenuta un’attivit\u00e0 “sacrificabile”, ma se fatto bene si riveler\u00e0 un importante investimento per i propri prodotti.<\/p>\n","protected":false},"author":4,"featured_media":2263,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wds_primary_category":0,"footnotes":""},"categories":[90,109,84,36],"tags":[94,107,111,93,110,108],"class_list":["post-2256","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net-core","category-angular","category-asp-net-core","category-guide","tag-net-core","tag-angular","tag-c","tag-dotnet-core","tag-tutorial","tag-unit-testing"],"_links":{"self":[{"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/posts\/2256","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/comments?post=2256"}],"version-history":[{"count":0,"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/posts\/2256\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/media\/2263"}],"wp:attachment":[{"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/media?parent=2256"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/categories?post=2256"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudsurfers.it\/index.php\/wp-json\/wp\/v2\/tags?post=2256"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
La differenza principale tra i STD e TDD \u00e8 che in TDD i test sono condizioni obbligatorie che dobbiamo soddisfare, mentre nel caso STD sono principalmente la prova del funzionamento del nostro codice esistente.
Di seguito uno schema riassuntivo di quali sono i 3 step che caratterizzano TDD:<\/p>\n\n\n\n![\"\"](\"https:\/\/cloudsurfers.it\/wp-content\/uploads\/2020\/06\/TDD.png\")
<\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/cloudsurfers.it\/wp-content\/uploads\/2020\/06\/BDD.png\")
<\/figure><\/div>\n\n\n\n
Pertanto, possiamo concludere che BDD estende TDD e non lo sostituisce.<\/p>\n\n\n\nTutorial: Unit Testing<\/h1>\n\n\n\n
Backend – .NET Core<\/h2>\n\n\n\n
![\"\"](\"https:\/\/cloudsurfers.it\/wp-content\/uploads\/2020\/06\/VS2019-create-webapp.gif\")
<\/li>dotnet new xunit -o UnitTestSample.Tests<\/code>
In questo modo .NET CLI creer\u00e0 per noi un nuovo progetto di test e si occuper\u00e0 di svolgere alcune operazioni di post process dopo la creazione.<\/li>Install-Package Moq<\/code><\/li>Install-Package Microsoft.EntityFrameworkCore.InMemory<\/code><\/li><\/ol>\n\n\n\n\npublic class CarsController_Test\n{\n\t\/\/\/ <summary>\n\t\/\/\/ Test GetCar() method\n\t\/\/\/ <\/summary>\n\t\/\/\/ <returns><\/returns>\n\t[Fact]\n\tpublic async void GetCar()\n\t{\n\t\t#region Arrange\n\t\t\/\/todo: define required assets\n\t\t#endregion\n\n\t\t#region Act\n\t\t\/\/todo: invoke the test\n\t\t#endregion\n\n\t\t#region Assert\n\t\t\/\/todo: verify that conditions are met\n\t\t#endregion\n\t}\n}\n<\/pre><\/div>\n\n\n\npublic class CarsController_Test\n{\n\t\/\/\/ <summary>\n\t\/\/\/ Test GetCar() method\n\t\/\/\/ <\/summary>\n\t\/\/\/ <returns><\/returns>\n\t[Fact]\n\tpublic async void GetCar()\n\t{\n\t\t#region Arrange\n\t\tvar options = new DbContextOptionsBuilder<ModelContext>()\n\t\t\t.UseInMemoryDatabase(databaseName: "cars")\n\t\t\t.Options;\n\n\t\tusing (var ctx = new ModelContext(options))\n\t\t{\n\t\t\tawait ctx.Car.AddAsync(new Car\n\t\t\t{\n\t\t\t\tCarId = 1,\n\t\t\t\tBrand = "Ferrari",\n\t\t\t\tModel = "Fxx",\n\t\t\t\tCv = 1050\n\t\t\t});\n\t\t\tawait ctx.SaveChangesAsync();\n\t\t}\n\t\tCar existingCar = null;\n\t\tCar non_existingCar = null;\n\t\t#endregion\n\n\t\t#region Act\n\t\tusing (var ctx = new ModelContext(options))\n\t\t{\n\t\t\tvar controller = new CarsController(ctx);\n\t\t\texistingCar = await controller.GetCar(1);\n\t\t\tnon_existingCar = await controller.GetCar(2);\n\n\t\t}\n\t\t#endregion\n\n\t\t#region Assert\n\t\tAssert.True(existingCar != null && non_existingCar == null);\n\t\t#endregion\n\t}\n}\n<\/pre><\/div>\n\n\ndotnet test<\/code><\/li>![\"\"](\"https:\/\/cloudsurfers.it\/wp-content\/uploads\/2020\/06\/test-explorer.png\")
<\/figure><\/div>\n\n\n\nFrontend – Angular<\/h2>\n\n\n\n
Gli strumenti da utilizzare per raggiungere l\u2019obiettivo sono:<\/p>\n\n\n\nKarma<\/h3>\n\n\n\n
Supponiamo di voler testare un componente CarsComponent<\/em> (definiamo il nome del file del componente con cars.component.ts<\/em>), quello che ci sar\u00e0 da fare in primis sar\u00e0 creare un nuovo file di test cars.component.spec.ts<\/em>. Uno scheletro \u201ctipo\u201d sar\u00e0 come segue:<\/p>\n\n\n\ndescribe('CarsComponent', () => {\n let fixture: ComponentFixture <CarsComponent> ;\n let component: CarsComponent;\n\n \/\/ async beforeEach(): testBed initialization\n beforeEach(async (() => {\n \/\/todo: initialize required providers\n TestBed.configureTestingModule({\n declarations: [CarsComponent],\n imports: [\n BrowserAnimationsModule\n ],\n providers: [\n \/\/todo: reference required providers\n ]\n }).compileComponents();\n }));\n\n \/\/ synchronous beforeEach(): fixtures and components setup\n beforeEach(() => {\n fixture = TestBed.createComponent(CarsComponent);\n component = fixture.componentInstance;\n \/\/todo: configure fixture\/component\/children\/etc.\n });\n \/\/todo: implement some tests\n});\n<\/pre><\/div>\n\n\n\n \/\/ Create a mock carService object with a mock 'getData' method\n let carsService = jasmine.createSpyObj <CarsService> ('CarsService', ['getData']);\n \/\/ Configure the 'getData' spy method\n carsService.getData.and.returnValue(\n \/\/ return an Observable with some test data\n of <Car[]> ([{\n carId: 1,\n brand: 'Ferrari',\n model: 'FXXX',\n cv: 1050\n },\n {\n carId: 2,\n brand: 'Lamborghini',\n model: 'Aventador',\n cv: 770\n }\n ]));\n<\/pre><\/div>\n\n\n\nTestBed.configureTestingModule({\n declarations: [CarsComponent],\n imports: [\n BrowserAnimationsModule\n ],\n providers: [{\n provide: CarsService,\n useValue: carsService\n }]\n}).compileComponents();\n<\/pre><\/div>\n\n\n\n\/\/ synchronous beforeEach(): fixtures and components setup\nbeforeEach(() => {\n fixture = TestBed.createComponent(CarsComponent);\n component = fixture.componentInstance;\n fixture.detectChanges();\n});\n<\/pre><\/div>\n\n\n
Ultimata questa fase di configurazione dell\u2019ambiente di test, si possono iniziare a scrivere i test veri e propri. Jasmine prevede il comando it()<\/em> da utilizzare per la definizione del test, mentre il comando expect()<\/em> viene usato per il check vero e proprio che vogliamo effettuare sul test specifico.
Un semplice esempio: \u201cvoglio testare che la tabella che mostra l’elenco dei record di cars contenga almeno una riga<\/em>\u201c. Ecco l\u2019esempio di come \u00e8 possibile implementare questa cosa:<\/p>\n\n\n\nit('should contain a table with a list of one or more cars',\n async (() => {\n let table = fixture.nativeElement.querySelector('table.table-striped');\n let tableRows = table.querySelectorAll('tr');\n expect(tableRows.length).toBeGreaterThan(0);\n }));\n<\/pre><\/div>\n\n\n
Aprire una finestra di prompt dei comandi e posizionarsi nella cartella ClientApp e lanciare il seguente comando ng test<\/code> . L\u2019esecuzione di questa istruzione avvier\u00e0 il Karma test runner, quindi verr\u00e0 aperta una nuova istanza del browser configurato nel file karma.conf.js<\/em> e verranno eseguiti in cascata tutti i test definiti per ogni blocco it()<\/em> dichiarato. Il risultato finale sar\u00e0 un report simile a questo<\/p>\n\n\n\n![\"\"](\"https:\/\/cloudsurfers.it\/wp-content\/uploads\/2020\/06\/karma-res.png\")
<\/figure>\n\n\n\nProtractor<\/h3>\n\n\n\n
\n
Come prima cosa, se il progetto \u00e8 stato creato direttamente da Visual Studio 2019 utilizzando come template di partenza quello della Webapp ASP.NET Core con Angular, automaticamente verr\u00e0 creata una cartella \/ClientApp\/e2e<\/em>, all\u2019interno della quale ci saranno tutta una serie di files di configurazione di base per utilizzare Protractor.
Partendo da questa preconfigurazione, elencher\u00f2 passo per passo le operazioni da fare per poter inizializzare ed utilizzare Protractor framework.
Si comincer\u00e0 con l\u2019installare il framework con le sue dipendenze; da prompt dei comandi, posizionarsi nella cartella ClientApp ed eseguire i seguenti comandi:<\/p>\n<\/div><\/div>\n\n\n\nnpm install -g protractor\nwebdriver-manager update\nnpm install jasmine-spec-reporter --save-dev\n<\/pre><\/div>\n\n\n
Tra i parametri del file protractor.conf.js<\/em> si evidenzia specs<\/em>; esso conterr\u00e0 l\u2019elenco di tutti i file .ts che contengono i test e che si vorranno mandare in esecuzione. Di default Visual Studio propone il parametro “.\/src\/**\/*.e2e-spec.ts” cos\u00ec che tutti i files nella cartella e2e\/src che terminano con .e2e-spec.ts<\/em> saranno eseguiti automaticamente.
Fatte queste premesse, spostarsi ora nel file app.e2e-spec.ts per scrivere il primo test. Cos\u00ec come per Karma, anche Protractor si avvale di Jasmine come strumento di scrittura e definizione dei test; quindi il set di test \u00e8 aperto dal comando describe()<\/em> seguito poi dalla definizione dei singoli test tramite i metodi it()<\/em>. Prendiamo questo esempio come riferimento:<\/p>\n\n\n\ndescribe('App', () => { \n it('check correct number of rows', async () => {\n await browser.get('\/'); \n await browser.waitForAngular();\n let elems = element.all(by.tagName('tbody tr')); \n expect(elems.count()).toEqual(1); \n });\n});\n<\/pre><\/div>\n\n\nprotractor .\\e2e\\protractor.conf.js<\/code><\/li><\/ol>\n\n\n\n![\"\"](\"https:\/\/cloudsurfers.it\/wp-content\/uploads\/2020\/06\/protractor.png\")
<\/figure>\n\n\n\nE’ possibile andare in debug dei test scritti con Protractor?<\/h3>\n\n\n\n
debugger<\/code> nel codice, ma sono necessari alcuni passaggi per far si che il comando funzioni:<\/p>\n\n\n\nnode --inspect-brk $env:APPDATA\\npm\\node_modules\\protractor\\bin\\protractor .\\e2e\\protractor.conf.js<\/code><\/li>Conclusioni<\/h1>\n\n\n\n
In sostanza: state iniziando un nuovo progetto? Affrontatelo fin da subito con un approccio BDD<\/strong>, \u00e8 un investimento che verr\u00e0 sicuramente ripagato nel tempo.<\/p>\n\n\n\nLink utili<\/h1>\n\n\n\n