Esercizio - Eseguire i test dell'interfaccia utente in locale e nella pipeline
Prima di eseguire i test nella pipeline, Andy e Amita vogliono verificare che i nuovi test dell'interfaccia utente eseguano le operazioni desiderate. In questa sezione verranno fornite le istruzioni per l'esecuzione dei test dell'interfaccia utente di Selenium prima in locale e quindi nella pipeline.
La scrittura di test automatizzati è un processo iterativo, analogamente alla scrittura di qualsiasi altro tipo di codice. Per le proprie app, sarà probabilmente necessario provare alcuni approcci, consultare la documentazione di riferimento e il codice di esempio e correggere eventuali errori di compilazione.
Facoltativo: installare il driver Selenium per Microsoft Edge
Seguire questa sezione se si vuole osservare l'esecuzione dei test in locale in Microsoft Edge.
Il pacchetto NuGet per Chrome e Firefox installa il software driver nella directory bin, insieme al codice di test compilato. Per Edge è necessario installare manualmente il driver. A questo scopo:
Installare Microsoft Edge.
Aprire Edge e passare a
edge://settings/help
. Annotare il numero di versione. Ecco un esempio:Passare alla pagina di download dei driver di Microsoft Edge e scaricare il driver corrispondente al numero di versione di Edge. Ecco un esempio:
Estrarre il file con estensione zip nella sottodirectory bin/Release/net6.0 della directory del progetto Tailspin.SpaceGame.Web.UITests. Creare queste directory se non esistono.
In macOS potrebbe essere necessario aggiornare i criteri di sistema per consentire l'esecuzione di msedgedriver. A questo scopo, in Visual Studio Code eseguire il comando spctl
seguente dal terminale:
spctl --add Tailspin.SpaceGame.Web.UITests/bin/Release/net6.0/msedgedriver
Esportare le variabili di ambiente
Più avanti in questo modulo si eseguiranno test di Selenium in Windows Server 2019. Il software preinstallato è elencato nella documentazione.
Nella sezione relativa ai driver Web di Selenium sono elencate le versioni del driver Selenium disponibili per Chrome, Firefox ed Edge. Ecco un esempio:
Per ogni driver è disponibile la variabile di ambiente mappata al percorso del driver. Ad esempio, ChromeWebDriver
corrisponde al percorso del driver Chrome.
Il codice di unit test è già configurato per leggere queste variabili di ambiente. Queste variabili indicano a Selenium dove si trovano i file eseguibili del driver. Per eseguire gli unit test in locale, è necessario esportare le stesse variabili di ambiente.
In Visual Studio Code passare al terminale. Quindi eseguire questi comandi: Sostituire il percorso visualizzato con il percorso completo del progetto mslearn-tailspin-spacegame-web-deploy.
Importante
Assicurarsi di eseguire questi comandi e impostare le variabili di ambiente nella stessa finestra del terminale usata per eseguire i test.
driverDir="C:\Users\user\mslearn-tailspin-spacegame-web-deploy\Tailspin.SpaceGame.Web.UITests\bin\Release\net6.0"
export ChromeWebDriver=$driverDir
export EdgeWebDriver=$driverDir
export GeckoWebDriver=$driverDir
Eseguire i test di interfaccia utente in locale
Il metodo Setup
in HomePageTest.cs passa alla home page Space Game dopo avere impostato la variabile membro driver
.
Sebbene sia possibile impostare l'URL del sito come hardcoded, qui l'URL viene letto da una variabile di ambiente denominata SITE_URL
. In questo modo, è possibile eseguire i test più volte su URL diversi.
// Navigate to the site.
// The site name is stored in the SITE_URL environment variable to make
// the tests more flexible.
string url = Environment.GetEnvironmentVariable("SITE_URL");
driver.Navigate().GoToUrl(url + "/");
Poiché il sito Web Space Game non è ancora stato distribuito nell'ambiente del servizio app, si userà il sito ospitato da Microsoft per eseguire i test in locale.
Per eseguire i test in locale:
In Visual Studio Code passare al terminale integrato e aprire una nuova finestra del terminale.
Eseguire i comandi seguenti nella nuova finestra del terminale.
dotnet build --configuration Release dotnet run --configuration Release --no-build --project Tailspin.SpaceGame.Web
Prendere nota del collegamento del sito Web locale, che in questo esempio è
http://localhost:5000
.Tornare alla finestra del terminale in cui sono state impostate le variabili di ambiente nel passaggio precedente e assicurarsi di essere nella directory radice del progetto. Ecco un esempio:
cd ~/mslearn-tailspin-spacegame-web-deploy
Esportare la variabile di ambiente
SITE_URL
. Usare il collegamento locale ottenuto nel passaggio precedente.export SITE_URL="http://localhost:5000"
Questa variabile punta al sito Web Space Game ospitato da Microsoft.
Eseguire i test dell'interfaccia utente.
dotnet test --configuration Release Tailspin.SpaceGame.Web.UITests
Questo codice esegue i test che si trovano nel progetto Tailspin.SpaceGame.Web.UITests.
Durante l'esecuzione dei test, vengono visualizzati uno o più browser. Selenium controlla ogni browser e segue i passi del test che sono stati definiti.
Nota
Può capitare che non vengano visualizzati tutti e tre i browser. Ad esempio, non verrà visualizzata l'esecuzione dei test su Chrome se Chrome non è installato o si ha una versione incompatibile. Anche se viene visualizzato un solo browser, significa che i test funzionano. In una situazione reale, nell'ambiente di sviluppo locale, potrebbe essere necessario configurare tutti i browser su cui eseguire il test. Questo consente di verificare che i test si comportino come previsto in ogni configurazione prima di eseguire i test nella pipeline.
Dal terminale, tracciare l'output di ogni test. E notare il riepilogo dell'esecuzione dei test alla fine.
Questo esempio illustra che su nove test tutti hanno avuto esito positivo e zero test sono stati ignorati:
Passed! - Failed: 0, Passed: 9, Skipped: 0, Total: 9, Duration: 5 s
Aggiungere la variabile SITE_URL in Azure Pipelines
In precedenza è stata impostata la variabile di ambiente SITE_URL
in locale per indicare ai test dove indirizzare ogni browser. È possibile aggiungere questa variabile ad Azure Pipelines. Il processo è simile a quello seguito per aggiungere le variabili per le istanze del servizio app. Quando l'agente viene eseguito, questa variabile viene esportata automaticamente nell'agente come variabile di ambiente.
A questo punto, aggiungere la variabile pipeline prima di aggiornare la configurazione della pipeline. A questo scopo:
In Azure DevOps, passare al progetto Space Game - Web - Test funzionali.
In Pipeline, selezionare Libreria.
Selezionare il gruppo di variabili Rilascio.
In Variabili, selezionare + Aggiungi.
Immettere SITE_URL come nome della variabile. Come valore, immettere l'URL dell'istanza del servizio app di Azure che corrisponde all'ambiente di test, ad esempio http://tailspin-space-game-web-test-10529.azurewebsites.net.
Nella parte superiore della pagina selezionare Salva per salvare la variabile nella pipeline.
Il gruppo di variabili sarà simile al seguente:
Modificare la configurazione della pipeline
In questa sezione viene modificata la configurazione della pipeline per eseguire i test dell'interfaccia utente di Selenium durante la fase Test.
In Visual Studio Code aprire il file azure-pipelines.yml. Quindi modificare il file in questo modo:
Suggerimento
Questo file contiene alcune modifiche, quindi è consigliabile sostituire l'intero file con quanto visualizzato qui.
trigger: - '*' variables: buildConfiguration: 'Release' dotnetSdkVersion: '6.x' stages: - stage: 'Build' displayName: 'Build the web application' jobs: - job: 'Build' displayName: 'Build job' pool: vmImage: 'ubuntu-20.04' demands: - npm variables: wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot' dotnetSdkVersion: '6.x' steps: - task: UseDotNet@2 displayName: 'Use .NET SDK $(dotnetSdkVersion)' inputs: version: '$(dotnetSdkVersion)' - task: Npm@1 displayName: 'Run npm install' inputs: verbose: false - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)' displayName: 'Compile Sass assets' - task: gulp@1 displayName: 'Run gulp tasks' - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt' displayName: 'Write build info' workingDirectory: $(wwwrootDir) - task: DotNetCoreCLI@2 displayName: 'Restore project dependencies' inputs: command: 'restore' projects: '**/*.csproj' - task: DotNetCoreCLI@2 displayName: 'Build the project - $(buildConfiguration)' inputs: command: 'build' arguments: '--no-restore --configuration $(buildConfiguration)' projects: '**/*.csproj' - task: DotNetCoreCLI@2 displayName: 'Publish the project - $(buildConfiguration)' inputs: command: 'publish' projects: '$(System.DefaultWorkingDirectory)/**/Tailspin.SpaceGame.Web.csproj' publishWebProjects: false arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)' zipAfterPublish: true - publish: '$(Build.ArtifactStagingDirectory)' artifact: drop - stage: 'Dev' displayName: 'Deploy to the dev environment' dependsOn: Build jobs: - deployment: Deploy pool: vmImage: 'ubuntu-20.04' environment: dev variables: - group: Release strategy: runOnce: deploy: steps: - download: current artifact: drop - task: AzureWebApp@1 displayName: 'Azure App Service Deploy: website' inputs: azureSubscription: 'Resource Manager - Tailspin - Space Game' appName: '$(WebAppNameDev)' package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip' - stage: 'Test' displayName: 'Deploy to the test environment' dependsOn: Dev jobs: - deployment: Deploy pool: vmImage: 'ubuntu-20.04' environment: test variables: - group: 'Release' strategy: runOnce: deploy: steps: - download: current artifact: drop - task: AzureWebApp@1 displayName: 'Azure App Service Deploy: website' inputs: azureSubscription: 'Resource Manager - Tailspin - Space Game' appName: '$(WebAppNameTest)' package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip' - job: RunUITests dependsOn: Deploy displayName: 'Run UI tests' pool: vmImage: 'windows-2019' variables: - group: 'Release' steps: - task: UseDotNet@2 displayName: 'Use .NET SDK $(dotnetSdkVersion)' inputs: version: '$(dotnetSdkVersion)' - task: DotNetCoreCLI@2 displayName: 'Build the project - $(buildConfiguration)' inputs: command: 'build' arguments: '--configuration $(buildConfiguration)' projects: '$(System.DefaultWorkingDirectory)/**/*UITests.csproj' - task: DotNetCoreCLI@2 displayName: 'Run unit tests - $(buildConfiguration)' inputs: command: 'test' arguments: '--no-build --configuration $(buildConfiguration)' publishTestResults: true projects: '$(System.DefaultWorkingDirectory)/**/*UITests.csproj' - stage: 'Staging' displayName: 'Deploy to the staging environment' dependsOn: Test jobs: - deployment: Deploy pool: vmImage: 'ubuntu-20.04' environment: staging variables: - group: 'Release' strategy: runOnce: deploy: steps: - download: current artifact: drop - task: AzureWebApp@1 displayName: 'Azure App Service Deploy: website' inputs: azureSubscription: 'Resource Manager - Tailspin - Space Game' appName: '$(WebAppNameStaging)' package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
Il file include le tre modifiche seguenti:
La variabile
dotnetSdkVersion
è stata spostata nella parte superiore del file in modo che sia accessibile da più fasi. In questo caso, la fase Build e la fase Test richiedono questa versione di .NET Core.La fase Build pubblica solo il pacchetto del sito Web Space Game come artefatto della compilazione. In precedenza sono stati pubblicati artefatti come questo:
- task: DotNetCoreCLI@2 displayName: 'Publish the project - $(buildConfiguration)' inputs: command: 'publish' projects: '**/*.csproj' publishWebProjects: false arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)' zipAfterPublish: true
Questa attività genera due artefatti della compilazione: il pacchetto del sito Web Space Game e i test dell'interfaccia utente compilati. I test dell'interfaccia utente vengono compilati durante la fase di compilazione per assicurarsi che vengano compilati durante la fase di test, ma non è necessario pubblicare il codice di test compilato. La compilazione viene eseguita di nuovo nella fase Test al momento dell'esecuzione dei test.
La fase Test include un secondo processo che compila ed esegue i test. Questo processo è simile a quello usato nel modulo Eseguire test di qualità nella pipeline di compilazione con Azure Pipelines. In quel modulo sono stati eseguiti test NUnit che hanno verificato la funzionalità di filtro del tabellone punteggi.
Tenere presente che un processo di distribuzione è un tipo particolare di processo che svolge un ruolo importante nelle fasi di distribuzione. Il secondo processo è un processo normale che esegue i test di Selenium su un agente di Windows Server 2019. Anche se si usa un agente Linux per compilare l'applicazione, qui viene usato un agente Windows per eseguire i test dell'interfaccia utente. Viene usato un agente Windows perché Amita esegue test manuali in Windows ed è ciò che usa la maggior parte dei clienti.
Il processo
RunUITests
dipende dal processoDeploy
per assicurare che i processi vengano eseguiti nell'ordine corretto. Il sito Web verrà distribuito al servizio app prima di eseguire i test dell'interfaccia utente. Se non si specifica questa dipendenza, i processi all'interno della fase possono essere eseguiti in qualsiasi ordine o in parallelo.
Nel terminale integrato aggiungere azure-pipelines.yml all'indice, eseguire il commit delle modifiche ed eseguire il push del ramo in GitHub.
git add azure-pipelines.yml git commit -m "Run Selenium UI tests" git push origin selenium
Osservare l'esecuzione dei test in Azure Pipelines
Qui si può osservare l'esecuzione della pipeline. La pipeline esegue i test dell'interfaccia utente Selenium durante la fase Test.
In Azure Pipelines passare alla compilazione e tracciarne l'esecuzione.
Durante la compilazione, si noterà che i test automatizzati vengono eseguiti dopo la distribuzione del sito Web.
Al completamento della compilazione, passare alla pagina di riepilogo.
Si noterà che la distribuzione e i test dell'interfaccia utente sono stati completati correttamente.
Osservare il riepilogo nella parte superiore della pagina.
Osservare inoltre che l'artefatto della compilazione per il sito Web Space Game viene pubblicato normalmente. Nella sezione Test e code coverage, inoltre, viene indicato che i test di Selenium sono stati superati.
Selezionare il riepilogo dei test per visualizzare il report completo.
Il report mostra che tutti e nove i test sono stati superati. Questi test includono tre test in tre browser.
Se un test ha esito negativo, vengono visualizzati i risultati dettagliati dell'errore. Da qui è possibile analizzare l'origine dell'errore, correggerlo in locale e quindi effettuare il push delle modifiche necessarie per fare in modo che i test abbiano esisto positivo nella pipeline.
Amita: Questa automazione è fantastica! Ora ho i test dell'interfaccia utente che posso eseguire nella pipeline. I test ci faranno davvero risparmiare tempo a lungo termine. Ho anche un modello da seguire per aggiungere altri test. E soprattutto, i test dell'interfaccia utente ci fanno stare più tranquilli per quanto riguarda la qualità del codice.
Andy: Tutto vero. Ricorda che i test che vengono eseguiti ripetutamente in modo manuale sono ottimi candidati per l'automazione. Puoi aggiungerne altri. Se ti blocchi o se ti serve una revisione del codice, sai dove trovarmi.