FizzBuzz Kata mit Javascript

So, heute geht es wieder mal ans Eingemachte. In letzter Zeit merke ich immer wieder, dass mir Übung ziemlich gut tut 🙂

Darum habe ich die allseits beliebte FizzBuzz Kata in Javascript mit dem Jasmine BDD Framework umgesetzt. Wer die Regeln von FizzBuzz nicht kennt, kann sie hier nachlesen.

Meine Ziele waren folgende:

  • Javascript Syntax intuitiver niederschreiben können
  • Testgetrieben entwickeln
  • Das ganze sollte auch noch ein annehmbares Tempo haben
  • Netbeans Shortcuts anwenden (Maus nicht verwenden)

12 Responses

  1. Häsch grad vo de neue 15 Minute Limite vo Youtube profitiert? 😉
    Super sach, so wie’s usgseht häsch dich in chürzeschter Ziit inen Javascript Profi gmauseret.

  2. Jepp, beim ersten Durchgang hatte ich ca. 20 Minuten, darum musste ich nochmal ran. Javascript Profi ist vielleicht übertrieben, aber langsam habe ich die Grundlagen drauf. Die Sprache gefällt mir echt gut.

  3. Interessant, aber war “FizzBuzzSequence” am Ende nicht vollkommen sinnbefreit? Denn tatsächlich hätte es doch nich “1,2,3” zurückgeben sollen, sondern “1,2,Fizz”, oder? Prinzipiell hast du da nur ein Stringjoining getestet aber nicht (wie man es dem Namen nach eigentlich denken würde) deine FizzBuzz Klasse im größeren Rahmen?!

  4. Der Fehler war natürlich nur ein Test, ob die Leser bemerken, ob alles richtig ist 😛

    Nein, im Ernst. Habe den Fehler schon vor ein paar Stunden bemerkt. Vor lauter Turbo programmieren, hab ich die letzte Spec falsch formuliert und dies nachher nicht bemerkt.

    Richtig wäre gewesen (FizzBuzzSequenceSpec):
    it(‘should end with String “98,Fizz,Buzz” in a sequence from 1 to 100’, function () {
    var fizzBuzzSequence = new FizzBuzzSequence(1,100);
    expect(fizzBuzzSequence.getString()).toMatch(“98,Fizz,Buzz$”);
    });

    Und in FizzBuzzSequence wäre folgendes richtig gewesen:
    for (i = start; i <= end; i++) { var value = FizzBuzz.getFizzBuzzValueOf(i); arr.push(value); calculatedString = arr.join(','); } So funktionierts, also sorry für meinen doofen Fehler. Muss noch schauen, ob ich das Video nochmals neu mache und richtig rauflade. Kommt sonst evtl. ein bisschen schräg rüber.

  5. Ich finds in der Version eigentlich ganz spannend, denn es zeigt eine der Tücken von Test Driven Development, die gerne unter den Tisch gefallen lassen werden – das volle Vertrauen in den Test lässt das eigentliche Denken mitunter zurückbleiben.

    Mir ist z.B. auch aufgefallen, dass du bei den letzten Tests von FizzBuzz den Text gar nicht mehr richtig angepasst hast, sondern voll im Copy&Paste Modus warst … und das ist meiner Meinung nach ein schwerwiegendes Problem von TDD. Man verlässt sich voll und ganz darauf, dass es schon in Ordnung ist, solange der Balken nur grün bleibt und programmiert eventuell komplett an dem, was das System EIGENTLICH leisten sollte, vorbei.

  6. Hey m.a. danke für dein wertvolles Feedback. Mein Ziel in der Kata war natürlich Speed, nichts desto trotz, müssen die Anforderungen in den “it” Blöcken natürlich richtig formuliert werden.
    Ich denke in der Realität macht es Sinn, zuerst die Anforderungen Textuell zu erfassen und erst danach diese auszuprogrammieren. Sonst kann, wie du schon richtig bemerkt hast, der copy paste Wahn um sich schlagen.

    Kennst du denn noch mehr Nachteile? Die Vorteile bekommen wir ja ständig auf die Nase gedrückt.

  7. Ich muss zu meiner Schande gestehen, dass ich bisher in keinster weise test driven programmiert habe – ja, bis vor ca. drei Monaten wusste ich nicht mal, dass sowas im Webbereich überhaupt möglich ist. Peinlich, aber die Wahrheit.

    Ich habe vor eines meiner privaten Projekte TD zu bauen, nur um es mal auszuprobieren. Das Hauptproblem das ich dabei sehe, das aber mit hoher Wahrscheinlichkeit auch ein persönliches und kein defacto Problem ist, ist die Frage “wie baue ich überhaupt vernünftige Tests?”.

    Ich denke es ist keine Kunst die üblichen Verdächtigen zu testen und auszuschließen (“Zu groß”, “Zu klein”, “Leerer Wert” etc.), aber die fängt man ja, wenn man nicht gerade mit der Programmierung angefangen hat, sowieso ab … aber Tests für Sachen zu schreiben, die nicht offensichtlich sind, das erscheint mir aus meiner momentanen Position heraus fast wie ein Catch-22.

    Ein weiteres Problem ist natürlich der Zeitaufwand. Ich hab deine obige Kata mal selbst nachgebaut (eigentlich um dieses Jasmine Framework mal zu testen) und während es natürlich spassig ist ein Programm zu haben dass einem mit einem positivem Grün bestätigt “Ja, du hast alles richtig gemacht” habe ich, selbst mit Copy&Paste, für die Tests deutlich mehr Zeit aufgewendet als für das Programm selbst. Wenn ich das auf ein “echtes großes” Projekt extrapoliere schaudert es mich vor dem Aufwand, der da in die Testsuite fliest – besonders im Zusammenhang mit meiner obigen Befürchtung, dass ich zu dämlich bin und sowieso nur Sachen teste die eh klar sind, ergo keinen echten Mehrwert erzeuge.

    Naja, mal schaun was bei rumkommt.

  8. Ich habe TDD schon mal in einer anderen Programmiersprache (4D) getestet, und dort war es mir teilweise sogar eine Programmierhilfe, da ich eine Methode so schon losgelöst vom restlichen Programm testen und auf Anforderungen überprüfen konnte. Wenn ich jedesmal das ganze Programm starten und bis dorthin klicken müsste wo die Methode aufgerufen wird, hätte ich wesentlich länger gebraucht um sie umzusetzen.
    Manchmal macht man sogar unbewusst TDD, indem man sich eine kleine Hilfsmethode zimmert um die Methode zu starten oder es direkt aus der Konsole versucht, nur statt diese im Erfolgsfall wegzuwerfen, bindet man sie bei TDD in ein System ein um es jederzeit automatisiert wieder testen zu können.
    Der Zeitaufwand ist also in gewissen Fällen nicht mal höher.

  9. @m.a.
    zum Thema “mehr Zeit für Tests, als fürs Programm”:
    ja, das ist so, am Anfang des Programms, aber versuch mal sinnvoll zu refaktorieren, ohne eine gute Testabdeckung. Das geht in die Hose, wenn das Projekt nur komplex genug ist. Ich selbst habe auch noch keine große Test-Erfahrung, aber dafür kommt Sebastian Bergmann nächste Woche zu uns in die Firma, also Consultant, und vermittelt uns das ganze 😉

  10. Ich habe (leider) auch erst vor ein paar Wochen mit Unittests (mit phpunit) begonnen. Der Zeitaufwand ist tatsächlich nicht zu unterschätzen. Die richtigen Tests zu finden ist am Anfang von mir aus gesehen wirklich nicht ganz einfach, ich hoffe mit weiterer Erfahrung geht das einfacher von der Hand.
    Ganz wichtig finde ich in diesem Zusammenhang die Code-Abdeckung. Da sieht man, ob beim testen alle if / else / throw … auch mindestens einmal durchlaufen wurden!

Leave a Reply

Your email address will not be published. Required fields are marked *