I’ll be there :-)

http://dotdotnet.org/content/TourVS2010.aspx
.m

Come cambiano i tempi…

…una volta ci si scottava con il fuoco, oggi ci si bagna con l’acqua… :-D

per la serie piccoli pirloni crescono ma pirloni restano :-D
.m

Siccome non me lo ricordo mai…

.m

Una tecnologia deve risolvere problemi non introdurne…

Il vendor, il cliente e il fornitore… o il buono, il brutto e i cattivo… :-)
Okkio…

il vendor, che ha uno scopo ben preciso, fa pressioni sul cliente, che ha uno scopo decisamente diverso e spesso ignorato (volutamente o meno) dal vendor, per fare una determinata scelta tecnologica… (mi ricorda qualcosa). A questo punto il cliente va dal fornitore con un’aspettativa radicata: soddisfare i propri bisogni seguendo i consigli del vendor che gli ha garantito (o lasciato intendere che garantisce e ha pure un sacco di peso) che è la scelta giusta…

Che cosa succede ora?
Che si scarica sul team una problematica che non è del team e che proprio non dovrebbe esistere: il cliente ha fatto scelte che non gli competono e la nomea del vendor rende decisamente difficile (se non impossibile) cambiare queste scelte.
Siamo di fronte ad un set di scelte decisamente poco piacevoli:

1. Cercare di screditare il vendor per far fare al cliente la scelta tecnologica giusta;
2. Assorbire tutta la problematica e cercare di soddisfare il bisogno con un requisito (la tecnologia) che non dovrebbe esserci;
3. Rimbalzare il cliente rischiando di perdere credibilità sia nei confronti del vendor che del mercato;

In tutti i casi secondo me c’è solo una garanzia: insoddisfazione, probabilmente condita da un bel “bagno si sangue”…, inoltre si sta verificando un curioso fenomeno: il fornitore sta generando attriti con il cliente e non può farne a meno ma non ha il benchè minimo controllo sulle cause di questi attriti.
.m

Un’architettura non si vende si usa

ne approfitto per rispondere ad un commento di PadovaBoy ad una delle mie tante esternazioni :-)
Stringendo direi che possiamo asserire che noi, in quanto sviluppatori, abbiamo un solo focus: gli user needs.
Il nostro obiettivo è soddisfare i requisiti e i bisogni del cliente, io dico anche i bisogni del cliente del nostro cliente… ne parleremo :-), come lo facciamo direi che sono “fatti nostri” e non del cliente.
In questo senso quindi non ritengo sensato che l’architettura, come tante altre “parti” (leggi ad esempio i test) del processo di sviluppo, venga usata come merce di scambio e/o punto di forza, l’architettura ha un altro scopo ben preciso: tra le tante cose deve essere a nostro uso e consumo per garantirci di assorbire in maniera fluente e naturale le “change request”. Una “change request” viene spesso vissuta dall’intero team (quindi da tutta la filiera) come problematica e questa è una delle fonti di tutti i mali, quindi il nostro sforzo, in termini architetturali (e non solo naturalmente) deve tendere in 2 direzioni ben precise:

• soddisfare i requisiti (funzionli e non);
• rendere indolore (o quasi) qualsivoglia cambio di direzione;

“Vendere” un’architettura rischia invece di creare delle aspettative inattese nel cliente, faccio un esempio triviale:

il commerciale di turno “spinge” palrando di quanto è figo Wcf che scala e che quindi una soluzione a servizi è il top, il cliente ci casca e nella sua testa si immagina che un domani potrà scalare orizzontalmente in maniera totalmente indolore… ma sappiamo tutti che non è così, abbiamo generato un’aspettativa che non è scritto da nssuna parta che saremo in grado di soddisfare… il cliente in realtà voleva semplicemente fare delle fatture :-)

Si può fare! :-)

ndr: Roby… non fare l’ing quando leggi, grazie :-)

.m

M-V-VM: The beginning

Rispondendo sui newsgroup mi sono reso conto, o forse è solo ego ;-), che probabilmente mancano risorse introduttive, molto introduttive, su Model-View-ViewModel. Non ho cercato, semplicemente mi piace scrivere, quindi sorbitemi :-), se proprio cambiate canale, aka “mark as read” ;-)
Disclaimer:

Un pattern in quanto tale è una linea guida per la soluzione ad un problema comune e in quanto linea guida va calato nel contesto del problema che deve risolvere, non va aplicato alla cieca in maniera “talebana”. Nel mio approccio all’uso di un pattern ho però scoperto che se il “primo e iniziale” approccio è un po’ talebano alla lunga paga perchè ogni volta che si devia dal pattern ci si sofferma a chiedersi perchè e quando non si ha esperienza di un dominio chiedersi perchè è “tanta roba” :-)

What’s that…?
mi sono già belle che rotto di scrivere M-V-VM quindi diventa il “nostro amico”… :-), il nostro amico è un pattern architetturale il cui focus è la presentazione dei dati, esiste da che mondo è mondo e non nasce con Wpf, è sempre stato conosciuto come Presentation Pattern; ma perchè è diventato un must, e per certi versi una buzz-word, proprio con Wpf? perchè il nostro amico trae enormi vantaggi dall’infinita potenza, flessibilità e malleabilità del motore di Data Binding proprio di Wpf.
Tornando in topic… un pattern per la presentazione dei dati è tipicamente composto da una triade, tre attori ognuno con un ruolo ben preciso:

• Visualizzare i dati: è il ruolo specificamente dedicato alla visualizzazione dei dati, questo ruolo non ha nessun diritto di fare ragionamenti sui dati, può nella migliore delle ipotesi fare ragionamenti che determinano alcune caratteristiche della visualizzazione sulla base di caratteristiche dei dati stessi: coloro di rosso il nome di un prodotto perchè non è in stock;
• Manipolare e preparare i dati: i dati tipicamente non sono pronti per essere visualizzati, la visualizzazione è spesso un appiattimento dei dati, avevte un grafo, in memoria, che è multi-dimensionale e volete rappresentarlo su un qualcosa che multi-dimensionale non è, esempio estremo un report cartaceo; questo ruolo ha quindi l’onere di trasformare e adattare i dati durante il loro ciclo di vita/caso d’uso;
• Dati duri e puri: i nostri dati veri e proprio, il dominio, nulla di più ne nulla di meno senza nessunissima nozione di essere trattato e visualizzato in un’applicazione di qualsivoglia genere;

questi attori nell’idioma del nostro amico sono:

• View: visualizza i dati;
• ViewModel: manipola e prepara i dati;
• Model: i dati quelli del nostro object model;

Un aspetto molto importante, di cui ho già avuto modo di discutere esponendo uno scenario si complesso ma decisamente tipico, è che il modello non deve mai essere esposto alla view ma deve sempre essere mediato dal view model, in realtà con l’esperienza scopriete che non è sempre necessariamente così ma è bene, soprattutto all’inizio, tenere ben presente questa regola.
What can M-V-VM do for me?
La domanda vera però probabilmente è un’altra: perchè?, perchè dovrei dannarmi per adottare il “nostro amico”? quali vantaggi ne possono trarre? alla fine dobbiamo capire se lo sbattimento il gioco vale la candela.
Separation of Concern
Da punto di vista del design sicuramente l’applicazione di un pattern di presentazione aiuta nel rispetare il principio di seprazione dei compiti, non è onere della UI prendere decisioni di business come non è onere del modello prendere decisioni sul suo shaping perchè sa di essere ospitao in una UI di un certo tipo; è inoltre indubbio che SoC aumenta la semplicità di manutenzione al crescere delle dimensioni della soluzione perchè sapere, ad esempio, dove cercare è un grosso vantaggio;
Tastability
Altro vantaggio portato da un pattern di questo tipo è che introduce la testabilità di buona parte del codice delegato alla manipolazione dei dati e l’unica cosa che ci rimane da verificare è chi abbia “composto” la UI abbia correttamente messo in binding le cose giuste con i dati giusti, ma per questo ci sono gli User Acceptance Test;
Separation of Roles

…l’unica cosa che ci rimane da verificare è chi abbia “composto” la UI abbia correttamente…

Finalmente, anche se ancora con un po’ di fatica, ma siamo sulla strada giusta, chi “disegna” non è detto che debba essere chi “programma”: M-V-VM, la tecnologia e gli strumenti finalmente ci permettono di separare abbastanza nettamente le figure professionali coinvolte nella creazione di un’applicazione Wpf.
Ma… ci sono degli svantaggi? naturalmente si:

• L’applicazion di un presentation pattern è complessivamente un’operazione complessa, che richiede dimistichezza con il pattern e con la tecnologia che si vuole usare;
• Alla complessità intrinseca dobbiamo aggiungere, ad oggi, che il rapporto tra wpf e il nostro amico è ancora agli inzi e molte aree sono borderline e diventa diffcile scegliere cosa far fare a chi, in questo senso essere un po’ talebani nell’applicazione del pattern aiuta a soffermarsi a pensare;
• Come qualsiasi pattern è senza strumenti di controllo, non abbiamo un compilatore che ci dice che una certa cosa è sbagliata ergo è molto facile farsi prendere dalla fretta del fare le cose… e la fretta produce solo cose deprecabili;

My First M-V-VM Based application
Ok… tante belle parole ma in soldoni?

Come utente voglio poter visualizzare il dettaglio dell’anagrafica di una persona visualizzando nome, cognome, data di nascita ed età al fine di avere informazioni che non ho.

Abbiamo il requisito, che potrebbe produrre un modello di questo genere:

è evidente, ed è pure voluto in questo caso anche se magari è un po’ tirato per i capelli, che sul modello manca un’informazione essenziale: l’età. Quale miglior candidato del ViewModel per gestire questa informazione “calcolata”?

Come possiamo notare un ViewModel è una classe come tutte le altre nulla di più ne nulla di meno, l’unica caratteristica peculiare è che implementa l’interfaccia INotifyPropertyChanged, all’inizio un errore che si tende a fare è far derivare i propri view model da Dependency Object ma questo non porta nessun vantaggio, anzi porta (imho) qualche svantaggio.

ndr:
abbiamo un modello e uno strato di business (perchè alla fine il ViewModel questo è) implementato e funzionante, cosa ci vieta di testarlo? cosa ci avrebbe vietato di realizzarlo con un approccio basato su TDD o su Test First? Inoltre è interessante sottolineare che fino ad ora non abbiamo minimamente tirato in ballo Wpf.

Dopo la divagazione, che mette in luce un punto interessante e importante, cosa ci resta da fare? Unire i 2 mondi, cominciamo con il disegnare la UI:

decisamente banale, ma per ora fa il suo sporco lavoro :-)
Cosa ci resta da fare? molto banalemente collegare i 2 mondi. Discuteremo del concetto di view-first e view-model-first, per ora limitiamoci a farlo funzionare con un' approccio view-first senza entrare nel dettaglio:

<Window x:Class="Mvvm.Presentation.MainView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:presentation="clr-namespace:Mvvm.Presentation"
        Title="MainView" Height="158" Width="300">
    <Window.DataContext>
        <presentation:MainViewModel />
    <Window.DataContext>

Definiamo il nostro namespace xml “presentation” che ci consente di avere accesso dallo xaml direttamente ai nostri tipi e poi assegnamo alla proprietà DataContext della Window un’istanza del nostro ViewModel.
A runtime quello che succede è questo:

La nostra Window viene istanziata e i dati visualizzati, mettendo in luce la mia tenera età :-), ma quale magia fa si che i dati giusti compaiano al posto giusto?

<TextBox Grid.Column="1" Height="23" 
            Text="{Binding Path=FirstName, UpdateSourceTrigger=PropertyChanged}"
            HorizontalAlignment="Stretch" VerticalAlignment="Top" />

In realtà nessuna magia piuttosto una “banale” espressione di binding con cui indichiamo al motore di Data Binding di Wpf come vogliamo che 2 elementi vengano “interconnessi” tra loro, figo :-)
Direi che come panoramica iniziale abbiamo messo abbastanza carne al fuoco, naturalmente ci sono anche i sorgenti.
Per ogni cosa fate un fischio :-)
.m

Dogmi? :-) (was: Pensieri sparsi ‘n’)

1. il Gantt è il male assoluto, soprattutto se pensiamo che una volta fatto sia scolpito nella pietra e chissà come mai una volta fatto e fatto vedere a qualcuno diventa sempre scolpito nella pietra… :-)
2. Una stima è una stima, quindi stiamo facendo guessing, usare una stima come fondamento di qualcosa è come costruire sulla gelatina… un suicidio;
3. Le tabelle html sono deprecate dal 2001, diamine :-)
4. Il DataSet è il male? molto spesso si :-)
5. che bello se avessi un modo per estirpare la keyword “static” :-)
6. ok, non sei un guru di T-Sql, quindi perchè ti fai del male impazzendo dietro a quello script da meganoide quando esiste San Linq2Sql?
7. Comunicare, comunicare e poi comunicare;
8. Visual Studio usa MSBuild non il santo bevitore di “righe polimorfiche”… :-)
9. Le RegEx… taccio :-)
10. l’accoppiata GC.Collect() + GC.WaitForPendingFinalizers() sono un paliativo e una mera illusione :-)
11. Un’architettura si usa non si vende;
12. un capo dispostico è la rovina della sua azienda: non ce l’ho io ce l’hanno gli operai che lavorano qui fuori… il minimo sindacale sono una simpatica dose di bestemmie mattutine;
13. La diplomazia è una disciplina importantissima in tutti i campi, sempre;
14. La musica, per me, è l’Arte con la “A” mauiscola;

.m

Diario di Bordo, data astrale 21-04-2010

Cosa ho fatto oggi, lavorativamente parlando:

• un bel po’ di slide, ma proprio un bel po’ :-)
• definito un bel po’ del dominio applicativo dell’applicazione a cui stiamo lavorando Giorgio (che se non si muove ad aprire un blog lo strozzo) ed io in combutta con “attenti a quei due”;
• Migrato la RC del TFS 2010 di produzione alla RTM: the most painless migration I’ve ever done: 45 minutes and works like a charme;
• Visto, purtroppo rapidamente, con Matteo i concetti legati all’amministrazione della security di TFS 2010;
• Fatto un interessantissimo incontro con l’A.D. in relazione all’importantissimo processo di riorganizzazione interna;
• Prodotto, con i colleghi, la solita eruzione (Lorenzo fai il bravo con le “u” e le “e”)  vulcanica di idee che sono puntualmente finite nel nostro backlog interno;
• Riso a crepapelle con Ughetto perchè stiamo lavorando con un fornitore che ne combina una peggio di bertoldo :-)

Posso con serenità dire che, per ora, è stata la giornata “più” perfetta :-P: ricca di soddisfazioni e rapporti umani con persone che stimo sempre di più e siccome si può solo migliorare… :-)
Dimenticavo… se avete bisogno di sostituire una lampadina, aggiustare la caldaia o semplicemente spazzolare il gatto… Matteo viene a casa vostra on-demand a qualsiasi ora del giorno e della notte… si lo so sono un idiota :-D
.m

non ho parole…

Certe cose proprio non me le spiego… come è possibile pensare che sta roba funzioni?

<table cellpadding="0" cellspacing="0" width="100%" border="0">
    <asp:datalist id="…" runat="server">
        <itemtemplate>
            <tr>
                <td>
                    <asp:linkbutton runat="server"> … asp:linkbutton>
                td>
            tr>
        itemtemplate>
        <selecteditemtemplate>
            <tr>
                <td> … td>
            tr>
        selecteditemtemplate>
    asp:datalist>
table>

Considerando MSDN?

Si dice il peccato ma non il peccatore… :-)
.m

VS2010 RTM: Code Coverage…

Settimana scorsa in Gaia abbiamo fatto una prima sessione di formazione su Unit Testing e naturalmente il santo sminchiatore di presentazioni era in agguato :-) e qualcosa doveva miseramente fallire: abilitare il Code Coverage in una solution nuova creata con VS 2010.
Per abilitare il Code Coverage dovete:

Aprire i settings dei test e andare su “Data and Diagnostics”

Abilitare il “Code Coverage” e ricordarsi di pigiare “Configure” per scegliere su quali assembly abilitare il Code Coverage altrimenti vi beccate un simpaticissimo errore parlantissimo :-D:

Che UX pessima… :-S
.m

Ma mi facci il “Servizio” <semi-cit.>

Serializzare un Expression Tree e spedirlo al server per deserializzarlo e aspettarsi dei risultati è tutto quello che volete ma non è di certo qualcosa che ha a che fare con SOA :-)

SOA: 4 tenets

1. Boundaries are explicit;
2. Services are autonomous;
3. Services share schema and contract, not class;
4. Service compatibility is based upon policy;

Mindmapping… aka elucubrazioni :-)
Diciamo che avete questo scenario, per noi a oggi decisamente concreto:

• A prima vista la necessità sembrava quella di dover realizzare una “becera” applicazione client-server;
• poi scoprite che l’utilizzatore finale avrà qualche “decinaia” di installazioni sparse per i nostro piccolo mondo… uno piccolino insomma :-)

è lecito secondo voi farsi queste domande?

1. è ipotizzabile che gli aggiornamenti dei client, dei server o di entrambi non siano contemporanei? quindi è uno scenario plausibile che ci siano in esecuzione contemporaneamente versioni diverse del client o del server senza che questi lo sappiano?
2. è sensato pensare che il repository dei dati sia uno ed uno solo per tutto il mondo?
3. è sensato pensare che 2 richieste consecutive, verso lo strato dei servizi, vengano evase dallo stesso server?
4. è sensato pensare che ci possa essere una richiesta che viene evasa con successo ma che non da una risposta nonostante il chiamante se la aspetti?
5. e… di conseguenza è sensato pensare che il client possa riprovare “all’infinito” finchè non ottiene la risposta che gli interessa senza che questo “sminchi” (termine molto tecnico) tutto?

Se vi fate queste domande e se rispondete “si, no, no, si, si” allora probabilmente un’architettura basata su principi SOA è la vostra “soluzione”.
Un contratto è per sempre…
Dicamo che i punti 2, 3, 4 e 5 sono probabilmente “seghe mentali”, ma vanno analizzati a fondo e soprattutto qualcuno mi deve mettere nero su bianco le risposte (ciò che non è scritto non è mai stato detto ), il primo punto però in un’applicazione geograficamente distributia è decisamente plausibile.

Come possiamo gestire il fatto che in un determinato momento t un client in America Latina faccia una chiamata ad un “metodo” di un servzio in Europa e che la firma di questo metodo sia radicalmente diversa da come il client si aspetta?

Problemi…
Mixxando il mio modo di vedere le cose e le fantastiche uscite di Giorgio ,collega in Gaia e compagno di banco, direi:

i problemi sono come il cucchiaio, non esistono… :-)

Se ci pensiamo stiamo affrontando il problema dalla parte sbagliata, lo stiamo affrontando con la “vision” (in questo caso ottusa) dello sviluppatore che è fossilizzato sul chiamare un metodo di un’istanza.
E’ Visual Studio che ci trae in inganno, o meglio svcutil.exe, generando un “robo” che ci permette di invocare metodi e aspettarci eventuali valori di ritorno, in realtà sotto sotto un servizio ragiona solo ed esclusivamente a “messaggi”:

• Un messaggio viaggia dal client verso il server;
• Un messaggio viaggia dal server verso il client;

Nulla di più ne nulla di meno, cosa ci limita nell’usare lo stesso approccio? o meglio, nell’usare il servzio con chiamate a basso livello? nulla, se non la nostra sanissima abitudine alla tipizzazione forte, e magari un po’ di pigrizia… ;-)
Se però ci pensiamo è proprio quello che ci serve:

• il client prepara un messaggio di un certo tipo;
• qualcosa serializza quel messaggio di un certo tipo in qualcosa di un certo tipo che però è spedibile “on the wire”;
• un server riceve il blobbone e delega a qualcuno di deserializzare il tutto in un messaggio di un certo tipo;
• il server analizza il messaggio e la versione e decide se, e come, farne routing verso un altro server;
• il ricevente delega a qualcuno l’onere di processare il messaggio;
• il tutto procede in senso inverso se c’è un’eventuale risposta;

Provate a condire questa cosa con un bel po’ di sano IoC e di DI e ottenete una cosa che almeno sulla carta è decisamente figosa. Vantaggi:

1. Avete comunque una tipizzazione molto forte;
2. Avete controllo totale sul versioning, sul routing e sul dispatching in maniera totalmente trasparente;
3. potete atomicizzare/serializzare un set di messaggi;

Svantaggi:

1. Se lo dovete dare in mano ad un rookie dovete sbattarvi non poco per rendere rookie-developer-firendly il tutto, ma i gioco, imho, vale decisamente la candela;
2. … nonzo :-)

Live!
voci di corridoio mi dicono che ne parleremo dal vivo, Giorgio ed Io, probabilmente in 2 occasioni una prima dell’estate e una in autunno, stay tuned ;-)
.m

I ragazzi di Los Techies…

… hanno un sacco di cose interessanti da dire: film making metaphor.
.m

Comprato :-)

http://www.gymboss.com/?src=IAP
…giusto per spaccarmi un po’ meglio la mattina… :-)
.m

Visual Studio 2010: MSDN

Mi aggancio a questo interessante post di Raff per segnalare, sempre in tema di MSDN, anche questo viewer per l’help system v3: http://mshcmigrate.helpmvp.com/viewer

Il tool non solo vi permette di visualizzare l’help di MSDN v3 in maniera umana con il supporto per l’indicizzazione, ma vi supporta anche nella migrazione al nuovo formato dell’help di eventuali help locali vostri e/o di terze parti.
Per svariati motivi, di cui non posso discutere perchè l’NDA incombe, biiiiiip sul nuovo sistema di help :-) anche se una cosa ritengo sia veramente utile: la possibilità di sincronizzare l’help offline con gli aggiornamenti presenti online senza dover riscaricare giga e giga di MSDN nel vecchio formato e impazzire per fare gli aggiornamenti:

.m

Santo subito :-)

http://pierg.wordpress.com/2010/04/15/the-magic-of-gantt
Amen :-)
.m

Beccato… :-)

La prossima volta stacco corrente e rete durante i corsi interni…
.m

Decisioni… :-)

Stockli Laser GS, provati sabato in condizioni pressochè perfette, semplicemente fantastici, due missili da brividi con una maneggevolezza quasi da SL e una tenuta impressionante, quelli che ho provato un po’ cortini (175cm) mentre io sarei orientato verso un sano 184cm.
… l’inghippo è che mi hanno parlato anche un gran bene di questi:

Blizzard Race GSR da 182cm, che non ho provato ma costano nettamente meno dei missili la sopra…
Qualcuno ha esperienze da condividere?
.m

A new kid on the block

il mio collega Matteo ha aperto un blog e per ora direi che promette bene.
.m

Pensierino della buona notte

Egon: Mai incrociare i flussi!
Peter: Perché?
Egon: Sarebbe male.
Peter: Faccio sempre confusione tra il bene e il male, che intendi per male?
Egon: Immagina che la vita come tu la conosci si fermi istantaneamente e ogni molecola del tuo corpo esploda alla velocità della luce.
Ray: Inversione protonica totale!
Peter: E quello è male... Ok è un importante ragguaglio, grazie Egon!
Mi limito a fare una semplice sostituzione:
Egon: Mai incrociare i flussi!
Mauro: mai tradire la fiducia che ti è stata concessa, mai!
Addendum…
Quanto diavolo odio le persone fatte di frasi fatte…
.m

Quality Assurance

Ho sempre fatto questa equazione:

QA == Test

usando “Test” nell’accezione peggiore per uno sviluppatore: UAT, ergo la mera esecuzione di una check list di test e la verifica che le aspettative vengano rispettate… che barba che noia…
Ora…
non c’è niente di più sbagliato che la mia convinzione di cui sopra, è un po’ che ci ragiono sopra e sono giunto alla conclusione che in un processo strutturato e consolidato in cui QA “spanna” su tutto il processo, perchè QA è come la security non si fa alla fine il giorno dopo la consegna…, un Tester è una figura decisamente intrigante.
Direi che il tester deve avere queste capacità:

1. Saper scrivere codice il cui scopo è spaccare il codice degli altri;
2. Saper scrivere codice il cui scopo è distruggere le barriere di security messe in piede dal codice altrui;
3. Vivere a strettissimo contatto con il team di sviluppo per essere costantemente sincronizzato e portare feedback;
4. Saper scrivere tool di supporto al testing per rendergli la vita felice;
5. Avere fantasia nel costruire/immaginare scenari di uso del codice altrui che gli “altrui” non hanno neanche minimamente pensato;
6. purtroppo :-) …eseguire la mera e noisa check-list;

Queste considerazioni nascono da un meeting interno con 4 guru del team della Security che ci stavano erudendo sulle news che avremmo avuto nel fx 4.0 in materia di CAS, in Corp. ad un MVP Global Summit di un paio di anni fa, in cui Raff fece una domanda del tipo:

Q: Quale è il tade off per cui decidete se testare o non testare?
A: Non c’è trade off, semplicemente testiamo tutto.

E’ ovvio che l’effort per arrivare a testare tutto è notevole e l’investimento su persone e tool interni è sicuramente interessante ma in molti contesti il gioco vale decisamente la candela, soprattutto se la QA la vendi al cliente nel contratto :-) e il cliente ha pure una nutrita schiera di avvocati che il contratto lo leggono molto bene :-P
Quindi?
Se in qualche modo foste interessati intrigati dai cinque punti di cui sopra e foste disposti ad accettare il sesto…
.m

Molto meglio, ma proprio molto…

All’inizio è decisamente pesante, ma una volta presa l’abitudine è un vero piacere.
.m

I tool interni: santi subito

Ho sempre pensato che lo sviluppo di tool interni finalizzati a migliorare e rendere sempre più friction-less il processo di sviluppo siano una delle chiavi per il successo, ma tutte le volte che leggo o sento certi numeri impallidisco:

Before we move on to UI testing for Visual Studio 2010, I’d like to share a few numbers that represent the scale of automated UI regression testing for Visual Studio 2008.

• Visual Studio 2008 had ~65,000 automated UI regression tests at the time of shipping.
• The core UI automation framework (non-Visual Studio specifics) was around ~41,000 lines of code (excluding comments, 175 files)
• The core Visual Studio parts (think tool windows, editors, projects etc.) of the UI automation framework was around ~147,000 lines of code (excluding comments, 763 files)
• On top of the core Visual Studio parts was built an additional layer of product features (Data tools, Debugger, Deployment, DLinq, Test Tools, Office Tools, VSSDK, Smart Devices, Team Foundation, VC, Web Forms, Win Forms and Class Designer) totaling an additional ~400,000 lines of code (excluding comments, 1840 files)

Fonte: http://blogs.msdn.com/visualstudio/archive/2010/03/30/wpf-in-visual-studio-2010-part-6-automated-ui-testing.aspx
.m