Tutto è pronto per il Bootcamp.
Rivedremo insieme le slide architetturali che vanno da DevCon 2005 a DevCon 2010 gettando le basi per una buona architettura.
E’ quasi impressionante rivedere le slide del 2005 dove abbiamo inserito Indigo (l’attuale WCF) ancora in beta nel codice e dove, poco dopo nel materiale, si parlava di LINQ !
Ci sono ancora tre posti disponibili. Se sei intenzionato a venire prenota subito.
A lunedì.
Andrea Provaglio, che collabora con noi da qualche anno sul fronte Agile, ed io, terremo un tutorial di una giornata presso il Software Testing Forum 2010, a Milano, il 20 di giugno.
La conferenza è interamente dedicata al test di software visto da tutti i punti di vista. Con Andrea terremo una sessione sull’utilizzo delle metodologile agili nell’ambito del test delle applicazioni. Abbiamo appena finito di costruire una demo che utilizza anche Visual Studio Ultimate (lato client e lato server) per dimostrare in pratica la teoria che verrà presentata.
Questa la presentazione ufficiale:
Il 20 Giugno sarà dedicato a tutorial tenuti dai più grandi esperti a livello mondiale, che Vi renderanno partecipi delle loro competenza sui seguenti temi:
Il 21 Giugno si svolgerà la conferenza ad accesso libero con contributi selezionati da un Comitato di Programma comprendente alcuni tra i maggiori esperti a livello internazionale, sia a livello industriale che accademico.
La conferenza ha l’obiettivo di approfondire ed analizzare importanza, necessità e convenienza della qualità di software e servizi nei nuovi scenari economici e tecnologici.
http://www.swtestingforum.org/
In questi giorni stiamo lavorando ad un nuovo progetto software e finalmente, dopo essermi ripromesso di fare un post ad ogni inizio di nuovi progetti, questa volta riesco a farlo veramente.
Nel caso in cui decida di automatizzare il deploy di un database project (con o senza relativo Data Generation Plan) per l’esecuzione di test da parte del servizio di build di TFS, occorre aggirare qualche problemino:
Per prima cosa occorre inserire all’interno del progetto che contiene gli unit test una classe con un metodo marcato con l’attributo AssemblyInitialize: per default Visual Studio inserisce questa classe automaticamente solo quando si inserisce all’interno del progetto un Database Unit Test. Non lo fa quando creiamo un normale Unit Test.
La classe creata in automatico da Visual Studio si presenta così:
using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Common;
using System.Configuration;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.Data.Schema.UnitTesting;
namespace MISM.Dal.Test
{
[TestClass()]
public class DatabaseSetup
{
[AssemblyInitialize()]
public static void InitializeAssembly(TestContext ctx)
{
// Setup the test database based on setting in the
// configuration file
DatabaseTestClass.TestService.DeployDatabaseProject();
DatabaseTestClass.TestService.GenerateData();
}
}
}
Per uniformità, noi solitamente creaiamo questo stesso file col lo stesso nome (DatabaseSetup.cs) quando è necessario farlo a mano.
La seconda cosa da fare per automatizzare il deploy è utilizzare il Test Database Configuration (Accessibile dal menù Test quando il progetto di test è selezionato):
In questo maschera si procede esattamente come nel caso di configurazione dell’ambiente locale. Si può scegliere di fare il deploy del database in automatico così come di eseguire un piano di generazione dei dati.
Premuto OK si ottiene questa modifica al file app.config del progetto di test:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="DatabaseUnitTesting" type="Microsoft.Data.Schema.UnitTesting.Configuration.DatabaseUnitTestingSection, Microsoft.Data.Schema.UnitTesting, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
<DatabaseUnitTesting>
<DatabaseDeployment DatabaseProjectFileName="..\..\..\MISM.DB.SqlServer\MISM.DB.SqlServer.dbproj"
Configuration="Debug" />
<DataGeneration DataGenerationFileName="..\..\..\MISM.DB.SqlServer\Simple.dgen"
ClearDatabase="true" />
<ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(local);Initial Catalog=MISM;Integrated Security=True;Pooling=False"
CommandTimeout="30" />
<PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(local);Initial Catalog=MISM;Integrated Security=True;Pooling=False"
CommandTimeout="30" />
</DatabaseUnitTesting>
</configuration>
In pratica la configurazione contiene la definizione delle operazioni da fare e la relativa stringa di connessione in base a quando indicato nel Database Test Configuration.
Queste operazioni si attivano solo quando il progetto di test ha un metodo marcato come AssemblyInitialize: per questo è stato inserito il codice della classe DatabaseSetup.cs. Se ci scordiamo la classe, la configurazione è perfetta, ma nessuno la utilizza durante il deploy del progetto di test.
Quando si decide di automatizzare il deployment (e eventuale Data Generation Plan) all’interno di una build di TFS è necessario modificare i path verso il .dbproj e verso il file .dgen.
Il motivo è semplice: mentre in locale la directory TestResults che accoglie gli assembly da testare e il risultato dei test è una sottodirectory della solution, TFS Build utilizza directory diverse fra file binary e risultati.
Questo un esempio reale:
La directory TestResults è, come si nota, allo stesso livello di Sources, mentre normalmente TestResult è una sottodirectory della solution.
Per aggiustare il path ai due file, invece di modificare direttamente il file app.config, operazione che renderebbe la configurazione inutilizzabile in locale, si può operare in questo modo.
1) Copiare il file app.config in un file nomemacchinatfs.dbunittest.config: nomemacchinatfs è il nome della macchina dove gira il servizio di build.
2) Inserire nel file app.config originale l’attributo AllowConfigurationOverride=”true” sull’elemento DatabaseUnitTesting, lasciando invariato il resto del contenuto
<DatabaseUnitTesting AllowConfigurationOverride="true">
3) Editare il file nomemacchinatfs.dbunittest.config cancellando eliminando tutto ciò che non è all’interno dell’elemento DatabaseUnitTesting e aggiornare il path ai due file includendo “Sources” nel percorso. Nel caso in cui il progetto test sia all’interno di una solution (cosa molto probabile) occorre anche inserire il nome della solution:
<DatabaseUnitTesting>
<DatabaseDeployment DatabaseProjectFileName="..\..\..\Sources\MISM\MISM.DB.SqlServer\MISM.DB.SqlServer.dbproj"
Configuration="Debug" />
<DataGeneration DataGenerationFileName="..\..\..\Sources\MISM\MISM.DB.SqlServer\Simple.dgen"
ClearDatabase="true" />
<ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(local);Initial Catalog=MISM;Integrated Security=True;Pooling=False"
CommandTimeout="30" />
<PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(local);Initial Catalog=MISM;Integrated Security=True;Pooling=False"
CommandTimeout="30" />
</DatabaseUnitTesting>
Nel file sopra oltre alla directory Sources ho aggiunto MISM che è appunto il nome della solution.
IMPORTANTE: eliminare tutto il resto del contenuto del file.
Fatto questo è sufficiente includere nel deployment il file che abbiamo editato: il punto più furbo per farlo è includere il file dalla configurazione di deployment dei test:
Pronti –> Via. Abbiamo risolto il problema.
Un secondo problema può essere rappresentato sempre da percorsi su disco in generale da una configurazione diversa di SQL Server fra l’ambiente locale di test e l’ambiente TFS. Ad esempio se lavoriamo in locale potremmo usare sicurezza integrata oppure lavorare con I data file di SQL sul disco D, mentre su TFS potremmo voler usare un utente in sicurezza standard e un path sul disco C:\DBTests per I data file.
Una delle opzioni rese possibili da VS 2010 è differenziare il file .sqlcmdvars per l’ambiente locale e l’ambiente “complessivo”.
Ad esempio, nella figura seguente uso nella configurazione My isolated deployment environment che ha una sua connection string locale e utilizza il file DatabaseRob.sqlcmdvars
Il mio file .sqlcmdvars punta al mio percorso locale dove voglio ospitare i data file di SQL Server:
La configurazione My Project Settings invece contiene una connection completamente diversa (va in trusted connection):
e punta ad un file .sqlcmdvars denominato TFS ThinkAhead (la nostra società).
Il file sqlcmdvars punta alle directory sul nostro server TFS Buil:
Secondo e ultimo problema risolto: la build adesso può effettuare il deploy del database di test, alimentarlo seguendo il piano di generazione e lanciare i test.
Alla prossima