Visual Studio 2010, Unit Test, MVC, Exception, Security, Farm, C#, Linq, Extension Methods, ASP.NET 4.0, Mobile, Friends, SharpTestEx, OT, Provider, Performances, Ottimizzazione, Dexter, ASP.NET

Molto probabilmente ne avranno parlato in tanti, ma scopro solo ora che in Visual Studio 2010 è possibile eseguire più Unit Test contemporaneamente se si ha a disposizione una o più CPU MultiCore; ma partiamo con ordine e vediamo come nasce questa esigenza e in quali casi tale approccio può aiutarci.
Dato il continuo aumentare dei test in Dexter, alcuni dei quali impiegano un tempo piuttosto alto (es: gli Smock Test, che verificano il funzionamento di tutte le skin e dei metodi asincroni), mi sono chiesto se era possibile far sì che l’esecuzione di tutti questi test non fosse seriale ma parallela, in modo da ridurre il tempo di esecuzione. Fortunatamente “sbingando” un po’ ho trovato questo interessantissimo post che spiega come la cosa sia fattibile con Visual Studio 2010.

I test sono una cosa seria :), e prima di scegliere un approccio del genere è necessario sapere che l’esecuzione parallela dei test richiede che alcune regole siano rispettate, quindi è bene sapere che essa:

• è utilizzabile solo in macchine multi Core/CPU;
• richiede che tutti i test siano Thread Safe;
• è utilizzabile solo per gli Unit Test (quindi gli Smock Test non ne trarrebbero beneficio);
• è utilizzabile solo per i test in esecuzione sulla propria macchina;
• richiede che i Data Adapter siano disabilitati;

Per tutta questa serie di motivi questa opportunità non è attiva di default, e quindi è necessario andare specificare che tutte le regole sopra elencate sono state rispettate e che vogliamo eseguire più test in parallelo.

Per prima cosa è necessario andare a modificare la configurazione dei nostri test e disabilitare i “Data Adapter”; per far ciò è sufficiente fare doppio Click sul file “.testsetting” presente all’interno della nostra solutions: a questo punto dovrebbe aprirsi una finestra come la seguente, dove dobbiamo disabilitare tutte le checkbox presenti all’interno della scheda “Data and Diagnostics”:

Completato questo step è ora necessario modificare nuovamente lo stesso file, ma tramite l’editorXML, in quanto l’opzione che andremo ad impostare non è configurabile tramite la UI presente in Visual Studio.
Quindi click con il destro sullo stesso file e selezione della voce “Open With”, ed a quel punto scelta della voce “XML (text) Editor”; da qui in poi è possibile andare a cambiare la configurazione dei test e modificare il nodo Execution, specificando l’attributo “parallelTestCount” ed impostandogli come valore il numero di Core/CPU che si intende utilizzare per l’esecuzione dei test (impostando 0 come valore, sarà il sistema a stabile il numero di Core/CPU da utilizzare).

A questo punto siamo abili ed arruolati per eseguire UnitTest in parallelo.
VS2010 Rulez!

Ciauz

This entry was posted on Monday, 10 May, 2010 and is filed under .NET . You can follow any responses to this entry through here . You can leave a response.

Linq è senza ombra di dubbio una delle features più belle introdotte da Microsoft in .NET negli ultimi anni (dopo i Generics); sicuramente anche gli Extension Methods hanno il loro fascino agevolando lo sviluppatore nella scrittura del codice. Purtroppo una cosa che mi manca in Linq (ma in realtà è un extension method) è il ForEach per IEnumerable<T>. In effetti c’è la possibilità di utilizzarlo per IList<T> e per le array, ma non per IEnumerable<T>.
Stufo di scrivere il foreach ogni volta, ho deciso di realizzarmi un’extension method che risolvesse il problema :).

Lo snippet seguente mostra la realizzazione:

/// <summary>
/// Eaches the specified enumeration.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="enumeration">The enumeration.</param>
/// <param name="action">The action.</param>
public static void ForEach <T> ( this IEnumerable <T> enumeration , Action <T> action )
{
    Ensure.That ( enumeration ).IsNotNull ( );

    foreach ( T item in enumeration )
        action ( item );
}

Il suo UnitTest (sempre utilizzando SharpTestEx):

[TestMethod]
public void eachTest_with_null_object_shold_throw_argumentNullException()
{
    var mockService = MockRepository.GenerateStrictMock<IFakeClass>();
    ActionAssert.Throws<ArgumentNullException>(() => ((IEnumerable<string>)null).ForEach(x => mockService.FakeMethod("testValue")));
}

[TestMethod]
public void eachTest_with_valid_object()
{
    IEnumerable<string> values = new List<string> { "testValue1", "testValue2", "testValue3" };

    var mockService = MockRepository.GenerateStub <IFakeClass>();

    values.ForEach(mockService.FakeMethod);

    var calls = mockService.GetArgumentsForCallsMadeOn(obj => obj.FakeMethod(null));

    calls [ 0 ] [ 0 ].Should ( ).Be.EqualTo ( "testValue1" );
    calls [ 1 ] [ 0 ].Should ( ).Be.EqualTo ( "testValue2" );
    calls [ 2 ] [ 0 ].Should ( ).Be.EqualTo ( "testValue3" );
}

Ciauz

This entry was posted on Tuesday, 13 April, 2010 and is filed under .NET . You can follow any responses to this entry through here . You can leave a response.

Ultimamente, lavorando in Dexter, ho deciso di metter su un po’ di test; diciamo pure che le buone intenzioni ci sono, e come prima cosa ho deciso di testare tutto ciò che di nuovo introduco (al momento ho messo solo 108 test, ma spero aumentino velocemente). Ovviamente primo test primo “problema” :). Come prima cosa avevo la necessità di testare un metodo tipo il seguente:

public class Foo
{
    public void TestMethod(string value1, string value2, string value3)
    {
        if (string.IsNullOrEmpty(value1))
            throw new ArgumentNullException("value1");

        if (string.IsNullOrEmpty(value2))
            throw new ArgumentNullException("value2");

        if (string.IsNullOrEmpty(value3))
            throw new ArgumentNullException("value3");

        //DO SOMETHING
    }
}

ed il primo test era una cosa tipo questa:

[TestMethod()]
[ExpectedException(typeof(ArgumentNullException))]
public void TestMethodTest()
{
    Foo foo = new Foo();
    foo.TestMethod(null,null,null);
}

Il problema era legato alle eccezioni, nello specifico volevo verificare che, nel caso i parametri fossero nulli, venisse sollevata l’oppurtuna ArgumentNullException. Detto così nessun problema, basta inserire l’attributo ExpectedException (come mostrato nel codice precedente) ed il gioco è fatto. Però la cosa che non mi piace è che, ipoteticamente, io potrei non avere la certezza che l’eccezione è stata sollevata per il primo, il secondo o il terzo parametro (nel caso fossero tutti e tre nulli) e, per esserne sicuro, devo verificare il ParameterName dell’eccezione.
Purtroppo l’attributo di MSTest non permette di specificarlo, così ho avuto tre idee:

• Metto un try/catch nel test e verifico manualmente il ParameterName;
• Creo un attributo custom che permette di specificare l’eventuale parametro;
• Chiamo Gian Maria che sicuramente ha affrontato il problema;

Sono bastati 5 secondi e la terza opzione si è concretizzata e, su suggerimento del buon Alkampfer, ho deciso di provare SharpTestEx del buon Fabio Maulo. Devo dire che la prima impressione è ottima: l’utilizzo Fluent è molto comodo, in più lo stesso Framework può essere utilizzato non solo con MSTest, ma anche con NUnit, xUnit, MbUnit.
Ovviamente il consiglio di Gian Maria non poteva che essere ottimo, ed il problema si è risolto molto velocemente:

[TestMethod()]
public void TestMethodTest2()
{
    Foo foo = new Foo();
    ActionAssert.Throws<ArgumentNullException>(() => foo.TestMethod("prova", null, "prova2"))
                            .ParamName
                            .Should ( )
                            .Be
                            .EqualTo("value2");
}

Molto probabilmente SharpTextEx sarà il mio Framework di testing per un po’, anche se mi riservo di provare TypeMock per effettuare UnitTest sulle WebForms.
Ciauz

This entry was posted on Wednesday, 07 April, 2010 and is filed under .NET . You can follow any responses to this entry through here . You can leave a response.