Java Ermitteln, ob der RSI-Wert von unten nach oben verläuft

[kali-hi]

Das ist doch jetzt nur noch Satire.

Nein, das zeigt, dass du noch nie in größeren Softwareprojekten mit hunderten von Tests gearbeitet hast, die alle gestartet werden wollen... Dauert dann gerne mal ein paar Minuten

 

[tollertyp]

wobei Arrays in Record-Klassen ein Anti-Pattern ist.

Ähm... das sind die kleinsten Probleme in dem Code.

Ich verabschiede mich und frage mich, warum ich bemüht war, trotz Sarkasmus ernsthaft zu helfen - auch wenn der TE das nicht wahrnimmt. Ich glaube, ich verzichte auch in Zukunft auf Antworten bei ihm, weil Satire trifft es ganz gut.

Ergänzung (18. November 2025)

Nein, das zeigt, dass du noch nie in größeren Softwareprojekten mit hunderten von Tests gearbeitet hast, die alle gestartet werden wollen...

Ich verrate dir ein Geheimnis: Man muss nicht bei jedem Build (alle) Tests laufen lassen.
Zu meiner Meinung über dich und Softwareprojekte schreibe ich nichts, die würde man als vielleicht Beleidigung auslegen können.

 

[BeBur]

Sag es doch einfach wie es ist: Du testet grundsätzlich nicht weil es in SCRUM auch nicht explizit so vorgegeben ist.

Das ist wohl kaum der Grund wenn jemand denkt, sowas hier sei ein Test:

  public static void testLinearRegression_same_values_slope_0() {
    double[] y = {1, 1};
    LinearRegressionResult result = linearRegression(y);
    System.out.println(result);
  }

Da hat man womöglich als Softwareentwickler gearbeitet, aber definitiv noch nie professionell. Ich bin mittelmäßig schockiert darüber was da gepostet wurde.

Die Vergleiche fehlen, das stimmt, aber man kann auch einfach in die Ausgabe schauen

Kompletter Blödsinn aus so vielen Gründen. Oh man. Ne, heute nicht mehr, vielleicht hat ja wer anders Bock das zu erklären für die Nutzer die hier still mitlesen oder den Thread später mal finden.

Nein, das zeigt, dass du noch nie in größeren Softwareprojekten mit hunderten von Tests gearbeitet hast, die alle gestartet werden wollen... Dauert dann gerne mal ein paar Minuten

HUNDERTE? Ich habe schon jeweils 100 Tests für einzelne Klassen geschrieben. Man rechnet doch nicht in hundert, das ist die ganz falsche Größenordnung. Ein paar hundert Unittests dauern sicherlich auch bei Java meist keine mehrere Minuten. Nicht, dass das irgendeine Relevanz hätte bei größeren Softwareprojekten.

Das ist doch jetzt nur noch Satire.

Das wäre so schön.

 

[Bob.Sponge]

Nein, das zeigt, dass du noch nie in größeren Softwareprojekten mit hunderten von Tests gearbeitet hast, die alle gestartet werden wollen... Dauert dann gerne mal ein paar Minuten

Finde nicht das dies ein Punkt ist, an dem man anderen Ahnungslosigkeit unterstellen sollte. Vor allem wenn schon der Punkt gekommen ist: wirf einen Blick in den Spiegel.
Hattest du innerhalb deines Studiums wenigstens mal eine Projektpase innerhalb eines Softwareprojekts in der freien Wirtschaft?

Das man Tests taggen kann oder überhaupt gruppieren bzw. sogar nur gezielt eine Klasse testen kann ist dir wirklich neu? Es müssen nicht stets alle Tests ausgeführt werden. Vor allem läuft das dann ja eher über nachts automatisiert über einen Buildserver oder etwas nicht?

Komme immer noch nicht drüber hinweg: JUnit und von mir aus auch Mockito dazu als Boilerplate zu bezeichnen. Gerade bei so einem Minischnippsel wie hier angeboten. Dann lieber da eine Woche völlig plannlos aber "ganz agile" Stunden drauf zu verschwenden und immer brav nachfragen: "So, besser?".

Sei froh das deinen Job als wissenschaftlicher MA hast. Hoffe auch für dich das aus befristet dann auch irgendwann was festes draus wird.

 

[kali-hi]

Vor allem läuft das dann ja eher über nachts automatisiert über einen Buildserver oder etwas nicht?

Das ist der springende Punkt. Lose Kopplung und starke Kohärenz im Design und kollektive Codeverantwortung im Projekt sind anzustreben und auch dafür notwendig, damit der Build-Server (also die CI) überhaupt erst entscheiden kann, welche Tests ausgeführt oder übersprungen werden können - andernfalls müssen eben alle Tests einmal durchgeführt werden. Zudem gibt es Features die mehrere Verantwortlichkeiten betreffen.

Es darf einfach nicht passieren, dass Funktion A in Klasse X zwar einwandfrei funktioniert, aber später im produktiven Einsatz in Klasse Y die Anwendung ungeordnet zum Absturz bringt, nur weil man versäumt hatte, A auch mit Y zu testen, und dadurch alle... Fließbänder ein paar Stunden außerbetriebgesetzt sind (vereinfacht gesagt).

Und ich meinte schon den ganzen Build- und Test-Vorgang... Gradle muss die Konfiguration lesen, den Cache und Dependencies abrufen, übersetzen und testen (statische, syntaktische und Bug/Anti-Pattern Analyse, und schließlich auch die Unit-Tests). Das kann auch mal mehr als 5 Minuten dauern.

Möchte gar nicht wissen, wie das bspw. bei Windows 11 wäre...

 

[Bob.Sponge]

Über Buildserver etc. muss man ja überhaupt erstmal gar nicht sprechen, bei dem momentanen Stand.
So schaffst es dein "Feature" ja erst gar nicht in ein Repo. Ungetesteter Code der gemerged wird? Wer soll denn da akzeptieren sowas in die Codebase aufzunehmen.. es also jemals in die Nähe eines Buildservers kommt? Also unsinnig jetzt über komplette Buildprozesse zu philosophieren. Feature die lokal ungetestet nicht funktionieren, kommen in kein Repo.

Außer du bist natürlich alles in Personalunion. Aber dann hälst du dich ohnehin nur an deine eigene Konvention(was dann durchaus von anderen als Spaghetticode bezeichnet wird) also bloß nicht testen, wegen Zeitfraß und was dir noch so einfällt.

Aber bitte schiebe das vermeiden von Tests nicht auf die "enorme Zeit" die das fressen würde, für eine kleine Klasse die du erstmal nur lokal zum Laufen bringen willst. Das ist unredlich.

Ist das eigentlich wirklich das was SCRUM meint? Alles nach Gefühl, keine Form der Qualitätskontrolle? Robustheit? Erweiterbarkeit? Muss mir das echt mal ansehen, wie das als Paradigma formuliert ist und mit Leben gefüllt werden soll.

 

[kali-hi]

Über Buildserver etc. muss man ja überhaupt erstmal gar nicht sprechen, bei dem momentanen Stand.

Vergisst offenbar, dass ich privat entwickle und das Ganze schon auf GitHub läuft... Nur kenne ich eben auch die Theorie, wie etwas im Team abläuft. Und wirklich entkräften, dass Tests lange dauern können, konntest du meine Argumentation jetzt auch nicht.

 

[kali-hi]

Ich weiß ehrlich gesagt nicht, was dieses Thema noch bringen soll... Bitte schließen.

 

[tollertyp]

"Ein Geisterfahrer? Nein, hunderte..."

Die Diskrepanz zwischen Nutzung der Buzzwords und dem, was der Geisterfahrer propagiert, passt auf keine Kuhhaut.

Ergänzung (21. November 2025)

Das kann auch mal mehr als 5 Minuten dauern.

Also ich baue auf einem Firmen-Laptop (also keine tolle Build-Maschine) regelmäßig ein Projekt, in dem in der Summe über 5.000 Tests (also aufgerufene Test-Methoden) ausgeführt werden, und auch mindestens ein Test, der einen Spring-Container hochfährt. Es ist eine Dependency-Hölle. Der komplette Build mit Tests läuft in unter 5 Minuten, außer Maven aktualisiert die Snapshot-Dependencies, dann dauert es länger. Wie gesagt, es ist eine Dependency-Hölle. Aber auch das macht es - wenn ich es nicht anders möchte - nur einmal am Tag, und ich bezweifle, dass du so viele Snapshot-Dependencies bei dir drin hast...

Du hast nicht ein Argument geliefert, warum die Tests bei dir so viel Zeit in Anspruch nehmen würden. Und deine Erkenntnisangst in Verbidung mit Dunning-Kruger führt dazu, dass du dich auch nicht vom Gegenteil überzeugt. Stattdessen hast wirfst du lieber mit Buzzwords um dich, redest im ersten Satz von wichtigem Code, den du aber nicht durch Tests funktionsfähig halten willst.

Stattdessen kommen hypothetische Gründe, warum in manchen Szenarien Tests keine 100%ige Sicherheit bringen. Also niemand hier sagt, dass Tests das tun würden. Die Erfahrung zeigt aber, dass keine Tests das auch nicht tun.
Du kannst deine Haustüre auch offen stehen lassen, denn das Schließen der Türe und ein Türschloss sind auch keine 100%ige Sicherheit gegen Einbruch. Und das Aufschließen der Türe kann auch mal mehrere Minuten dauern.

 

[rallyco]

Ich weiß ehrlich gesagt nicht, was dieses Thema noch bringen soll... Bitte schließen.

🫡