I didn’t know the answer myself, although I presumed the function gets called only once. Interestingly, the PHP Manual doesn’t say a word about this question.

So, what’s the answer? The function gets called only once, as I suspected. Here’s the output of the code above:

1. call to getArray
ForEach: 1
ForEach: 2
ForEach: 3

The Unit-Tests that can be run by NUNIT are subprograms and need to have the following structure. As you can see, the fixture’s and tests’ names are simply plain text to allow strings that are longer than 32 characters (the longest possible name for a Natural module) to provide meaningful names as in Behaviour Driven Development. The TestCases are parsed by NUNIT for this structure to make sure that all the needed parameters, subroutines etc. are available. To create a new TestCase all you have to do is copy the example source code and change the names and the implementation of the tests in the IF-branches.

The following diagram shows NUNIT’s architecture. I tried to make the adaption of NUNIT to a different platform than ours (Solaris with Natural modules saved in the file system) as easy as possible and encapsulated the OS-specific implementation into two modules that need to be changed accordingly. I have also included some basic assertions like ASSERT-NUM-EQUALS, ASSERT-STRING-EQUALS and ASSERT-ARRAY-EQUALS and some example TestCases in the source code you can download below.

The TestCases’ names are defined in a user-specific workfile in the home directory (in the current configuration, but this may be changed e.g. to a DB READ). A run of all defined TestCases is as simple as calling the main program NUNIT and produces an output like the following (even with a “red bar” ).

Notice the nice failure/error messages including the module names, line numbers etc.

I developed NUNIT by applying TDD which means the framework tests itself. After you “installed” it (which means importing the NUNIT modules into a library of your choice, preferably a steplib if you plan on using it throughout your application) you can run a simple TESTNU to make sure NUNIT behaves as expected.

All NUNIT modules include a detailed header comment so they should be pretty self-explanatory. But in fact, all you need to start are the programs TESTNU, NUNIT and NUSINGLE (with which you can run a single TestCase) and a TestCase like TCEXMPL1. Just try it out and let me know if you like it

Downloads

• NUNIT’s source code (including intermediary versions as described in the thesis)
• The part of my Master’s thesis about the development of NUNIT (German)

The problem with mocking System.Net.Sockets.Socket is that it implements no abstract interface and is also sealed (which means you cannot derive from the class). Therefore, you cannot mock the class directly with RhinoMocks (which otherwise would be able to mock the class directly without the need for an interface). So we have a (framework) class to whose source code we have no access (which we would need to add something like Socket : ISocket) and from wich we cannot derive a new class. How do we mock such a seemingly isolated class?

First of all, we need a common interface that we can use for mocking. The problem is that we have to make sure Socket implements this interface (let’s call it ISocket). How do we do that? We find a possible answer to that question in the GoF design patterns catalog:

The adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. (Wikipedia)

So we have to create an adapter class that implements ISocket and simply delegates all calls to its methods to an instance of Socket. Then we make sure FTPConnection uses the adapter class (or rather ISocket) instead of Socket directly and provide a constructor through which we can inject our own implementation of ISocket (e.g. the mocked one) as shown in the following class diagram.

It is quite a bit of effort to mock the Socket class (you have to define every needed method in ISocket and implement the delegation in SocketAdapter) but it definitely pays off! The resulting design is less coupled due to FTPConnection depending on ISocket instead of Socket directly and can be tested easily by providing a mocked socket that simulates valid or invalid FTP server responses. Examples of how to simulate FTP calls and responses using RhinoMocks are included in my example project below.

Example project in C#

I have created a small console application in C# according to the second class diagram above which demonstrates the mocking of System.Net.Sockets.Socket and produces the output shown in the following screenshot.

You can download the project here:

• MockASocket (Visual Studio 2008 project including executables and needed DLLs)

• Hochzeitsfotos auf Bali (”normales” Blog)
• Hochzeitsfotos auf Bali (Hochzeitsblog)

Einige Fotos kann man (in hoher Auflösung) bei Flickr bewundern: Fotostream von michaelstange (26.10.2009).

Und ein paar davon gibt es auch hier zu sehen. Kommentare sind erwünscht

Es war wirklich sehr heiß bei 35° Grad im Anzug und Kleid, obwohl man das auf den Bildern dank Puder nicht sieht

Das grüne Tuch, das z.B. auf dem vorletzten Bild zu sehen ist, ist ein Sarong. Den muss man auf Bali tragen, wenn man den mittleren Hof eines Tempels (in diesem Fall der Tempel im Monkey Forest) betreten möchte. Da der untere Teil des Körpers dort als unrein gilt (bzw. den Dämonen nahesteht), muss er durch den Sarong bedeckt und durch einen Gürtel vom oberen Körper abgegrenzt werden.

Die Affen im Monkey Forest heißen Makaken (wie passend zu meinem Namen ) und einer von ihnen hat hartnäckig versucht, die Perlen vom Kleid abzuknabbern, was ihm bei einer auch tatsächlich gelungen ist. Ansonsten waren die Affen aber friedlich und faul.

Sehr witzig war, dass Julia Roberts an dem Tag, an dem wir die Fotos gemacht haben, auch im Monkey Forest war (allerdings erst nachmittags als wir schon weg waren) und die einheimischen Besucher sie mit Jaqueline verwechselt haben, weshalb sie fast mehr Fotos von ihr gemacht haben als Michael. Wir Europäer/Amerikaner sehen für die Balineser wohl alle so “gleich” aus wie sie für uns

Diese sorgt dafür, dass in die *.bbl-Datei die entsprechende Auszeichnung in die \bibitems eingetragen wird: In der Funktion output.bibitem musste der Output "\bibitem[" lediglich durch "\bibitem[\scshape{}" ersetzt werden.

Und schon sehen die Zitate aus wie hier:

Meine drei aktuellen Favoriten im .NET-Umfeld sind die folgenden Bücher:

1. The Art of Unit Testing von Roy Osherove.
   Kurz und knapp: das Buch hat alles, was man zum Thema Unit-Tests mit .NET wissen muss. Es ist meiner Meinung nach aktuell die praxisnahste Einführung in das Thema Unit-Tests und enthält von einer lockeren Einführung, über die Eigenschaften guter Tests bis hin zu Mocking-Frameworks und testgetriebener Entwicklung alle Kernthemen aus dem Bereich der automatischen Software-Tests.
   Wer sich einen Eindruck vom Autor verschaffen will, kann dies u.a. in Form eines Podcasts bei Hanselminutes oder als Video von der TechEd tun.
2. C# 3.0 Design Patterns von Judith Bishop.
   Wer sich in das Thema Entwurfsmuster einarbeiten will, kommt normalerweise nicht um das altbekannte Buch der Gang of Four herum. Allerdings hat es nun mittlerweile 14 Jahre auf dem Buckel. Judith Bishop schlägt in ihrem Buch die Brücke zwischen den altbewährten Design Patterns und den Sprachmöglichkeiten in C# 3.0. Sie zeigt, wie sich die Muster im Stile von .NET umsetzen lassen und liefert dafür sehr anschauliche Beispiele. Auch für Einsteiger ins Thema ist das Buch gut geeignet, allen anderen zeigt es vielleicht interessante moderne Ansätze zur Implementierung der langjährigen Pattern-Wegbegleiter.
3. Clean Code: A Handbook of Agile Software Craftsmanship von Robert C. Martin.
   Ok, etwas geschummelt. Das Buch hat erstmal nichts mit .NET zu tun. Aber ich halte Clean Code für ein so wichtiges Buch, dass es einfach auf diese Liste gehört. Nicht umsonst haben Ralf Westphal und Stefan Lieser (deren Vortrag ich mir übrigens nächste Woche in Bremen anhöre) ihre Initiative Clean Code Developer nach diesem Buch benannt. Es enthält so viele wichtige Tipps für Entwickler (egal welcher Programmiersprache), dass ich gar nicht weiß, wo ich anfangen soll. Aber wahrscheinlich ist das Buch eh ein alter Hut für die meisten Leser, oder?

So. Das waren meine Top 3. Vielleicht ist ja was Interessantes dabei oder es hagelt Kritiken, warum ich ausgerechnet diese Bücher ausgewählt habe… Wie auch immer, Kommentare sind ausdrücklich erwünscht

Außerdem soll im kommenden Jahr ab dem 01. August 2010 wieder ein/e Student/in der Wirtschaftsinformatik in Kooperation mit der BA Emsland ausgebildet werden. Bei der ALTE OLDENBURGER wird bei diesem dualen Studium die Ausbildung zum Fachinformatiker Anwendungsentwicklung absolviert, während das Studium in zehnwöchigen Praxisphasen an der BA Emsland in Lingen stattfindet.

Die Kontaktdaten für die schriftlichen oder elektronischen Bewerbungsunterlagen gibt es hier: Stellenangebote bei der ALTE OLDENBURGER.

Dann also mal nichts wie ran an die Bewerbung und vielleicht sind wir bald Kollegen

• korrekt: Die Test müssen in sich fehlerfrei sein und zu den Anforderungen passen.
• schnell: Die Tests müssen schnell laufen, um häufig durchgeführt werden zu können.
• abgeschlossen: Die Tests müssen ein klares Ergebnis liefern und dürfen keine Interpretation benötigen.
• isoliert: Die Tests müssen unabhängig von anderen Tests durchführbar sein und dürfen andere Tests nicht beeinflussen.
• sprechend: Die Tests sollten ihre Absicht durch sprechende Benennung kundtun (wie etwa beim BDD).
• wartbar: Die Tests sollten den Regeln für sauberen Code folgen und sich leicht an den veränderten Produktivcode anpassen lassen.
• begrenzt: Die Tests sollten jeweils nur einen kleinen Bereich des Testobjekts prüfen (und nicht etwa mehrere Methoden gleichzeitig).
• einfach durchführbar: Die Tests müssen so einfach wie möglich (am besten auf Knopfdruck) durch einen beliebigen Entwickler durchführbar sein.

Wer hat noch mehr zu bieten?

Quellen

• Roy Osherove: The Art of Unit Testing. Manning Publications, 2008.
• Michael Feathers: A Set of Unit Testing Rules. 2005.
• Kent Beck: Test-Driven Development: by Example. Addison-Wesley, 2003.
• Klaus Meffert: JUnit Profi-Tipps. Entwickler.Press, 2006.
• David Astels: Test Driven Development: A Practical Guide. Prentice Hall International, 2003.
• Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR, 2008.
• Arie van Deursen et.al.: Refactoring Test Code. Proceedings of the 2nd International Conference on Extreme Programming and Flexible Processes in Software Engineering, 2001.

Die übliche Literatur dazu sollte inzwischen allgemein bekannt sein. Wenn nicht, erfolgt hiermit der absolute Lesebefehl

• Presentation Zen von Garr Reynolds
• Slide:ology von Nancy Duarte
• Made to Stick von Chip und Dan Heath

Wer sich nicht gleich alle Bücher zulegen will, kann auch erstmal mit dem Vortrag von Garr Reynolds bei Google anfangen: Authors@Google: Garr Reynolds. Da wird schon so ziemlich alles beschrieben, worauf es bei Präsentationen ankommt.

Handout zum Vortrag

Mein Handout zum Vortrag gibt es hier: Tod durch PowerPoint.

Es fasst die Oberpunkte meines Vortrags zusammen:

• Warum unsere bisherigen Präsentationen in den Müll gehören
• Wie kann man es besser machen?
• Wie entwickle ich meine Präsentation?
• Design der Folien
• Tipps für den Vortrag