Hypercell ein ] Hypercell aus ] Zeige Navigation ] Verstecke Navigation ]
c++.net  
   

Die mobilen Seiten von c++.net:
https://m.c-plusplus.net

  
C++ Forum :: Projekte ::  BETA: Test soon: Neues Testing Framework basierend auf Erfahrungen mit anderen Frameworks  
Gehen Sie zu Seite 1, 2, 3  Weiter
  Zeige alle Beiträge auf einer Seite
Auf Beitrag antworten
Poll :: Bist du mit einem (Unit) Test Framework, das du bisher kennst zufrieden? (Außer "Test soon".)

Ja, völlig.
30%
 30%  [ 9 ]
Nein, aber ich komme zurecht und möchte auch nicht wechseln.
3%
 3%  [ 1 ]
Nein, wurde Zeit für eine neue Alternative!
36%
 36%  [ 11 ]
Nein, alles Scheiße, auch "Test soon" ist Müll / muss Müll sein.
30%
 30%  [ 9 ]
Stimmen insgesamt : 30


Autor Nachricht
Mr. N
Mitglied

Benutzerprofil
Anmeldungsdatum: 28.12.2001
Beiträge: 4328
Beitrag Mr. N Mitglied 15:33:52 18.11.2006   Titel:   BETA: Test soon: Neues Testing Framework basierend auf Erfahrungen mit anderen Frameworks            Zitieren

Wir (Ronny und ich) sind auf der Suche nach Feedback und Anregungen. Daher möchte ich mich auf die Forumsbeschreibung beziehen:
Zitat:

Ihr sucht ein paar Beta-Tester für eure fertigen Projekte?


Wobei unser Projekt noch nicht wirklich fertig ist.


Test soon


Test soon ist ein Testing Framework zum Beispiel für Unit Tests. Wir haben momentan einen einfachen XML Reporter und einen (genau genommen zwei) Text Reporter für Menschen.

Was meint ihr? Bitte formuliert eure vernichtende Kritik höflich ;).

EDIT: Ach ja, das ganze ist für C++. Steht aber auch im Link.


Zuletzt bearbeitet von Korbinian am 16:26:49 22.08.2007, insgesamt 3-mal bearbeitet
ronny
Mitglied

Benutzerprofil
Anmeldungsdatum: 16.11.2004
Beiträge: 440
Beitrag ronny Mitglied 17:54:49 18.11.2006   Titel:              Zitieren

es wäre nett, wenn sich die paar gegenstimmen einmal mit kritik äußern würden anstatt nur votes zu setzen
Mr. N
Mitglied

Benutzerprofil
Anmeldungsdatum: 28.12.2001
Beiträge: 4328
Beitrag Mr. N Mitglied 19:59:48 07.01.2007   Titel:              Zitieren

Jetzt ist Version 0.58 (zum Zeitpunkt des ersten Posts wars 0.55) raus. Ein direkter Link auf unsere Sourceforge-Projektseite: http://sourceforge.net/projects/testsoon.

Viel Spaß.
Headhunter
Mitglied

Benutzerprofil
Anmeldungsdatum: 20.08.2000
Beiträge: 3567
Beitrag Headhunter Mitglied 12:49:02 10.01.2007   Titel:              Zitieren

Hallo,

ich habe mir das Framework mal angeschaut (leider nur auf der Homepage, nicht im eigenem Projekt).

Der Syntax - also das Verwenden von Makros zur Testerzeugung - gefällt mir sehr gut. Ich kenne CPPUnit, CXXUnit und ein paar andere Unit Testing Frameworks für C++ - und keines von denen ist wirklich toll zu benutzen. Test soon sieht da schon wesentlich cooler aus :live:

Leicht Offtopic:
Wo ihr gerade ein eigenes Framework entwickelt: Wäre es nicht möglich per Makros Design by Contract zu implementieren? Natürlich nicht zur Laufzeit - Test soon soll aus meinen deklarativen Einschränkungen automatisch Tests erzeugen, beispielsweise so:

C++:
bool is_prime (int number)
{
     VERIFY (number > 0)
     // .. Berechnung .. ret = ...
     RETURN_AND_VERIFY (ret, ret == 1 || ret == 0)
}


Was meint ihr :) ?

_________________
Viele Grüße, headhunter
Mr. N
Mitglied

Benutzerprofil
Anmeldungsdatum: 28.12.2001
Beiträge: 4328
Beitrag Mr. N Mitglied 18:42:03 10.01.2007   Titel:              Zitieren

Headhunter schrieb:
Hallo,

ich habe mir das Framework mal angeschaut (leider nur auf der Homepage, nicht im eigenem Projekt).

Der Syntax - also das Verwenden von Makros zur Testerzeugung - gefällt mir sehr gut. Ich kenne CPPUnit, CXXUnit und ein paar andere Unit Testing Frameworks für C++ - und keines von denen ist wirklich toll zu benutzen. Test soon sieht da schon wesentlich cooler aus :live:


Danke!

Zitat:

Leicht Offtopic:
Wo ihr gerade ein eigenes Framework entwickelt: Wäre es nicht möglich per Makros Design by Contract zu implementieren? Natürlich nicht zur Laufzeit - Test soon soll aus meinen deklarativen Einschränkungen automatisch Tests erzeugen, beispielsweise so:

C++:
bool is_prime (int number)
{
     VERIFY (number > 0)
     // .. Berechnung .. ret = ...
     RETURN_AND_VERIFY (ret, ret == 1 || ret == 0)
}


Was meint ihr :) ?


Nicht zur Laufzeit meinst du? Dann wird es zumindest SO nicht möglich sein. So oder so kannst du assert aus <cassert> verwenden. Ich könnte mir mit gewissem technischen Aufwand folgendes vorstellen:

C++:
int strcmp(char const *a, char const *b) {
   VERIFY_RETURN_VALUE(_1 == 0 || _1 == -1 || _1 == 1);
}


Aber es ist durchaus möglich, den Test im jetzigen Stil direkt nach der Funktion zu schreiben und <testsoon.hpp> mittels des Makros TESTSOON_DUMMY bei Nichtbedarf in einen Dummy-Modus zu setzen, der nur wegoptimierbaren Code generiert.

PS: Um sicherzustellen, dass number > 0 ist, könntest du übrigens einen eigenen Typen verwenden, aber das nur am Rande.
phlox81
Moderator

Benutzerprofil
Anmeldungsdatum: 21.04.2001
Beiträge: 7480
Beitrag phlox81 Moderator 18:50:14 10.01.2007   Titel:              Zitieren

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

_________________
Intelligenz ist eine Illusion des Menschen

phlox81.de | The Black Board | Code Node | Xing | Blog | C++ Kurs | Meeting C++ | Twitter
Headhunter
Mitglied

Benutzerprofil
Anmeldungsdatum: 20.08.2000
Beiträge: 3567
Beitrag Headhunter Mitglied 18:57:35 10.01.2007   Titel:              Zitieren

Hi,

bei meinem Beispiel ging es nicht um Programmierstil, sondern nur um Prinzip :)

Vielleicht sollte ich mal erklären was ich möchte.

Was möchte man bei Unittests eigentlich erreichen?
1) überprüfen mit korrekten Werten/Ausgangssituationen
2) überprüfen mit falschen Werten/Ausgangssituationen
3) dokumentieren des Quellcodes (gute Beispiele geben, "so geht's nicht"..)
4) Bugfixing (hier eher sekundär)

Um all diese Aufgaben zu erledigen bieten sich Unittests an. Sie haben jedoch einen Nachteil: Jeder Test muss außerhalb der Implementierung manuell geschrieben werden. Wenn ich also eine Klasse "foo" erzeuge, muss ich daran denken einen Test namens "test_foo" zu schreiben.

Eine Design by Contract Testlösung hätte dieses Problem nicht - schon beim Code tippen sehe ich, welche Eingangsbeschränkungen eine Funktion hat. Die dazu automatisch generierten Testfunktionen sollen die Funktion dann jeweils mit (automatisch generierten) falschen und korrekten Eingabewerten durchtesten.
Wenn gewünscht kann der Testcode dann von mir editiert werden.

Vom Prinzip ähnelt das dem Scaffolding aus Rails: Anhand von vorgegebenen Objekten (bei Rails Tabellen) wird dazu passender Code (HTML+Ruby) erzeugt. Sehr agil :)

Wie man das jedoch implementieren kann, weiß ich nicht.
Wahrscheinlich muss man die Sources mit nem eigenem Preprozessor bearbeiten.
Alternativ: Wann werden die Konstruktoren von lokalen statischen Objekten aufgerufen? Wenn die ctors alle beim Start eines Programmes aufgerufen werden, hat man gewonnen. Gibt's da vielleicht nen GCC-Switch für? Mal schauen..

_________________
Viele Grüße, headhunter
Headhunter
Mitglied

Benutzerprofil
Anmeldungsdatum: 20.08.2000
Beiträge: 3567
Beitrag Headhunter Mitglied 19:04:50 10.01.2007   Titel:              Zitieren

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.

_________________
Viele Grüße, headhunter
Mr. N
Mitglied

Benutzerprofil
Anmeldungsdatum: 28.12.2001
Beiträge: 4328
Beitrag Mr. N Mitglied 21:58:53 10.01.2007   Titel:              Zitieren

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?


Wir machen exzessiv gebrauch von Boost.Preprocessor. Das hat nur Boost. Und wir brauchen es dafür. Du brauchst allerdings wirklich nur die angegebenen Teile von Boost. Boost.Asssign könnte man optional machen.

Warum nicht Boost.Test? Weil mir das genausowenig wie die anderen gefällt. IMHO Grund genug.

EDIT: Die named parameter sind ein integraler Teil von Test soon. Nur so können wir die nötige Flexibilität erreichen und trotzdem gute Syntax haben. Wie sonst ginge sowas? (Check1 ist ein generischer Check auf einen unären Funktor)

C++:
XTEST((name, "dummy test") (range, (int, 0, 7))) {
  Check1(something, value);
}


EDIT 2: schließende Klammer hat gefehlt (die Klammern sind technisch nötig)


Zuletzt bearbeitet von Mr. N am 22:02:39 10.01.2007, insgesamt 2-mal bearbeitet
Mr. N
Mitglied

Benutzerprofil
Anmeldungsdatum: 28.12.2001
Beiträge: 4328
Beitrag Mr. N Mitglied 22:23:36 10.01.2007   Titel:              Zitieren

Headhunter schrieb:
Hi,

bei meinem Beispiel ging es nicht um Programmierstil, sondern nur um Prinzip :)


Mir gehts um Machbarkeit. OHNE extra Präprozessortool (welches nicht cpp heißt :D).

Headhunter schrieb:

Vielleicht sollte ich mal erklären was ich möchte.

Was möchte man bei Unittests eigentlich erreichen?
1) überprüfen mit korrekten Werten/Ausgangssituationen
2) überprüfen mit falschen Werten/Ausgangssituationen
3) dokumentieren des Quellcodes (gute Beispiele geben, "so geht's nicht"..)
4) Bugfixing (hier eher sekundär)


Auf jeden Fall, allerdings haben Punkte 1 und 2 Priorität.

Headhunter schrieb:

Um all diese Aufgaben zu erledigen bieten sich Unittests an. Sie haben jedoch einen Nachteil: Jeder Test muss außerhalb der Implementierung manuell geschrieben werden. Wenn ich also eine Klasse "foo" erzeuge, muss ich daran denken einen Test namens "test_foo" zu schreiben.


Unsere Tests brauchen keinen Namen. Ach und ich weiß nicht ob ich die Bezeichnung "Unit Test" mag. Oder um mit Helge Schneider zu sprechen: "Das ist mir zu profan." :o)

Headhunter schrieb:

Eine Design by Contract ...


*quietsch* *halt*

Das solltest du genauer erklären. Was meinst du? Wozu brauchst du das? Ist es wirklich vorteilhaft?

Der Wikipedia-Artikel ist nicht lesbar.

Dann: Lässt sich das auch anders lösen? Kannst du deine Constraints nicht ins Typsystem einbauen? Du brauchst einen Wert > 0? Du nimmst (unsigned. Oder aber) checked integer.

Dann: Sind Test soon / Unit tests nicht trotzdem sinnvoll? Lässt sich alles über einen Vertrag prüfen?

Dann: Das mit dem "dran denken" gilt hier auch.

Headhunter schrieb:

... Testlösung hätte dieses Problem nicht - schon beim Code tippen sehe ich, welche Eingangsbeschränkungen eine Funktion hat. Die dazu automatisch generierten Testfunktionen sollen die Funktion dann jeweils mit (automatisch generierten) falschen und korrekten Eingabewerten durchtesten.
Wenn gewünscht kann der Testcode dann von mir editiert werden.


Wenn du konkretere Ideen hast, kannst du dich gerne mit uns zusammen setzen und dann überlegen wir, was Sinn macht. Deine Idee ist reizvoll, scheint aber nicht unbedingt praktikabel.

Headhunter schrieb:

Vom Prinzip ähnelt das dem Scaffolding aus Rails: Anhand von vorgegebenen Objekten (bei Rails Tabellen) wird dazu passender Code (HTML+Ruby) erzeugt. Sehr agil :)


*flycht* Ronny nervt mich auch ständig mit diesen Buzzwords. Muss das sein?

Headhunter schrieb:

Wie man das jedoch implementieren kann, weiß ich nicht.
Wahrscheinlich muss man die Sources mit nem eigenem Preprozessor bearbeiten.
Alternativ: Wann werden die Konstruktoren von lokalen statischen Objekten aufgerufen? Wenn die ctors alle beim Start eines Programmes aufgerufen werden, hat man gewonnen. Gibt's da vielleicht nen GCC-Switch für? Mal schauen..


Daran habe ich gedacht, als ich von "mit einigem Aufwand machbar" sprach.

Prost.

PS: BB-Code ist voll scheiße.
C++ Forum :: Projekte ::  BETA: Test soon: Neues Testing Framework basierend auf Erfahrungen mit anderen Frameworks  
Gehen Sie zu Seite 1, 2, 3  Weiter
Auf Beitrag antworten

Zeige alle Beiträge auf einer Seite




Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Sie können keine Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum nicht antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht mitmachen.

Powered by phpBB © 2001, 2002 phpBB Group :: FI Theme

c++.net ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de Werbekostenerstattung verdient werden kann.

Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info und www.c-plusplus.net enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt (vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden. Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.