4. BETA: Test soon: Neues Testing Framework basierend auf Erfahrungen mit anderen Frameworks

BETA: Test soon: Neues Testing Framework basierend auf Erfahrungen mit anderen Frameworks

  • H

    Hi,

    bei Unittesting (um mal bei dem Wort zu bleiben) geht es mir nicht um Stil oder Schönheit, sondern um Praktikabilität. Wenn ich was schönes elegantes will schreibe ich Code oder entwickle ein tolles System. Unittests müssen funktionieren , umfassend testen und das am Besten ohne großen Entwickleraufwand. Deshalb finde ich das Prinzip von Test soon auch so toll - simplicity rules!

    Zum Design by Contract und zu Entscheidungen ins Typsystem verlagern:

    Was ist ein unsigned int?
    Im Prinzip ist es ein normaler int mit der Constraint "n>0". Für ein char gilt "c>=0 && c<256". Das sind Einschränkungen, nur nennen wir sie hier nicht Constraints sondern Typen.
    Das schöne an Typen ist: Sie sind eingebaut und für den Entwickler bindend. Ich kann keinen uint mit einem negativen Wert initialisieren.

    Meine Funktionen un Klassen haben auch Constraints. So hat die Funktion "getValueFromPointer(foo* bar)" die Einschränkung, dass "bar" != NULL sein muss.
    Bei einer Funktion "getFileModificationDate(string path)" ist die Einschränkung, dass "path" eine gültige Datei beschreibt. Diese Einschränkungen gelten erstmal implizit durch einen entsprechenden Headercomment. Zusätzlich schreibt man noch ein Fehlerüberprüfungs-if an den Anfang der Funktion, um fehlerhafte Eingaben auszuschließen.
    Dann schreibt man Unit Tests, um dieses Verhalten zu verifizieren und zu dokumentieren. Der Unit Test sagt also was richtig und was falsch sein soll.
    Problem auch hier: Sowas ist implizit: Es greift nur *wenn* ich Tests für alle relevanten Teile schreibe (Code Coverage) und *wenn* ich die Tests ausführe.

    Ein Design by Contract bringt diese Überprüfungen bzw. Funktionsspezifierungen in den Quellcode und ist so ein integraler Bestandteil der Entwicklung. Allein diese Tatsache macht Design by Contract schonmal wertvoller als Unit Tests.

    Was heißt das jetzt in drei Sätzen?
    * Simple is beautiful, komplexe Sachverhalte auf einfache Bausteine reduzieren rockt.
    * Design by Contract ist ein simples Prinzip mit simplen Werkzeugen, das komplexe Sachverhalte einfach sichtbar macht.
    * Unit Tests überfordern viele Entwickler, da sie kein integraler Bestandteil eines Programmes sind, das Programm startet auch ohne grünes Lämpchen - DbC setzt da die Daumenschraube an und forciert Spezifikationen.

    0
  • M

    Headhunter schrieb:

    Meine Funktionen un Klassen haben auch Constraints. So hat die Funktion "getValueFromPointer(foo* bar)" die Einschränkung, dass "bar" != NULL sein muss.

    Also das lässt sich in C++ recht problemlos lösen.

    template<class T>
class non_null_ptr {
  T *p;

public:
  non_null_ptr(T *p) : p(p) {
    if (p == 0)
      throw std::foo_exception();
  }

  T &operator*() { return *p; }
  ...
};

    Headhunter schrieb:

    Bei einer Funktion "getFileModificationDate(string path)" ist die Einschränkung, dass "path" eine gültige Datei beschreibt.

    Du meinst natürlich einen gültigen Dateinamen. Alles weitergehende wäre eine race condition... Naja, auch das lässt sich analog lösen.

    Headhunter schrieb:

    Diese Einschränkungen gelten erstmal implizit durch einen entsprechenden Headercomment. Zusätzlich schreibt man noch ein Fehlerüberprüfungs-if an den Anfang der Funktion, um fehlerhafte Eingaben auszuschließen.

    Jo, oder ein assert.

    Headhunter schrieb:

    Dann schreibt man Unit Tests, um dieses Verhalten zu verifizieren und zu dokumentieren. Der Unit Test sagt also was richtig und was falsch sein soll.
    Problem auch hier: Sowas ist implizit: Es greift nur *wenn* ich Tests für alle relevanten Teile schreibe (Code Coverage) und *wenn* ich die Tests ausführe.

    Unit tests sind für andere Dinge wichtiger und durch DbC nicht vollständig zu ersetzen. Das möchte ich in den Raum gestellt wissen.

    Headhunter schrieb:

    Ein Design by Contract bringt diese Überprüfungen bzw. Funktionsspezifierungen in den Quellcode und ist so ein integraler Bestandteil der Entwicklung. Allein diese Tatsache macht Design by Contract schonmal wertvoller als Unit Tests.

    *hüstel* Die Anwendungsfelder sind wie gesagt nicht deckungsgleich. Darüber hinaus werden komplexere Spezifikationen schnell fehleranfällig.

    Auch Unit tests sind integraler Anteil der Entwicklung. Ich entwickle ein Modul und nach jeder Veränderung lasse ich alle Test laufen bzw. füge auch neue hinzu. Natürlich gibt es auch Leute, die das als "Buzzword" einfach ablehnen.

    Headhunter schrieb:

    Was heißt das jetzt in drei Sätzen?
    * Simple is beautiful, komplexe Sachverhalte auf einfache Bausteine reduzieren rockt.
    * Design by Contract ist ein simples Prinzip mit simplen Werkzeugen, das komplexe Sachverhalte einfach sichtbar macht.
    * Unit Tests überfordern viele Entwickler, da sie kein integraler Bestandteil eines Programmes sind, das Programm startet auch ohne grünes Lämpchen - DbC setzt da die Daumenschraube an und forciert Spezifikationen.

    Das dritte ist interessant. Aber mit Programmiererüberforderung kann ich halt nichts anfangen. Sonst wäre ich ja kein Java-Gegner. 🤡

    Meine Bitte: Gib so simplen Ansätzen wie "Unit" Testing oder halt "Test soon" trotzdem auch in der Praxis eine Chance.

    0
  • H

    Hallo,

    versteh mich nicht falsch MrN - ich betrachte Unit Tests durchaus als ein wichtiges Element in der Softwareentwicklung. Aber es ist nicht der Weisheit letzter Schluss (aus genannten Gründen), DbC würde es prima ergänzen.
    Den NULL-sicheren Pointer in C++ finde ich grausam, sieht echt schlimm aus 🙂

    0
  • M

    Headhunter schrieb:

    Hallo,

    versteh mich nicht falsch MrN - ich betrachte Unit Tests durchaus als ein wichtiges Element in der Softwareentwicklung. Aber es ist nicht der Weisheit letzter Schluss (aus genannten Gründen), DbC würde es prima ergänzen.

    OK. Ist nur vielleicht ein wenig missverständlich wenn du hier anfängst DbC zu preisen :p.

    Headhunter schrieb:

    Den NULL-sicheren Pointer in C++ finde ich grausam, sieht echt schlimm aus 🙂

    Wieso? Ich find den toll. Gut, benutzen tu ich das nicht :D.

    0
  • G

    Es macht einen recht kompakten Eindruck; das gefällt mir schon mal gut! 🙂

    Aber

    Headhunter schrieb:

    phlox81 schrieb:

    Ihr habt da eine Abhängigkeit zu boost, ist die wirklich nötig?
    Und warum sollte man dann nicht direkt boost::test verwenden?

    Boost brauchen die zwei für die Named Parameters. Ob man die braucht ist ne andere Frage, aber boost ist eigentlich immer praktisch.

    Boost ist im Vergleich dazu dann der Aufwand-Overkill für die Entwicklungsinfrastruktur! 😞

    Nichts gegen Boost; aber ich habe ein Projekt (und es ist nicht das erste) bei dem ich Boost fürs Release nicht einsetzen darf (ist halt so...).
    Da würde der Aufwand für die Boost-Installation nicht amortisieren.

    Wenn's auch ohne Boost kompiliert werde ich's gerne mal testen.

    Weiter so!

    Grüsse && Happy Hacking !

    *this

    0
  • P

    Gast++ schrieb:

    Es macht einen recht kompakten Eindruck; das gefällt mir schon mal gut! 🙂

    Aber

    Headhunter schrieb:

    phlox81 schrieb:

    Ihr habt da eine Abhängigkeit zu boost, ist die wirklich nötig?
    Und warum sollte man dann nicht direkt boost::test verwenden?

    Boost brauchen die zwei für die Named Parameters. Ob man die braucht ist ne andere Frage, aber boost ist eigentlich immer praktisch.

    Boost ist im Vergleich dazu dann der Aufwand-Overkill für die Entwicklungsinfrastruktur! 😞

    Nichts gegen Boost; aber ich habe ein Projekt (und es ist nicht das erste) bei dem ich Boost fürs Release nicht einsetzen darf (ist halt so...).
    Da würde der Aufwand für die Boost-Installation nicht amortisieren.

    Wenn's auch ohne Boost kompiliert werde ich's gerne mal testen.

    Weswegen darfst du es nicht einsetzen?
    Die Boost Lizenz ist doch recht liberal...

    0
  • G

    phlox81 schrieb:

    Weswegen darfst du es nicht einsetzen?
    Die Boost Lizenz ist doch recht liberal...

    Zu dem Projekt hatte ich schon mal etwas geschrieben:
    (leider ist das von einem Moderator zu "günstig" umplaziert worden)

    http://www.c-plusplus.net/forum/viewtopic-var-t-is-181214.html

    Kurzgefasst ist der Verzicht auf Boost u.a. eine Vorgabe der Konzern-IT.

    Grüsse

    *this

    0
  • M

    Gast++ schrieb:

    Wenn's auch ohne Boost kompiliert werde ich's gerne mal testen.

    Keine Chance.

    (Durch Zufall ist mir aufgefallen, dass jemand "vor kurzem" geantwortet hat.)

    0
  • M

    0.59 released.

    http://sourceforge.net/project/showfiles.php?group_id=180756

    0
  • R

    Changelog?

    0
  • M

    rüdiger schrieb:

    Changelog?

    Hab ich mir nicht die Mühe gemacht. Eigentlich wollte ich das Release ja nichtmal selber machen, aber weil ich eine Mail von einem Nutzer bekommen habe, hab ich das gemacht.

    0
Anmelden zum Antworten