Your SlideShare is downloading. ×
ESEconf2011 - Arrenbrecht Peter: "Literate Testing: Stimmige API's machen mehr Spass"
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

357
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
357
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
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!