Dariusz quatscht : Testing

TechTalk Dezember 2009: Anwendungsentwicklung mit Visual Studio 2010

dparys — Fri, 31 Jul 2009 12:05:52 GMT

Erst im Juni habe ich einen TechTalk hinter mir und schon steht mein nächster an. Dieses mal jedoch nicht über einen Monat gezogen sondern in einer Woche werden 5 Städte besucht und mein Kollege Christian Binder wird auch mit von der Partie sein.

In Visual Studio 2010 kommen so viele neue Elemente dazu das wir einfach in diesem TechTalk verschiedene Aspekte live im Coding demonstrieren wollen und auf hoffentlich viele Fragen eingehen dürfen. Ganz nach dem Motto: “Keine Slides! Nur Code!”

Hier der Auszug von der MSDN TechTalk Anmeldeseite:

Der letzte MSDN TechTalk in diesem Jahr nimmt Sie mit auf eine Reise zur nächsten Version von Visual Studio: Visual Studio 2010. Dabei werden Christian Binder und Dariusz Parys die interessantesten Aspekte der neuen Entwicklungsumgebung vorstellen: von Verbesserungen in den einzelnen Frameworks bis hin zu neuen Möglichkeiten in den Application Lifecycle Management Tools, die das Testen und die Entwicklung im Team einfacher machen, wird dieser TechTalk die verschiedenen Aspekte mit Hilfe von Live Codings demonstrieren. Das heißt ganz klar: Keine Slides! Nur Code!

Die Termine:

An manchen Terminen werden wir vermutlich deutlich überziehen, das dürfte Karlsruhe, Berlin und München sein. In Köln und Hamburg sind wir leider an die Öffnungszeiten des Microsoft Office gebunden.

Ich freue mich schon auf viele Teilnehmer und Fragen, bis dann!

Link: Offizielle TechTalk Anmeldeseite

Tech-Ed 2009 vom 09.11 – 13.11 in Berlin

dparys — Mon, 22 Jun 2009 17:54:21 GMT

Nach langer Pause dürfen wir die Tech-Ed endlich wieder in Deutschland begrüßen. Dieses Mal ist Berlin Gastgeber. Es werden zahlreiche neue Technologien vorgestellt und nach Jahrelanger Trennung von IT-Pros und Developern wieder ein einwöchiger Event für beide veranstaltet. Themen werden unter anderem Windows 7, Windows Server 2008 R2, Windows Azure und Visual Studio 2010 sein.

Frühbucherrabatte gibt es auf der entsprechenden Webseite

http://www.microsoft.com/europe/teched/

Projekt Blog Poll – Entity Framework Repository

dparys — Mon, 25 May 2009 11:08:42 GMT

Im 4. Teil der Serie zum Projekt Blog Poll geht es nun in die erste Implementierung. Ein Repository soll erstellt werden. Die erste Technologie die ich benutze ist das Entity Framework. Und wie mit jeder neuen Technologie ist auch bei dieser die ein oder andere Fragestellung zu lösen.

Visual Studio 2010 – Historical Debugging

dparys — Wed, 20 May 2009 17:13:06 GMT

Ein weiteres cooles Feature ist die Möglichkeit sich nach dem Testen einer Anwendung in der IDE sich die Debugger Informationen nachträglich zeigen zu lassen. So kann man in aller Ruhe die Exceptions im Nachhinein analysieren und dazu sich die lokalen Zustände anzeigen lassen.

Hier ein Beispiel der Debug History

Selektiert man eine Zeile im Fenster wird der entsprechende Source-Code Bereich angezeigt. Klickt man dann auf die “Related Views” erhält man die Zustände zum Zeitpunkt der Exception im Variablen Fenster angezeigt

In den Einstellungsoptionen kann man sich noch mehr Informationen sammeln lassen, was sich natürlich auf die Performance der Anwendung auswirkt.

Zum Fehlersuchen auf jeden Fall ein hilfreiches Tool.

Improving Entity Framework Performance

dparys — Mon, 06 Apr 2009 10:48:20 GMT

I was really shocked when I saw this blog post: Entity Framework and LINQ to SQL Performance. I decided to download the performance test solution and try the tests myself. I did not changed any of the tests so far, I just added for my own interest NHibernate into the game as I think that it is the choice of Frameworks for Domain Driven Design.

So, I was shocked again, as I saw my numbers in the chart:

The elapsed time was 4 times higher than with plain SqlDataReader. But more worse was the fact the the elapsed processor time was nearly 8 times higher. NHibernate was really good in performance compared to Entity Framework, but LINQ to SQL was still better.

What was wrong? I couldn’t imagine that we had such an issue in data access using the Entity Framework. I took a look at the code. All test runs are looping 10000 times over the access method to retrieve the customers data. In this loop, each time a connection will be created and closed. Linq to SQL and Linq to Entities are using compiled queries, so, this optimization was already done. I also added in my tests a pre-generated Entity Framework view (using edmgen.exe) to enhance startup performance. Still those poor results.

Here is the original code from the tests:

   1: public static List<CustomerResults> GetCustomers()

   2: {

   3:     using (NorthwindEntities ne = new NorthwindEntities())

   4:     {

   5:         return GetCustomersQuery(ne).ToList();

   6:     }

   7: }

8:

   9: private static Func<NorthwindEntities, IQueryable<CustomerResults>>

  10:     GetCustomersQuery = CompiledQuery.Compile(

  11:         (NorthwindEntities ne) => from c in ne.Customers

  12:                                   select new CustomerResults

  13:                                   {

  14:                                       CustomerID = c.CustomerID,

  15:                                       CompanyName = c.CompanyName,

  16:                                       ContactName = c.ContactName,

  17:                                       ContactTitle = c.ContactTitle,

  18:                                       City = c.City,

  19:                                       Country = c.Country

  20:                                   });

My guess was that the instantiation of the connection string could be the problem. Why? Because several things happen here. First, the EntityConnection which is created when not specifying any argument in the constructor of the typed object context class NorthwindEntities, has to read from the config file. I/O cost. Second, it has to read the metadata information, which is stored by default in the assembly as resource. Second performance cost. Here is my optimization approach. One of the overload constructors is taking an EntityConnection object. Guess what, you probably just use this one connection object during the whole life time of your application, so why not create it once and give it into the constructor. This does not mean that I open the connection beforehand, no, I just create the type EntityConnection and retrieve the meta information in the first call. From that, I reuse this instance, so no need anymore to retrieve the metadata information again.

Here is the optimization in my code base:

   1: private static EntityConnection entityConnection;

2:

   3: public static void InitializeConnectionString()

   4: {

   5:     SqlConnectionStringBuilder sqlBuilder = new SqlConnectionStringBuilder();

   6:     sqlBuilder.DataSource = @"(local)\sqlexpress";

   7:     sqlBuilder.InitialCatalog = "NorthwindPerfTest";

   8:     sqlBuilder.IntegratedSecurity = true;

   9:     sqlBuilder.MultipleActiveResultSets = true;

10:

11:

  12:     EntityConnectionStringBuilder builder = new EntityConnectionStringBuilder();

  13:     builder.Provider = "System.Data.SqlClient";

  14:     builder.Metadata = "res://*/Customers.csdl|" +

  15:                        "res://*/Customers.ssdl|" +

  16:                        "res://*/Customers.msl";

  17:     builder.ProviderConnectionString = sqlBuilder.ToString();

18:

  19:     entityConnection = new EntityConnection(builder.ToString());

  20: }

I have a static variable entityConnection which holds the reference on the object. In the constructor I just pass this reference:

   1: public static List<CustomerResults> GetCustomers()

   2: {

   3:     using (NorthwindEntities ne = new NorthwindEntities(entityConnection))

   4:     {

   5:         return GetCustomersQuery(ne).ToList();

   6:     }

   7: }

Now I have difference numbers to show in my chart:

For this specific test scenario I cutted performance cost two times for the elapsed time and four times for the process elapsed time. Hope that helps.

Behavior Driven Development, Contexts und Specifications

dparys — Thu, 26 Mar 2009 18:33:23 GMT

Ich glaube es ist kein Geheimnis, das ich mich immer schwer getan habe Unit Tests konsequent anzuwenden. Die Vorteile wie von vielen Leuten angepriesen sind mir nicht wirklich als solche Erschienen. Mein Problem war immer das ich kein Gefühl dafür entwickelt habe was und vor allem, bis in welche Tiefe ich testen sollte. Ich habe mich dabei ertappt Unit Tests zu schreiben die mittlerweile komplexer waren als das eigentliche Projekt. Selbst das Lesen verschiedener Bücher wie z.B. xUnit Test Patterns: Refactoring Test Code hat mir nichts gebracht. (Anmerkung: Das Buch kann ich absolut nicht empfehlen, nicht mal als Nachschlagewerk). Kurz, ich hatte kein Gefühl dafür was ein guter Unit Test ist und was nicht.

Insofern habe ich mir einfach mal Zeit genommen und einen Haufen anderen Test-Code angeschaut. Vielmehr durch Zufall bin ich von den Test-Code des Projektes Mass Transit zu verschiedenen Blog Posts gestolpert und siehe da, es gab da etwas was mein Interesse geweckt hat. Behavior Driven Development, genauer gesagt wie dort mit Tests verfahren wird.

Hier die Blog Posts die ich meine:

Getting started with BDD style Context/Specification base naming

Refining Context / Specification BDD using Rhino Mocks 3.5

Jan van Ryswyck’s Implementierung habe ich nun als Grundlage genommen um das ganze mal an einem kleinen Demo Projekt zu testen.

Die Tests lassen sich nun folgendermaßen lesen:

When_retrieving_customer_orders_from_repository_for_customer_ALFKI

Then_should_have_at_least_one_order
Then_should_be_able_to_get_a_list_of_all_products
Then_should_be_able_to_add_a_new_order_with_positions_and_persist_it
Then_should_be_able_to_update_an_existing_order
Then_should_be_able_to_delete_the_first_order
Then_should_be_able_to_update_company_name

Um die Ansicht von Klasse (Context) und TestMethode hierarchisch zu bekommen, muss man in Visual Studio nach der Spalte Class Name gruppieren.

Mittlerweile hat die Beta von Resharper 4.5 auch eine direkte Integration von MSTest.

Das Schreiben der Tests in Bezug auf das Verhalten und dessen Kontext wird nun etwas sein was ich versuchen werde auf meinen zukünftigen Code anzuwenden. Mal schauen wie praktikabel das auf Dauer sein wird.

Test Reviews by Roy Osherove

dparys — Wed, 25 Mar 2009 14:06:23 GMT

Roy Osherove hat auf seinem Blog angefangen Projekte, genauer gesagt deren Unit Tests, zu analysieren und zu bewerten. Besonders ans Herz legen möchte ich einfach mal Test Review #1. Hier geht es um das ASP.NET MVC Beispiel NerdDinner. Es lohnt reinzuschauen.

PEX – Automatisierter Testansatz

dparys — Wed, 17 Dec 2008 12:52:03 GMT

Ich selbst habe PEX das erste Mal auf der PDC 2008 kennengelernt. PEX ist die Abkürzung für Programming EXplorations und ist ein Projekt von Microsoft Research.

Wo kann PEX helfen? Schreibt man Unit Tests so macht man dies in erster Linie um das Objektmodell zu formen, um gängige Abläufe abzubilden und um besondere Fehlererwartungen zu testen. Hat man sich eine Testsuite erstellt so kann man jegliche Änderungen am Code schnell überprüfen und durch Fehlerhafte Tests ist das Feedback eindeutig wo die Probleme aufgetaucht sind.

Ob man nun allerdings den Code in seiner komplettheit testet sei mal dahingestellt. Mechanismen wie Code Coverage helfen einem dabei zu sehen wieviel Prozent der eigentlichen Code Basis getestet worden sind. Ein Wert von 80% ist eine gute Basis um den Code in die Versionsverwaltung einzuchecken. In der Regel ist es jedoch so, das die Unit Tests die man schreibt, oft nur die Ansätze wiederspiegeln, die man beim Design im Kopf hatte. Was noch fehlt ist das lästige suchen nach Fehlern wie Sie in der Regel durch ein “gutmütiges” Nutzen des Objektmodells nicht vorkommen. Die ideale Testabdeckung von Code ist 100%.

Genau hier kann PEX helfen. PEX analysiert den Code und such dediziert nach verschiedenen Fehlerquellen für jeden Programmpfad. Dabei werden die Eingabeparameter für Methoden mit teilweise exotischen Werten ausgestattet um Fehler zu produzieren auf die man normalerweise nicht kommt.

Wie funktioniert PEX?

PEX ist ein Addon für Visual Studio 2010. Für Visual Studio 2008 gibt es auch eine Version, auf Basis einer akademischen Lizenz.

Folgender Sourcecode als Basis:

   1: public bool Validate( CardType cardType, string creditCardNumber )

   2: {

   3:     //

   4:     // Fast path some validation

   5:     //

   6:     if ( creditCardNumber.Length > _maxLength )

   7:     {

   8:         return false;

   9:     }

10:

  11:     //

  12:     // Credit card to validate

  13:     //

  14:     int[] number = new int[ _maxLength ];

15:

  16:     int length = 0;

  17:     foreach ( char c in creditCardNumber.ToCharArray() )

  18:     {

  19:         if ( char.IsDigit( c ) )

  20:         {

  21:             number[ length++ ] = ( int ) c - '0';

  22:         }

  23:     }

24:

  25:     //

  26:     // Validate based on card type

  27:     //

  28:     switch ( cardType )

  29:     {

  30:         case CardType.MasterCard:

  31:             {

  32:                 if ( length != 16 )

  33:                     return false;

  34:                 if ( number[ 0 ] != 5 || number[ 1 ] == 0 || number[ 1 ] > 5 )

  35:                      return false;

36:

  37:                 break;

  38:             }

39:

  40:         case CardType.BankCard:

  41:             {

  42:                 if ( length != 16 )

  43:                     return false;

  44:                 if ( number[ 0 ] != 5 || number[ 1 ] != 6 || number[ 2 ] > 1 )

  45:                     return false;

46:

  47:                 break;

  48:             }

49:

  50:         case CardType.Visa:

  51:             {

  52:                 if ( length != 16 && length != 13 )

  53:                     return false;

  54:                 if ( number[ 0 ] != 4 )

  55:                     return false;

56:

  57:                 break;

  58:             }

59:

  60:         case CardType.AMEX:

  61:             {

  62:                 if ( length != 15 )

  63:                     return false;

  64:                 if ( number[ 0 ] != 3 || number[ 1 ] != 4 )

  65:                     return false;

66:

  67:                 break;

  68:             }

69:

  70:         case CardType.Discover:

  71:             {

  72:                 if ( length != 16 )

  73:                     return false;

  74:                 if ( number[ 0 ] != 6 || number[ 1 ] != 0

  75:                     || number[ 2 ] != 1 || number[ 3 ] != 1 )

  76:                     return false;

77:

  78:                 break;

  79:             }

80:

  81:         case CardType.DinersClub:

  82:             {

  83:                 if (length != 14)

  84:                     return false;

  85:                 if (number[0] != 3 || number[1] != 0

  86:                     && number[1] != 6 && number[1] != 8)

  87:                     return false;

88:

  89:                 break;

  90:             }

91:

  92:         case CardType.JCB:

  93:             {

  94:                 if ( length != 16 && length != 15 )

  95:                     return false;

  96:                 if ( number[ 0 ] != 3 )

  97:                     return false;

98:

  99:                 break;

 100:             }

 101:     }

 102:

 103:     //

 104:     // Use the Luhn algorithm to validate the integrity of the number itself

 105:     //

 106:     int sum = 0;

 107:

 108:     for ( int i = length - 1; i >= 0; i-- )

 109:     {

 110:         if ( i % 2 == length % 2 )

 111:         {

 112:             int n = number[ i ] * 2;

 113:

 114:             sum += ( n / 10 ) + ( n % 10 );

 115:         }

 116:         else

 117:         {

 118:             sum += number[ i ];

 119:         }

 120:     }

 121:

 122:     return ( sum % 10 ) == 0;

 123: }

Und der CardType Enum

   1: public enum CardType

   2: {

   3:     MasterCard = 1,

   4:     BankCard = 2,

   5:     Visa = 3,

   6:     AMEX = 4,

   7:     Discover = 5,

   8:     DinersClub = 6,

   9:     JCB = 7,

  10: }

Diese Routine möchte ich nun mit Unit Tests ausstatten. Ich habe welche in meinem Projekt und erreiche eine Abdeckung über Data-Driven Tests von ca. 67%, noch einige Prozentpunke entfernt von dem selbstgesetzten Ziel von 80%.

Nun benutze ich PEX um den Code zu analysieren und mir eine Test-Suite zu erstellen und dabei auch noch Fehler zu finden die ich vielleicht übersehen habe und nicht Teil meiner bisherigen Test-Suite sind.

Dazu rufe ich PEX über das Kontext-Menü im Source Editor auf:

Danach startet PEX einen Prozess und instanziert die zu testenden Klassen und ruft systematisch in die einzelnen Methoden rein.

Das Ergebnis sind 262 Aufrufe mit einem gefunden Fehler und 40 erstellten Unit Tests.

Und zur Komplettheit noch der generierte Unit Test der für diesen Fehlerfall erzeugt wurde.

   1: [TestMethod]

   2: [PexRaisedException(typeof(NullReferenceException))]

   3: [PexGeneratedBy(typeof(LuhnValidatorTest))]

   4: public void Validate02()

   5: {

   6:     LuhnValidator luhnValidator;

   7:     bool b;

   8:     luhnValidator = new LuhnValidator();

   9:     b = this.Validate(luhnValidator, CardType.BankCard, (string)null);

  10: }

Des Weiteren gibt PEX einem die Möglichkeit , gleich eine Pre-Condition in den Code einzubauen die die Kreditkartennummer auf null prüft und eine ArgumentNullException wirft.

Und mein Ziel 80% Code Coverage zu erreichen?

Die Tests lassen sich abspeichern und entsprechend in die dafür vorgesehene BVT Suite (BVT = Build Verification Tests) integrieren.

Und nach einem weiteren Testlauf im Test View von Visual Studio 2008 mit aktivierter Code Coverage erscheint nun folgendes Resultat für die Validate Methode:

Wow, 100%, mehr als ich wollte. Ein Tool das einen Blick Wert ist!

Die Webseite von PEX und die entsprechenden Downloads findet man hier.

Was sind relevante Themen in der Softwareentwicklung für Sie?

dparys — Wed, 03 Dec 2008 19:19:00 GMT

Lange Zeit bevor ich bei Microsoft war, habe ich schon in diversen Firmen eigentlich immer aus eigenem Antrieb heraus recht schnell Technologie adaptiert und auch während laufender Projekte reingebracht. Den Mehraufwand hat man gerne selbst getragen (oder tragen lassen, Entschuldigung schon mal an dieser Stelle, Ihr wisst wer gemeint ist) um das Projekt / Produkt auf eine neue technische Ebene zu heben. Meist hat sich der Aufwand auch gelohnt.

Seit ich bei Microsoft bin, liegt hier mein Fokus natürlich verstärkt auf die Microsoft Technologie. Ich möchte mal sagen das ich nicht diesen Bias habe über den Ralf Westphal geschrieben hat, aber mein "Abdriften" in andere Technologie Welten ist definitiv geringer geworden.

Warum schreibe ich das eigentlich? Ganz einfach, nach dem Auswerten der Technical Summit Feedbacks ist mir aufgefallen das die Themen kaum Relevanz für die Teilnehmer hatten und ich nicht von mir ausgehen möchte was relevant ist. Was ich wirklich Cool finden würde, wären Kommentare was für Sie relevante Softwareentwicklungsthemen sind.

Mock it up!

dparys — Wed, 28 Nov 2007 13:30:20 GMT

Gestern hatte ich eine Veranstaltung zu Visual Studio Team System und dem Team Foundation Server. Während wir über Unit-Testing gesprochen haben, stellte mir ein Teilnehmer die Frage, ob wir ein Mocking Framework zur Verfügung stellen. Nach einem klaren...(read more)