Delphi ist unbeliebt...angeblich

[freimatz]

Zitat von Sherlock:

Man kann das Delphi Gebashe auch wirklich übertreiben. "Delphi gets the job done" was will man mehr?

Definiere bitte "the"? Ich bekomme "meinen" hier mit Delphi auch done. Aber mehrmals am Tag Delphi neustarten oder zu manchen Zeiten nach jedem Lauf des Unit-Tests - das ist teuer.
Hier gibt es etliche Entwickler die Delphi und C# machen. Alle machen lieber C# mit VS als Delphi.

[Sherlock]

Meine 10.2.1 IDE stürzt mittlerweile im Schnitt einmal die Woche ab. Und das obwohl ich mit FMX auf dem iOS Simulator oder gar einem iPad entwickele. Das ist enorm gegenüber noch dem letzten Jahr.

Sherlock

[Codehunter]

Zitat von Sherlock:

Meine 10.2.1 IDE stürzt mittlerweile im Schnitt einmal die Woche ab. Und das obwohl ich mit FMX auf dem iOS Simulator oder gar einem iPad entwickele. Das ist enorm gegenüber noch dem letzten Jahr.

Sherlock

Hatte ich auch schon mal nach dem Update von XE2 auf XE4. Hab damals geflucht wie ein Rohrspatz. Am Ende war es aber ein defekter RAM-Riegel, der sich zufällig gerade dann bemerkbar machte wo ich das Update installiert hab. Kann auch mal sowas banales sein.

[Der schöne Günther]

Alle die meckern sollen mal mit dem C++ Builder arbeiten. Danach weiß man wie gut man es als Delphi-Entwickler hat. Lieber würde ich Qualitätskontrolle für Rektal-Thermometer machen.

[Bernhard Geyer]

Zitat von freimatz:

... nach jedem Lauf des Unit-Tests - das ist teuer.

Unit-Tests auf dem Client-Rechner zu machen ist teuer.
Ich würde euch empfehlen ein Build-System wie Jenkins zuzulegen.
Bei uns laufen die Unit-Tests mittlerweile nach jedem Checkin.

[LTE5]

Bei kleineren Produkten sind Unit-Tests doch nicht notwendig. Da lässt man die Software einfach von zwei, drei Leuten auf Herz und Nieren prüfen und alles ist gut.

[Uwe Raabe]

Zitat von LTE5:

Bei kleineren Produkten sind Unit-Tests doch nicht notwendig. Da lässt man die Software einfach von zwei, drei Leuten auf Herz und Nieren prüfen und alles ist gut.

Du hast das Ironie-Tag vergessen

[mensch72]

UnitTests eignen sich sogar speziell für kleinere Projekte, denn da ist die Anzahl möglicher gültiger Zustände noch überschaubar und damit voll regelbasiert definierbar&prüfbar. Und da ist dann ein erfolgreicher Unittest auch meist ein Zeichen das "alles gut".

Bei größeren Sachen wo es letztendlich um irrsinnig viele mögliche Kombinationen aus verschiedensten Größen/Werten geht, welche teils gültig und teils ungültig sind, da scheitern im Livebetrieb "binäre" Unittetsts die da ja letztendlich nur ala "InRange/OutRange" prüfen können.
Da es leider auch manuell unmöglich ist vorab, alle möglichen gültigen Kombinationen regelbasiert binär zu beschreiben, setze ich da auf etwas BigData und Statistik per Klassifizierung durch SupportVectorMaschinen... da gibt man wie bei neuronalen Netzen alles aus der Vergangenheit und dem aktuellen samt Ergebnis rein, und das ermöglicht dann eine "vorab" Bewertung eines "neuen" Ergebnisses aus einem beliebigen Parametersatz, bevor dieser weiterverwendet wird.


Also Super: Unittests finden grobe Schnitzer vorab, reale Fehler durch zufällig mehrere ungünstige(aber einzeln gültige) Wertepaarungen verhindern all meine vorab bestandenen UnitTests aber leider nicht
=> Soll heißen: auch nach bestandenen UnitTests verzichte man im RealProgramm nie auf ständige Werte und Fehlerprüfungen

[LTE5]

Ich mach es immer so, dass ich neu hinzugefügte Funktionen sehr gründlich durchprüfe.
Ich brauche da keine Unitstests oder so. Alles Zeitverschwendung meiner Meinung nach.

[Daniel]

Unit-Tests sind nicht das Thema hier.