Let’s play tennis, with TDD

TDD & Code Kata’s

Now I’m working since more than four months as a software engineer at bbv Software Services in Switzerland. Every new employee at bbv needs to attend several courses (bbv Academy) to improve and extend his skills towards a good software developer. After my Scrum Master course, the next one on my schedule was Test Driven Development.

In addition to the theory why TDD, clean code and pair programming is highly desirable the course was accompanied with hands-on code kata’s. For those who don’t know what a code kata is, here is a citation from Wikipedia:

A code kata is an exercise in programming which helps a programmer hone their skills through practice and repetition.

One kata of the course was the Tennis Scorer. The goal was to implement a mechanism, which prints the score of a single game (therefore there are no sets).

Our Referee

The rules given were the following:

  1. A game is won by the first player to have won at least four points in total and at least two points more than the opponent.
  2. The running score of each game is described in a manner peculiar to tennis: scores from zero to three points are described as “love”, “fifteen”, “thirty”, and “forty” respectively.
  3. If at least three points have been scored by each player, and the scores are equal, the score is “deuce”.
  4. If at least three points have been scored by each side and a player has one more point than his opponent, the score of the game is “advantage” for the player in the lead.

Our implementation should be based on the ITennisScorer interface, which of yourse was changed during the exercise.

</span>
<pre>namespace Tennis
{
    public interface ITennisScorer
    {
        void AchievesScore(Player player);

        string GameScore { get; }
    }

    public enum Player
    {
        PlayerA,
        PlayerB
    }
}

Because it was a TDD course, we needed to build up a TODO list of appropriate unit tests first (e.g. Game just started, no one scored so far, expected score “love”).

Then we implented the unit tests one by one. Each of them had to fail first. Then came the actual implementation, test should pass afterwards. Code Refactoring -> All tests should pass.

Our Players

My initial implementation was blotched with many if statements, handling all the special cases for the game score (deuce, advantage, …). I also had code duplication, because I needed to track and update the score of player A and B separately.

But here comes the ultimate advantage of TDD. You’re not afraid anymore to refactor your code to a better architecture and solution. Because you know you can (and should) always run your unit tests and see if everything is still behaving as desired. You can sleep comfortably without to fear the next morning from an upcoming design change. Ok, I know. Some can still sleep during the nights without TDD, but they will be haunted by bad dreams ;)

So I refactored my code and eliminated the code duplication. Instead of using an enum to track the actual player score, I simply use a two-dimensional array, which holds all the possible scores of a game.

namespace Tennis
{
    public class TennisScorer : ITennisScorer
    {
        private int scoreA;
        private int scoreB;

        private const string GameA = "gameA";
        private const string GameB = "gameB";
        private const string AdvantageA = "advantageA";
        private const string AdvantageB = "advantageB";

        private static readonly string[][] PlayerScores = new[]
            {
                new[] {"love",  "15:0",     "30:0",     "40:0",     GameA},
                new[] {"0:15",  "15:15",    "30:15",    "40:15",    GameA},
                new[] {"0:30",  "15:30",    "30:30",    "40:30",    GameA},
                new[] {"0:40",  "15:40",    "30:40",    "deuce",    AdvantageA},
                new[] { GameB,   GameB,     GameB,      AdvantageB}
            };

        public void AchievesScore(Player player)
        {
            switch (player)
            {
                case Player.PlayerA:
                    UpdateGameScore(ref scoreA, ref scoreB);
                    break;
                case Player.PlayerB:
                    UpdateGameScore(ref scoreB, ref scoreA);
                    break;
            }
        }

        public string GameScore
        {
            get { return PlayerScores[scoreB][scoreA]; }
        }

        private void UpdateGameScore(ref int playerToAddScore, ref int opponentScore)
        {
            if (GameScore == AdvantageA || GameScore == AdvantageB)
            {
                opponentScore--;
            }
            else if (GameScore != GameA && GameScore != GameB)
            {
                playerToAddScore++;
            }
        }
    }
}

The Regulating Authority

I also refactored my unit tests. There were many tests, testing all the possible game processes. But my course instructor gave me the hint to use Nunit’s RowTest. Instead of writing many, almost identical tests for each case, I wrote just one parametrized unit test and the many case were provided as a parameter.

namespace Tennis.Test
{
    using NUnit.Framework;
    using FluentAssertions;

    [TestFixture]
    public class TennisScorerTest
    {
        private TennisScorer testee;

        [SetUp]
        public void SetUp()
        {
            testee = new TennisScorer();
        }

        [TestCase("", "love")]
        [TestCase("A", "15:0")]
        [TestCase("AAB", "30:15")]
        [TestCase("AAAB", "40:15")]
        [TestCase("BBB", "0:40")]
        [TestCase("BBB", "0:40")]
        [TestCase("ABABAB", "deuce")]
        [TestCase("AAABBB", "deuce")]
        [TestCase("AABBAB", "deuce")]
        [TestCase("AAABBBA", "advantageA")]
        [TestCase("AAABBBB", "advantageB")]
        [TestCase("AAAA", "gameA")]
        [TestCase("AAAAA", "gameA")]
        [TestCase("AAAABBBBBB", "gameA")]
        [TestCase("AAABBBBB", "gameB")]
        [TestCase("ABABABABABABABABABABABAA", "gameA")]
        public void PlayerScores(string game, string expectedScores)
        {
            foreach (var currentScore in game)
            {
                switch (currentScore)
                {
                    case 'A':
                        testee.AchievesScore(Player.PlayerA);
                        break;
                    case 'B':
                        testee.AchievesScore(Player.PlayerB);
                        break;
                }
            }
            testee.GameScore.Should().Be(expectedScores);
        }
    }
}

References & Coaches

If you want to practice your programming skills, I can encourage you to do some code kata’s, or similar challenges, to stay fresh in your head.

Here is a list of some useful sites with some brain-teasers and, if given, their solutions:

My Tennis Scorer implementation is available on GitHub.

Category: C#, Coding  Tags: , ,  One Comment

Hirnzellen knacken beim Möbelpacken

Wer braucht schon Sudoku?

Also ehrlich. Wer braucht schon diese Rätselheftchen, die man im Kiosk für knapp 2 Franken kaufen kann.
Wer seine Gehirnmasse trainieren will, der kann uns das nächste Mal beim Zügeln helfen :-)

Da gibts nämlich die kniffligsten Aufgaben

Wo waren schon wieder diese IKEA Anleitungen…?

  • Aah, da sind sie ja. Wo sind aber die 64 Schrauben für die Schranktüren?
  • Warum musste ich mir einen überdimensionierten Schrank kaufen. Das Zeug kann man ja nur in senkrechter Position aufbauen.
  • Zwischen den Lippen finden 13 Schrauben Platz (Anzahl kann je nach Grösse der Klappe variieren)

Wie transportiere ich ein Sofa mit dem Lift?

  • Gar nicht! Blöder Pythagoras. Die Rechnung ging gar nicht auf.

Das Bett heisst Hopen, quietscht aber beim Poppen. Schlage IKEA vor diesen Namen zu ändern.

Ah ja, die Lampen. Kein Problem, kaufen wir doch neue. So energiesparende. Sind ja momentan ganz im Trend:

  • Ähm… ja. Energiesparlampe, stromsparende Halo Eugen Lampe, LED, Leuchtröhre.
  • 11 Watt entspricht 68 Watt. 764.4657 Lumen, kalt, warmweiss, blau, gelb (ist ja ein ganzer Farbkasten hier)
  • Leuchtet sofort 100%, manche erst nach 30 Sekunden (als ich sie anschloss leuchteten sie gar nicht)
  • Hält 2 Jahre, 6 Jahre, sogar 25 Jahre (will mal sehen wer so lange die Garantie aufbewahrt)

Strom und so

  • Phasenprüfer: Egal ob der Schalter auf ON oder OFF ist, der blöde Prüfer leuchtet andauernd.
  • Holen wir ein Multimeter: Wieso fliessen 78 Volt wenn der Schalter auf OFF ist?
  • Bohrmaschine läuft nicht wenn die Sicherungen draussen sind.
  • Sind diese Handschuhe gegen Stromschläge gedacht?
  • Im Wohnzimmer fehlt ein Draht. Man kann keine Lampe mit einem Draht anschliessen. Oder haben wir Wireless Strom verpasst?
  • 650 Watt Bohrmaschine reicht nicht um Löcher in die Decke der Küche zu bohren. Liebe Nachbarn: Wir bitten um Entschuldigung für die 40 Minuten um drei Löcher zu bohren.
  • Der Null-Leiter ist der blaue Draht, bei alten Systemen der braune Draht. Bei Conforama Lampen anscheinend der rote Draht.

Hausratversicherung

  • Befindet sich in der Nähe von 100 Metern ein Hydrant? Was weiss ich?!? Die Feuerwehr ist grad um die Ecke, reicht das?

Was ist der maximale Winkel beim Verlegen vom Netzwerkkabel, damit die Elektronen nicht aus der Kurve schiessen?

Wieviel 20 Räppler brauche ich um die Kochwäsche vollständig durchlaufen zu lassen?

Die absolute Knacknuss?

100 Punkte gehen an die gekaufte Lampe von Thailand.
Ich brauchte 1:20h um eine 30-teilige Lampe zusammenzubauen. Hey, immerhin eine halbe Stunde weniger als beim Lucerne Marathon.
Und ohne Fehler, musste nie von vorne anfangen. Hab mir auch schön viel Zeit genommen bzw. nehmen müssen.
Mein räumliches Denkvermögen hat sich vermutlich um 687% verbessert.

Seht aber am Besten selbst wie das Kunstwerk nun aussieht.

Category: Fun  Tags: ,  2 Comments

Debug- und Testcode haben nichts im Release zu suchen

Jaja, da hab ich mir doch die Sunrise Mein Konto App von Google Play runtergeladen. Mit der App kann man unter sein eigenes Sunrise Konto zugreifen und dabei laufende Kosten, Inklusivleistungen und Rechnungen der eigenen Produkte einsehen. Es ist wirklich eine gute App, teilweise umständlich zu navigieren aber ansonsten ist alles ersichtlich was man an Kontoinformationen braucht.

Und Windows Phone 7?

Da dachte ich mir doch: Hey, eine solche App muss ich auf dem Windows Phone 7 auch haben. Aber leider Fehlanzeige. Für WP7 gibts von Sunrise noch keine App.
Ja gut, dann schreib ich doch selber eine Sunrise Mein Konto App fürs WP7.

Doch so einfach ist das nicht: Die Verbindung zwischen App und Server ist mit SSL gesichert. Ich habe keine Ahnung welche Services (REST, SOAP?) an welchen Endpunkten aufgerufen werden. Was für Daten und in welcher Form (JSON, XML?) diese übertragen werden. Wie läuft der Login Vorgang, HTTP Authentication, GET/POST Variablen, selbstgemachtes Gemüse? Hier wurden die Hausaufgaben gut gemacht, der Datenverkehr ist verschlüsselt.

Aber ich möchte dennoch herausfinden was so vor sich geht. Machen wir doch eine Man in the Middle Attacke mit dem Emulator. Dafür werde ich meine persönlichen Login Daten opfern müssen.
Das Übliche halt:

  • Meinen PC als Proxy dazwischenschalten, am Besten mit Charles Web Debugging Proxy
  • Lokales Zertifikat erstellen wo www1.sunrise.ch als Common Name eingetragen ist
  • Das “Sunrise” in den Zertifikatsspeicher des Emulators oder eines echten Android Gerätes (Root Zugriff erforderlich) installieren
  • Applikation auf Emulator oder Android Gerät laufen lassen und mit LogCat zugleich noch den Output der App aufzeigen

Aber ich bin gerade auf Wohnungssuche, habe also keine Zeit und brauche eine schnellere Lösung ;)

Hey App, lass mich rein, ich bin Entwickler

Meine Faulheit muss ja bekanntlich belohnt werden. Und das wurde ich auch. :-D
Ich wollte sehen ob die App irgendwelchen Debug Output an LogCat sendet und habe die offizielle App von Google Play runtergeladen. Der Output war jedoch minimal. Einige Standardmeldungen wie “Login successful” kamen heraus aber nichts Auffschlussreiches über die Internals der App.

Also habe ich mich etwas am APK File zu schaffen gemacht. Mit dem APK MultiTool die App dekompiliert, und anschliessend das AppManifest.xml in Klartext geöffnet.
Folgendes ist mir aufgefallen:

  1. android:debuggable=”true” ist nicht gesetzt. Ist auch gut so, ist ja schliesslich ein Release und keine Debug Version.
  2. Eine Activity mit Namen Administration ist registriert. Lässt vermuten, dass es irgendwo in der ofiziellen App einen ServiceDialog o.ä. gibt.
Also schön das Debug Flag setzen und die XML Datei speichern. Mit dem APK MultiTool die “modifizierte” Applikation wieder in ein APK File builden und anschliessend noch erneut signieren.

Oh, ich bin ja schon drin

Und wer hätte das gedacht: Die Debug Statements wurden alle schön brav mit in die ofizielle App kompiliert. LogCat spuckte fröhlich alle möglichen Statements raus. JSON Objekte und Inhalt, Hostnamen und Pfade der jeweiligen Services, Login Infos uvm.

LogCat Output

Debug Infos im LogCat Output

Nun gut, aber was ist mit der registrierten Administration Activity? War nicht schwer herauszufinden. Sobald man im Login Screen ist, einfach mal den “Search” Button drücken (F5 im Emulator) und schon kommt man ins Service Menü, oder sollte ich besser sagen in den Test Dialog? Das neue APK File auf mein Android Gerät installiert. Übrigens: Die App lässt sich auch installieren, wenn “Installation von Nicht-Market Anwendungen zulassen” deaktiviert ist.

Fazit

Service Dialog

Service Dialog

Es ist nichts sensitives ans Tageslicht gerückt. Ich habe weder Zugriff auf vertrauliche Kundendaten erhalten oder sonstige Hinweise auf sicherheitskritische Bereiche. Da haben die Entwickler der App gute Arbeit geleistet.

Aber dennoch sollte man darum bemüht sein Debug Informationen, Testdaten, Testabläufe und sonstige interne Informationen nicht in den offiziellen Release zu veröffentlichen. Solche Daten verschwenden nicht nur zusätzlichen Speicher auf dem Phone, sondern sie können sicherheitskritische Informationen an jedermann preisgeben.

Testabläufe sollten auch möglichst mithilfe von Tools und Unit Tests vorgenommen werden und nicht mit echten Testern, welche auf Test Screens mit den Fingern herumdrücken. Solche Tests sind nicht immer einfach. Dies resultiert auch oft daraus, dass eine Entkopplung vom User Interface und der Business Logic nicht einfach zu bewerkstelligen ist. Ein guter Ansatz um eine gute Entkopplung zu erzielen und somit die Applikation “testbarer” zu machen wäre das Model View ViewModel (MVVM) Pattern.

Ich persönlich freue mich sehr über die ganze Sache. Dadurch habe ich genug Einblicke bekommen um meine Windows Phone App zu entwickeln. Die Authentisierung läuft über HTTP POST. Die Session wird mittels eines Login Keys, welcher vom Server zugewiesen wird, identifiziert und die Daten werden im JSON Format vom Server zurückgesandt.

Category: android, Coding  Tags: , ,  Leave a Comment

Biken nach der langen Reisepause

Cannot open XML data file: http://blog.antoine.li/files/2012/09/19092012_luzern_glaubenberg.gpx