Seven testing tips

[animate]

http://www.benpoole.com/80256B44004A7C14/articles/TestTips


ich finde den Artikel und die weiterführenden Links ganz interessant.

[Hernan Cortez]

... eine wirklich gute Zusammenfassung.
Aus meiner ERfahrung lauten ja 67% aller Kommentare in Notes Datenbanken:  

Code

 
' Jürgen. Meine Änderung beginnt hier. 

Eclipse unterstützt viele der genannten Sachen:
Einfach zu bedienender cvs-Client.
eigene Perspektive für Unit-Tests.
Refactoring (von BP nicht genannt).


Der Teufel steckt aber wie immer im Detail. Es dauert eine Zeit bis man wirklich effizient richtig test-driven development betreibt (was Testen und JUnit wirklich beherrschen) --> kann ich auch noch nicht.
In Phasen wo man stark neue APIs in sein Repertoire integriert, ist das Schreiben von Testcode auch nicht unbedingt sinnvoll, weil man einfach zu viel umschmeisst. Irgendwie gibt es auch ein htmlUnitTesting framework (was total übertrieben ist). Auf der Ranch gab es mal eine Diskussionswoche mit einem Autor eines how-to-test-correctly Buchs. Unter den wirklichen OO-Freaks im OO/UML Forum hatte dann jeder seine eigene Meinung.

Z.B. sowas wie CVS muß man auch erstmal richtig beherrschen (Versionen setzen etc). Bei uns gab es letztmal eine wg. Zeitmangel gescheiterte Bewegung hin zu Rational Clear Case (gibts ja umsonst als Businesspartner), weil das commiten von 5 Leuten gegen cvs zu chaotisch wurde. Meiner Meinung nach kann man das lösen, wenn man die CVS features - wie z.B. Versionierung - richtig beherrscht. Auch die einfachen Eclipse "Masken" ersetzen keine richtige Beschäftigung mit CVS an sich.

Ein großer Teil der Verwirrung um OO besteht IMHO darin, dass die Anfängerliteratur eigentlich immer ein volles OO-Layer beschreibt.

Code

Es gibt ein Förmchen für Autos und eins für Räder. Die Förmchen sind die Klassen. Damit werden Objekte erstellt. Von Rädern sogar 4. Objekte können auch andere Objekte enthalten (Containment). Ein Auto hat 4 Räder. Ausserdem haben Objekte Methode. Ein Auto z.B. "fahren". 
Somit ist nun klar bewiesen, dass Objekte einfach die Realität wiedergeben. OO ist also einfacher...  Alle, die nicht OO programmieren, sind Torf-Köpfe. 

Als "normaler" Straßen-Notesler denkt man aber erstmal in Masken und Ansichten.
Die meisten mir bekannten OO-Teile für Notes - u.a. auch das von Ben Poole - sind keine Objekte im Sinne von Abbildern der Realität (wie das Auto Beispiel). Es sind vielmehr das, was Larman Pure Fabrications nennt, d.h. kohäsive Elemente, die eine bestimmte rein softwareinterne, abstrakte Funktion übernehmen (z.B. Validierung).

Gruß Axel

[animate]

... eine wirklich gute Zusammenfassung.
Aus meiner ERfahrung lauten ja 67% aller Kommentare in Notes Datenbanken:  

Code

 
' Jürgen. Meine Änderung beginnt hier. 

das ist besser als nix. Eine bestimmte Menge an Code (ich kann das jetzt nicht in % angeben) ist nach meiner Erfahrung gar nicht kommentiert.

Eclipse unterstützt viele der genannten Sachen:
Einfach zu bedienender cvs-Client.
eigene Perspektive für Unit-Tests.
Refactoring (von BP nicht genannt).

Ja stimmt, das ist schön. Leider kann das die Notes-Designer-IDE nicht

Ein großer Teil der Verwirrung um OO besteht IMHO darin, dass die Anfängerliteratur eigentlich immer ein volles OO-Layer beschreibt.

Code

...

Als "normaler" Straßen-Notesler denkt man aber erstmal in Masken und Ansichten.
Die meisten mir bekannten OO-Teile für Notes - u.a. auch das von Ben Poole - sind keine Objekte im Sinne von Abbildern der Realität (wie das Auto Beispiel). Es sind vielmehr das, was Larman Pure Fabrications nennt, d.h. kohäsive Elemente, die eine bestimmte rein softwareinterne, abstrakte Funktion übernehmen (z.B. Validierung).

Da magst du recht haben, ich kenne nur wenig NotesDBs, in denen überhaupt bewusst OO angewendet wird.
Allerdings kann man auch in Notes auch wunderbar Klassen nutzen, die Abbilder der Realität sind. Das ist dann halt nicht das Auto, sondern der Kunde und seine Firma oder sowas, und die beiden sind von der Klasse Dokument abgeleitet (z.B.)

[Hernan Cortez]

[sondern der Kunde und seine Firma oder sowas, und die beiden sind von der Klasse Dokument abgeleitet (z.B.)

... hab ich so weit noch gar nicht getrieben. Wobei ich würde das erstmal so versuchen würde, der Klasse das Dokument im Konstruktor zu übergeben. Also quasi als containment und nicht über inheritance.

Wobei man da die Notes-Logik immer mitbedenken muß. Bei Enterprise Java Beans wurde auch immer wieder kritisiert, dass die sich OO-features im Grunde widersetzen. Kyle Brown (IBM) hatte da so Artikel, wie man da Vererbung in EJBs bringt. Ich glaub, das haben aber nur 10 Leute weltweit verstanden.

<xTremeBlaBlaBla>
Das ist dann so, dass man sogenannte cross-cutting concerns wie Security, Persistance, mailing (ungewöhnlich), GUI-Darstellung (auch ungewöhnlich) Notes überläßt. Cross-Cuttings Concerns sind Dienste, die klassenübergreifend sind.  So ist zumindest die Idee von EJB.
Dadurch werden aber die Klassen selber schwergewichtig, weil sie zuviel Rücksicht auf Notes nehmen müssen. Die Tendenz bei Java geht z.Zt. dahin, dass man das so macht, dass die Klassen möglichst wenig von den Diensten "merken". Das coole an Hibernate ist, dass ich dort einen RDBMS übergreifenden RDBMS Dienst habe und bei der Gestaltung der Klassen in einem sehr hohen Grade  frei bin.
Wenn ich einen wirklichen Objekt-Layer haben will, ist das glaub ich eine sehr entscheidende Frage: Welche Zusatzanforderung an die Klassen stellt das Framework/Tool/whatever - dessen cross-cutting-concern Dienste ich nutze - an die Implementierung der Klassen selbst.
</xTremeBlaBlaBla>

Gruß Axel

[animate]

[sondern der Kunde und seine Firma oder sowas, und die beiden sind von der Klasse Dokument abgeleitet (z.B.)

... hab ich so weit noch gar nicht getrieben. Wobei ich würde das erstmal so versuchen würde, der Klasse das Dokument im Konstruktor zu übergeben. Also quasi als containment und nicht über inheritance.

also 'Dokument' ist eine Klasse, die ein 'NotesDocument'-Objekt enthält, das dem Konstruktor übergeben wird. Und 'Dokument' ist die Basisklasse für spezielle Klassen wie 'Kunde', 'Firma'.


So meinte ich das.
Von den Notes-Klassen kann man sowieso keine eigenen Klassen ableiten

[TMC]

Sehr interessanter Artikel.

Wobei mich z.B. GetThreadInfo noch immer nicht begeistert. Ich bin davon wieder abgekommen und übergebe lieber meiner ErrorSub die aktuelle Routine etc. per String - ist einfach exakter und zuverlässiger.

Was mir hier auch noch etwas fehlt - passt eigentlich zu den immer fehlenden Code-Kommentierungen - ist eine einheitliche Variablen-Bezeichnung. Vielleicht bin ich da auch zu empfindlich, aber irgendwelche "Reader = doc.blabla" Variablenzuordnungen ohne vorherige Deklaration und einheitlichen Präfixen treiben mich bei langen Codes zum Wahnsinn.

Aber jetzt bin ich auch schon sehr entfernt vom "testing"-Thema. Wie auch immer....

Matthias

[animate]

diesen Satz hätte er besser nicht schreiben sollen

I recommend you look at these products before the über-geek in you decides to code your own CVS / DXL interface-based source control system (or is that just me? Ahem).

Das ist eine verdammt gute Idee. Aber leider zu schwer und zeitaufwändig für mich, um das mal nebenbei zu entwickeln.

[Hernan Cortez]

... und oft ist Formelsprache einfach aus Performance-Gründen wirklich ratsam.
Jeder dbLookup unterläuft strenggenommen die durch die Klassen spezifizierte Objektstruktur.

Halte ich aber für eine gute Idee. Dein Ansatz.  

Rein gescriptete Anwendungen werden wirklich immer zu undurchschaubaren Monstern und ich (bzw. meine Firma) verdienen da auch noch ein bischen dran. Aber die Zeit, die Änderungen, bug-suche, etc. in Anspruch nehmen ist einfach nicht ökonomisch. Leid tun mir die Kunden nicht, aber es gibt heute wirklich bessere Wege.
Aber das ist eh klar.

Gruß Axel

[animate]

das coole ist, dass in einer Maske theoretisch nur noch 2 Zeilen Code stehen müssen (außer sowas wie Option Explicit)

Dim p as Person
Set p = new Person(source)

der Rest inklusive aller Events läuft in der Klasse ab.

Mit den Formeln hast du natürlich leider Recht.
Ich mag Formeln, aber die passen so leider gar nicht zu OO.
Aber manche Wünsche lassen sich nur über Formeln realisieren, manche sind dadurch performanter als Script-Lösungen, wie du ja schon gesagt hast.

Wie gesagt, theoretisch habe ich 2 Zeilen in einer Maske. Und jetzt sag mir mal einer, dass das nicht pflegeleicht ist...

[TMC]

theoretisch habe ich 2 Zeilen in einer Maske. Und jetzt sag mir mal einer, dass das nicht pflegeleicht ist...

Das hat schon was :-)

Bisher war ich oft "Klassen-faul", und habe vieles in Functions/Subs in Libs ausgelagert. Das sehr extrem. Teilweise hat(te) eine Function/Sub nur 1-2 Zeilen Code mit Verweis auf andere Routinen.
Generell hat der "1st-Level-Programmierer" damit kein Problem, er pflegt ja nur z.B. die Masken-Events und ruft < 5 Routinen auf. Wehe aber, die ScriptLib muss angepasst werden, dann hat man das Gezeter und muss sich durchwühlen. Aber das bleibt wohl nie aus. Gut kommentierter Code hilft da bekanntlich sehr weiter.
Eine coole 3rd-Party-IDE wäre da bestimmt noch hilfreicher.