ESEconf2011 - Arrenbrecht Peter: "Literate Testing: Stimmige API's machen mehr Spass"

  • 327 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
327
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1.
    • “Stimmige APIs kosten weniger.” Peter Arrenbrecht
    • 2. codewise.ch @parrenbrecht
    Literate Testing
  • 3. Wir alle designen APIs
      Prüft Verbessert Einige von uns erklären sie auch Und wir testen sie
    • 4. Ziel des Vortrags
        In diesem Vortrag geht es um das
      • Erklären beim Schreiben von Anleitungen
      • 5. Zeigen anhand von Beispielen
      • 6. Prüfen der Beispiele in Tests
      • 7. Aber eigentlich geht es darum, wie dies die Qualität von APIs verbessert.
    • 8. Kosten eines schlechten APIs
      • Getrieben durch Anzahl Anwendungen
        • Auch in kleineren Teams relevant
      • Schlecht lesbarer Code
      • 9. Fehler in der Anwendung
      • 10. Nachdenken bei jedem Anwenden
      • 11. oder Copy/Paste von Unverstandenem
      • 12. Vertrauensverlust
      • 13. Ein schlecht designtes zentrales API kann eine Code-Basis massiv schädigen!
    • 14. Zitat
      • “ Good tests help you verify your code works , but good documentation forces you to question whether your code makes sense .” @sstephenson
    • 15. Wie hilft das Erklären?
      • Fokus auf Anwender und ihre Bedürfnisse
        • Use Cases, User Stories
      • Erweitert die Perspektive
        • Zusammenspiel von Komponenten
        • 16. Gesamtabläufe
      • Bremst Featuritis
        • Das muss nun auch noch alles erklärt werden
    • 17. Erklären, die Zweite
      • Fördert Zusammenarbeit
        • Reviews der Usability des APIs
        • 18. Vom Thron steigen
      • Macht ehrlich und überzeugend
        • Man muss für seine Arbeit einstehen
        • 19. Speziell in Vorträgen!
    • 20. Wie hilft das Zeigen?
      • Beispielcode erzählt Teil der Geschichte
      • 21. Konsistente und überzeugende Begriffe
      • 22. Prägnanter Anwender-Code
        • Vereinfachtes API für typische Fälle?
      • Kryptische Hacks stechen heraus
    • 23. Was bringen Beispiele?
      • Korrekte und effiziente Verwendung
      • 24. Gleichförmigen Anwender-Code
        • Einfacher zu lesen und zu warten
        • 25. Kann Refactoring des APIs vereinfachen!
      • Feedback
        • Anwender fragen eher nach, wenn ihr Fall nicht abgedeckt ist, anstatt einfach zu wursteln.
    • 26. Was hilft das Testen?
      • Vollständigkeit
        • Kein Händewedeln, keine Abkürzungen
      • Wartbarkeit
        • Beim Refactoring sieht man, wo Text betroffen ist.
      • Nachhaltigkeit
        • Führt beim Refactoring zurück zum Erklären und dem damit verbundenen Nachdenken!
      • Nutzen, der nicht dem API an sich dient:
        • Die Beispiele funktionieren. Immer.
        • 27. Wichtiger Satz von automatisierten Tests
    • 28. Aus der Praxis
      • Excel Compiler: http://formulacompiler.org/
      • 29. Habe umfassende Tutorials geschrieben
        • Führte zu vereinfachten APIs für typische Fälle
        • 30. Zwang zu Gründlichkeit bei komplexen Features
        • 31. Lenkt Anwender zu bewährten Mustern
      • Habe in Vorträgen präsentiert
        • Zeigte Bedarf an weiterer Lenkung auf
    • 32. Techniken
      • Code-First
        • Beispiele direkt als Test
        • 33. Erklärung in Kommentaren im Test-Code
      • Prose-First
        • Erklärung direkt als Textdokument
        • 34. Beispiele eingebettet oder aus Test-Code zitiert
    • 35. Ein Experiment dazu
      • Dokumentierte Erweiterbarkeit von JCite: http://arrenbrecht.ch/jcite/
      • 36. Zuerst mit Code-First fand ich
        • Schlechte Begriffe
        • 37. Schlechte Abstraktionen, die zu Redundanz im Anwender-Code führten
      • Dann mit Prose-First fand ich
        • Noch mehr schlechte Begriffe
        • 38. Sogar solche, die ich mit Code-First gerade eben eingeführt hatte!
    • 39. Vorteile Code-First
      • Einfach und schnell eingerichtet
      • 40. Gut von der IDE unterstützt
      • 41. Anleitungen für Anwender direkt in IDE verfügbar
    • 42. Vorteile Prose-First
      • Leeres Blatt führt zu tieferer Reflexion
      • 43. Fokus auf User Story, Hintergrund und Zielen
      • 44. Begriffe besser, wenn im Schreibfluss gewählt
      • 45. Verknappte Beispiele ohne Ballast
      • 46. Ergibt ausgestaltete Dokumentation
      • 47. Fördert erneutes Durchlesen und Verbessern
    • 48. Code-First
      • Beginne mit Tests, nicht mit dem API
      • 49. Schreibe Einführungstext vor dem Test (leeres Blatt!)
      • 50. Verberge Ballast
      • 51. Trenne Beispieltests von technischen Tests
      • 52. Verwende JavaDoc nicht für lange Anleitungen
        • Verweise stattdessen auf Beispieltests
      • Generiere evtl. Doku daraus: http://agical.com/bumblebee/
    • 53. Prose-First
      • Beginne weit oben (Übersicht, Ziele)
      • 54. Skizziere die Beispiele zunächst direkt im Text
        • So bleibt man auf die Story fokussiert
        • 55. Beispiele danach in echte Tests überführen
      • Zitiere auch die Checks in den Tests
        • Prüft dieser Test wirklich was ich behaupte?
      • Zitiere so viel wie möglich
        • Kein Copy/Paste
      • Kehre wieder nach weit oben zurück
        • Sind die Ziele erreicht? Verweise zu Beispielen.
      • Checke mit dem Code zusammen ein
    • 56. Caveat Emptor
      • Kurze Beispiele auf Kosten des APIs
        • Es gibt noch andere Kriterien für ein gutes API
        • 57. Vorsicht beim Einführen von vereinfachten APIs
      • Anleitung ersetzt die Referenz nicht
      • 58. Nicht alle Programmierer schreiben gut
        • Vorträge halten, Präsentationen im Haus
        • 59. Reviews, Lektoren (aus Administration?)
        • 60. Der Reflexion nicht ausweichen!
    • 61. Den Kreis schliessen
        Was hat mich dieser Vortrag gelehrt?
      • Wie können wir externe Anleitungen in IDEs integrieren?
      • 62. Wie die Zitate direkt im Dokumenteditor anzeigen?
      • 63. Wenn ich Library-Code reviewe, dann bestehe ich auf Beispieltests.
    • 64. Links
      • Twitter: @parrenbrecht
      • 65. Literate Testing
        • http://arrenbrecht.ch/testing/
      • JCite
        • Zitiert Code-Ausschnitte in HTML-Dokumente
        • 66. http://arrenbrecht.ch/jcite/
      • Bumblebee
        • Erzeugt HTML aus Kommentaren im Code
        • 67. http://agical.com/bumblebee/bumblebee_doc.html
      • Vielen Dank!