Automatisiertes Testen von größeren und komplexen Prozessen

[Zrebna]

Hallo!

Ich bin bzgl. einer Abschlussarbeit gerade auf erster vorbereitender Recherche-Suche - folgender Hintergrund:
JUnit ist ja als Test Framework dafür prädestiniert einzelne Methoden und Module zu testen.
Ich frage mich jedoch, wie man in der Sotwareentwicklung in der Praxis große Prozesse automatisiert testen kann?
Z.b. Prozesse bzgl. Rezertifizierungen von digitalen Entitäten, wie z.B. Berechtigungen oder Geschäftsrollen.
Bei so einem Prozess gibt es viele Teilaufgaben, wie z.B.

• Aufgaben/Requests zur Überprüfung von existierenden Mitarbeiter-Berechtigungen erstellen
• Aufgaben über eine eingebaute Engine an Verantwortliche delegieren (z.B. an Abteilungsleiter des überprüften Mitarbeiters).
• Aufgaben können dann angenommen (und bearbeitet), abgelehnt oder weitergeleitet werden.
• Nach der Bearbeitung von Aufgaben, müssen Entscheidungen auditsicher festgehalten werden und ggf. Berechtigungsentzüge angestoßen werden.
• uvm.

Evtl. könnte man so einen Prozess auch mittels JUnit-Tests automatisiert testen, indem man einfach zig JUnit-Tests aneinanderreiht?

Jedoch muss/soll es (nach "Hören und Sagen") in der Praxis auch besser gehen.

Daher meine Eingangsfrage, um überhaupt einen Startpunkt für weitere Recherchen zu haben:
Viele von Euch in dieser Community arbeiten schon lange in der Sotwareentwicklung - wie testet ihr automatisiert größere Prozesse mit ggf. auch Abhängigkeiten?
Gibt es hier bereits bestehende Best Practices oder existierende Testing Frameworks (eben was anderes und ggf. in diesem Zusammenhang "mächtigeres" als JUNit), die darauf prädestiniert sind große und komplexe Pozesse zuverlässig zu testen?

Über Input bin ich dankbar.

Lg
Zrebna

 

[M.L.]

zig JUnit-Tests aneinanderreiht

Dafür wäre z.B. TestNG ein Schlagwort

 

[KonradN]

Welches Tooling man verwendet ist dabei eigentlich egal. Der Unterschied ist aus meiner Sicht, dass man bei Unit Tests in der Regel mit Mocking arbeitet und daher explizit keine Testumgebung aufbaut.

Bei den Abläufen automatisierst Du halt den ganzen Prozess. Da würde dann auch die Schnittstelle deutlich mehr dazu gehören so dass die Frage ist, was für Schnittstellen du hast. Es gibt da halt spezielle Tools um eben z.B. UI Tests zu erstellen.

In dem Projekt, in dem ich derzeit bin, haben wir diese Regression Tests - eine ganz große Menge Testcases, die auf Testdaten alle Operationen durchführt, die spezifiziert sind. Das läuft dann mehrere Stunden

Und da gibt es dann Test Cases, die als "Top Ten" Tests laufen und dessen Performance genau gemessen wird um genau zu sehen, wie die Performance sich verändert hat.

 

[Zrebna]

Dafür wäre z.B. TestNG ein Schlagwort

Danke schon einmal für den Input!

Interessant - TestNG ist auch eine mögliche Empfehlung, die chatGPT liefert, als ich mal gefragt habe:

1. End-to-End-Tests: Für große Prozesse, die viele Teilaufgaben und Abhängigkeiten haben, sind End-to-End-Tests eine häufige Wahl. Hierbei wird die gesamte Software wie ein Endbenutzer verwendet, um sicherzustellen, dass alle Teile des Prozesses ordnungsgemäß zusammenarbeiten. Frameworks wie Selenium, Cypress oder Playwright eignen sich gut für solche Tests.
2. Testautomatisierungswerkzeuge: Neben JUnit gibt es eine Vielzahl von Testautomatisierungswerkzeugen und Frameworks, die sich auf die Automatisierung großer Prozesse spezialisiert haben. Einige Beispiele sind TestNG, Cucumber oder Robot Framework. Diese bieten oft erweiterte Funktionen und eine bessere Unterstützung für Testautomatisierung in komplexen Szenarien.

Aber handelt sich bei TestNG nicht letztlich ebenfalls um ein Framework, was auch (analog zu JUnit) "nur" auf einzelne Unit-Tests (vorwiegend einzelne Klassen oder Methoden) spezialisiert ist?
Inwiefern eignet sich dieses Framework besser, als JUnit, um auch größere Prozesse (sehr viele Methodenaufrufe) zu testen?

Im wikipeidia-Artikel steht zum Beispiel:

TestNG ermöglicht eine flexible Gruppierung der Tests und Testmethoden mittels XML-Konfiguration oder Annotationen. Damit können beispielsweise Tests für unterschiedliche Teststufen (wie z. B. Modultests, Integrationstests, Akzeptanztests) oder auch Testumgebungen ausgewählt werden. Gruppen können auch mittels Regulären Ausdrücken gewählt, zu anderen Gruppen wieder zusammengefasst oder auch exkludiert werden.

Solche flexible Gruppierung könnte ja dann n viele Test-Methoden clustern und am Ende einen Prozess simulieren, wenn ich das korrekt verstehe.
Aber könnte sowas JUnit nicht?

Weitere aufkommende Fragen an Alle:
- Bzgl. der Textpassage von chatGPT:
Braucht man da quasi am Ende etwas aus den Kategorien 1 (End-to-End) und 2 (Testautomatisierungswerkzeuge)?
Mir ist nicht klar, ob diese Kategorien "Hand in Hand" gehen, oder ob je nach Prozessen man nur eine der beiden Kategorien braucht?
Hier habe ich leider im Eingangspost nicht erwähnt, wie die Ausgangssituation ist (kann den Eingangspost leider nicht mehr editieren),
daher hier:

Update/Hinzufügung zum Eingangspost:
Ausgangssituation:
Aktuell wird im Unternehmen (handelt sich um eine externe Abschlussarbeit) verwendet:
JUNit, eine Test-Datenbank und eine Continous Integration Pipeline.

- Unter welche der beiden Kategorien (chatGPT) würde folgendes Tool fallen?
-> https://www.telerik.com/teststudio
bzw.
https://www.telerik.com/teststudio-dev

- Hätte ihr Literaturempfehlungen, die mir bei meiner Abschlussarbeit helfen könnten?

Lg
Zrebna

 

[Zrebna]

Welches Tooling man verwendet ist dabei eigentlich egal. Der Unterschied ist aus meiner Sicht, dass man bei Unit Tests in der Regel mit Mocking arbeitet und daher explizit keine Testumgebung aufbaut.

Bei den Abläufen automatisierst Du halt den ganzen Prozess. Da würde dann auch die Schnittstelle deutlich mehr dazu gehören so dass die Frage ist, was für Schnittstellen du hast. Es gibt da halt spezielle Tools um eben z.B. UI Tests zu erstellen.

In dem Projekt, in dem ich derzeit bin, haben wir diese Regression Tests - eine ganz große Menge Testcases, die auf Testdaten alle Operationen durchführt, die spezifiziert sind. Das läuft dann mehrere Stunden

Und da gibt es dann Test Cases, die als "Top Ten" Tests laufen und dessen Performance genau gemessen wird um genau zu sehen, wie die Performance sich verändert hat.

Welche Tools und Frameworks verwendet ihr bei euch zum Testen?

 

[KonradN]

Welche Tools und Frameworks verwendet ihr bei euch zum Testen?

In dem Projekt, in dem ich derzeit arbeite, haben wir unsere eigenen Tools geschrieben. (Liegt mit daran, dass das Projekt schon ca. 30 Jahre läuft. Damals gab es vieles schlicht noch nicht.)

Bei Web Anwendungen ist z.B. Selenium ein oft verwendetes Tool.
Wenn es nicht um das Testen einer UI geht, dann kannst Du aber auch jedes Unit Test Framework verwenden. Was hindert Dich daran, über das Unit Test Framework auch z.B. das ganze Backend zu testen, also Testdaten in einer Datenbank bereit zu stellen, die Applikation auf der Datenbank zu starten und dann beliebige Abläufe zu testen? Hier ist evtl. zu überlegen, dass man dies von den eigentlichen Unit Tests trennt, damit Entwickler da nicht durch länger laufende Tests behindert werden.

 

[Zrebna]

In dem Projekt, in dem ich derzeit arbeite, haben wir unsere eigenen Tools geschrieben. (Liegt mit daran, dass das Projekt schon ca. 30 Jahre läuft. Damals gab es vieles schlicht noch nicht.)

Bei Web Anwendungen ist z.B. Selenium ein oft verwendetes Tool.

Danke, schaue ich mir an

Wenn es nicht um das Testen einer UI geht, dann kannst Du aber auch jedes Unit Test Framework verwenden.

Exakt, d.h. die UI soll nicht getestet werden.

Was hindert Dich daran, über das Unit Test Framework auch z.B. das ganze Backend zu testen, also Testdaten in einer Datenbank bereit zu stellen, die Applikation auf der Datenbank zu starten und dann beliebige Abläufe zu testen?

Tatsächlich, soll auch weiterhin JUnit verwendet werden und evtl. in Zusammenarbeit noch andere Tools, falls es Sinn macht - bin da momentan noch nicht tief genug drin, um das zu beurteilen, daher habe ich hier noch einen separierten Thread erstellt, bei dem ich noch einmal einen oder mehrere Schritte zurückgehe:

https://www.java-forum.org/thema/zuverlaessiges-automatisiertes-testen-im-eigenem-software-unternehmen-aufsetzen-how-to.202887/

Hier ist evtl. zu überlegen, dass man dies von den eigentlichen Unit Tests trennt, damit Entwickler da nicht durch länger laufende Tests behindert werden.

Was meinst du damit? Bzw., wie trennt man sowas in der Praxis?

Danke schon mal!

 

[KonradN]

Was meinst du damit? Bzw., wie trennt man sowas in der Praxis?

Meine erste Idee wäre, sowas in ein eigenes Projekt zu packen, Abhängigkeit zu dem Hauptprojekt. Dann können Entwickler problemlos weiter entwickeln und diese ganzen ausführlichen Tests behindern nicht den Ablauf. Als Entwickler führt man die Unit Tests regelmäßig aus daher sollten diese immer schnell durchlaufen.

 

[thecain]

Wir verwenden im moment:
-Junit 5
-Mockito
-Wiremock
-Testcontainer
-Pact
-Restassured

Mit diesen Tools/Libraries decken wir eigtl alle Teststufen für einen Service ab.

 

[philanthrop]

Wir verwenden im moment:
-Junit 5
-Mockito
-Wiremock
-Testcontainer
-Pact
-Restassured

Das sieht nach zu viel aus... Zudem wurde Spotbugs vergessen (statische Analyse).

 

[thecain]

Du scheinst es ja zu wissen

Spotbugs ist mMn kein automatisierter Test sondern ein Teil des Builds. Auf jeden Fall aber auch relevant.

 

[Zrebna]

Meine erste Idee wäre, sowas in ein eigenes Projekt zu packen, Abhängigkeit zu dem Hauptprojekt. Dann können Entwickler problemlos weiter entwickeln und diese ganzen ausführlichen Tests behindern nicht den Ablauf. Als Entwickler führt man die Unit Tests regelmäßig aus daher sollten diese immer schnell durchlaufen.

Ah ok, also meinst du quasi alles was mit Testen zu tun hat (also alle zig Test-Klassen, etc.) in ein eigenes Unterprojekt zu packen - falls das gemeint ist, dann ist dies bereits gegeben.

 

[Zrebna]

Wir verwenden im moment:
-Junit 5
-Mockito
-Wiremock
-Testcontainer
-Pact
-Restassured

Mit diesen Tools/Libraries decken wir eigtl alle Teststufen für einen Service ab.

Danke schon mal!

Kannst du evtl. konkret eure Teststufen aufzählen und dazuschreiben, welches von den Tools bei euch für welche Teststufe zum Einsatz kommt?

Und sind bei euch alle Test-Klassen, egal ob JUnit5 Tests oder Tests via Mockito in einem eigenem Unterprojekt, in dem Alles test-related drin steckt?

 

[thecain]

JUnit5 und Mockito in den Unit Tests
JUnit5, Wiremock und TestContainer in den Integration Tests (Hier wird auch die eigene Datenbank mit getestet, fremde Services sind aber mit Wiremock weggemockt).
Die beiden Teststufen sind im selben Modul wie der Code, einfach im test Ordner in maven.

RestAssured, Testcontainer und Wiremock in den Service Tests. Hier wird der Service von aussen getestet. Das ist dann auch ein eigenes Maven Modul. Hier laufen auch pact Tests zum sicherstellen der Consumer Contracts.

 

[LimDul]

Unsere Anwendung (Enterprise Anwendung) ist recht umfangreich. Wenn wir alle integrierten Komponenten starten sind das so um die 12 Docker Container. Wir haben sogenannte Integrationstests, die gegen diese Docker Instanzen laufen. Die laufen nicht in jedem Build mit, sondern nur in Builds auf main Branches, sowie 1x Nachts.

Diese Tests liegen in einem eigenen Maven-Sub-Modul und können auf verschiedene Weise gestartet werden. Sie sind Aufrufe, die am Ende Erfolg/Misserfolg + Liste von Meldungen im Misserfolg zurückgeben. Sie werden über Rest Exposed, so dass man man sie von außen anstarten kann, außerdem gibt es Unit-Tests (als Integrationstest klassizifziert, dass sie normalerweise nicht mitlaufen), die ebenfalls die Endpunkte aufrufen. Damit hat man mehrere Möglichkeiten die lokal oder auf dem Jenkins auszuführen.

Extrem viele gibt es nicht - sind knapp unter 40 Stück. Laufzeit von denen ist 10-20 Minuten, weil auch paar asynchrone Schritte drin sind, die mittels "Sleep" abgewartet werden bzw. komplette Batch-Läufe.

Diese Tests hinterlassen auch Spuren auf der Datenbank, dass heißt da werden echt Daten angelegt und verarbeitet und persistiert. Sie sind halt so aufgebaut, dass sie immer neue Daten anlegen, auch wenn schon welche da sind.

Gemockt ist da quasi gar nichts - außer Services zu externen Dienstleister, die nicht in unserer Kontrolle sind.

 

[Zrebna]

Eine konkrete Sache würde mich noch interessieren:

Kategorisiert ihr euere Tests auch irgendwie - also habt ihr eine Struktur, so dass verschiedene Testkategorien in verschiedenen packages sind?

 

[LimDul]

Normale Unit-Tests liegen immer im gleichen Package wie zu testende Unit. (halt nur unter src/test/java). Die Integrationstest liegen bewusst in einem einem eigenen Maven-Modul und sind somit separat. Weitere Unterteilungen gibt es nicht.

 

[Zrebna]

Ok, so haben wir es bis dato nicht.

Und zusätzlich so Kategorien in Über-Packages, wie z.B. "Tickets aus Kundenportal", "Past Hotfixes", "Gängige use cases testen (wie z.B. digitale Entität löschen)", Lebenszyklen, etc. habt ihr nicht.

Und unter den Über-Packages (Kategorien) würden dann die weiteren Unter-Packages genauso heißen, wie die zu testende Klasse, aber eben in src/test/java und die Klasse heißt dann eben "ClassXTest".

Zu Integrationstests:
Das sind ja eigentlich nur aneinandergereihte Unit-Tests, um letztlich einen größeren Prozess (mehrere Einzel-Funktionalitäten im Zusammenspiel) zu testen, oder?
Mit Maven-Modul meinst du hier in einem eigenem Maven-Unterprojekt?

 

[KonradN]

Zu Integrationstests:
Das sind ja eigentlich nur aneinandergereihte Unit-Tests, um letztlich einen größeren Prozess (mehrere Einzel-Funktionalitäten im Zusammenspiel) zu testen, oder?

Also Integrationstests sind keine Unit Tests! Ein Unit Test ist nun einmal gezielt der Test einer einzelnen Units ohne andere Dinge mit einzubeziehen. Integrationstests sind nun einmal der Tests, ob die Elemente sich integrieren lassen, also ob das Zusammenspiel funktioniert.

Was Du evtl. mit der Aussage meintest: Bei Integrationstests können auch Tools verwendet werden, die für Unit Tests verwendet werden. Bei der Wahl der Tools ist man halt relativ offen, daher kann man durchaus auch Test Frameworks, die vor allem aus Unit Tests bekannt sind, verwenden.

Bezüglich Plugins, die in Maven verwendet werden können für Integrations Tests ist evtl. folgender Link interessant:

https://www.baeldung.com/maven-integration-test

 

[LimDul]

Ok, so haben wir es bis dato nicht.

Und zusätzlich so Kategorien in Über-Packages, wie z.B. "Tickets aus Kundenportal", "Past Hotfixes", "Gängige use cases testen (wie z.B. digitale Entität löschen)", Lebenszyklen, etc. habt ihr nicht.

Nein, wie oben geschrieben - die Integrationstests sind ca. 40 Stück. Da lohnt eine weitere Unterteilung nicht. Der Rest sind wie gesagt Unit-Tests und die sollten im gleichen Package wie die zu testende Klasse liegen. Maximal ist ein Unit-Test kommentiert oder benannt mit einem Bug-Report.

Zu Integrationstests:
Das sind ja eigentlich nur aneinandergereihte Unit-Tests, um letztlich einen größeren Prozess (mehrere Einzel-Funktionalitäten im Zusammenspiel) zu testen, oder?

Unit-Test testen eine Klasse. Diese arbeiten auf dem öffentlichen und semi-öffentlichen (protected / package-Private) API einer Klasse. Alles drumherum ist idealerweise sinnvoll weg-gemockt bzw. abstrahiert. Die sind insbesondere oft technisch motiviert (Thema Äquivalenzklassen von Eingabewerten etc.) Das ist sehr oft losgelöst von fachlichen Anforderungen und Use Cases. Der Inhalt des Unit-Tests wird durch die Methoden-Signaturen vorgegeben.

Integrationstests testen Integrationen. Die setzen nicht auf Unit-Tests auf, sondern arbeiten (idealerweise) komplett auf der öffentlichen API der Anwendung, maximal noch auf öffentlicher API einzelner Module. Sie sollten aber generell nicht mehr auf protected oder package private API zugreifen. Insbesondere sollte in Integrationstests nach Möglichkeit gar nichts gemockt sein. Klar lässt sich das nicht immer zu 100% erreichen.
Integrationstests testen komplette Use Cases. Einzelne Klassen, Schnitt etc. interessieren da nicht. Sondern es interessiert, ist die Fachlich Anforderung korrekt.

Der Fokus ist also ein ganz anderer. Unit Test gehen mit der Lupe an ein sehr sehr kleines Element ran und abstrahieren drum herum alles weg. Die Intergrationstests hingegen schauen von außen auf die gesamte Anwendung. Da gibt es sehr sehr wenig Überlappungen.

Wenn man sagen würde, Integrationstests sind nur Aneinanderreihungen von Unit-Tests - wo ist da der Sinn? Sobald ein Unit-Test rot ist, ist der Integrationstest rot und sobald alle Unit-Tests grün sind, ist der Integrationstest grün - da kann ich mir den auch sparen.

Mit Maven-Modul meinst du hier in einem eigenem Maven-Unterprojekt?

Korrekt.

 

[Zrebna]

Also Integrationstests sind keine Unit Tests! Ein Unit Test ist nun einmal gezielt der Test einer einzelnen Units ohne andere Dinge mit einzubeziehen. Integrationstests sind nun einmal der Tests, ob die Elemente sich integrieren lassen, also ob das Zusammenspiel funktioniert.

Was Du evtl. mit der Aussage meintest: Bei Integrationstests können auch Tools verwendet werden, die für Unit Tests verwendet werden. Bei der Wahl der Tools ist man halt relativ offen, daher kann man durchaus auch Test Frameworks, die vor allem aus Unit Tests bekannt sind, verwenden.

Ich meinte halt, dass bei einem Integrationstest mehrere "Einzelsachen" im Zusammenspiel getestet werden. Das wird doch oft dann einfach ein Anwendungsfall sein, der getestet wird. Bei so einem Anwendungsfall (z.B. Login -> Waren auswählen -> Waren im Warenkorb ablegen -> kaufen) werden ja zig Methoden durchlaufen. Jede Methode kann man mittels einem JUNit-Test testen.
Daher dachte ich, dass man bei einem solchen Anwendungsfalls eben JUnit-Tests aneinanderreiht und ggf. sagt, dass eben alle erfolgreich durchlaufen müssen, damit der gesamte Inegrationstest "grün" durchgeht -> also erfolgreich ist.

Bezüglich Plugins, die in Maven verwendet werden können für Integrations Tests ist evtl. folgender Link interessant:

https://www.baeldung.com/maven-integration-test

 

[Zrebna]

Wenn man sagen würde, Integrationstests sind nur Aneinanderreihungen von Unit-Tests - wo ist da der Sinn? Sobald ein Unit-Test rot ist, ist der Integrationstest rot und sobald alle Unit-Tests grün sind, ist der Integrationstest grün - da kann ich mir den auch sparen.

Ja, so habe ich es bis dato scheinbar fehlerhafterweise angenommen

Ich mache mich mal schlau, wie Integrationstests in der Praxis technisch aussehen und umgesetzt werden.^^

 

[Zrebna]

Hi,
Ich greife nochmal diesen Thread auf.

Mittlerweile habe ich etwas unsere Fehlerliste (Hotfix-Liste) analysiert und es fällt auf, dass es oftmals beim Kunden wegen "Unspektakulärem" nach dem geplantem Maintenance Release "knallt".
Konkret kamen viele Fehler aufgrund NPEs zu stande, weil einfach bei Aufrufen Null-Checks vergessen wurden.
Meiner Recherche nach ist das beste Mittel NPEs vorzubeugen die Art und Weise des Programmierens selber.
Z.b. defensives Programmieren oder Optionals verwenden (nie null returnen, sondern eben Optionals).
All das machen wir schon und ist eher nicht interessant für meine Abschlussarbeit.

Jedoch habe ich auch rausgefunden, dass man wohl NPEs ganz gut mit statischer Codeanalyse vorbeugen kann. Mein betreuender Professor hält diese Möglichkeit auch für gut und findet auch, dass diese Richtung sich für meine Arbeit (soll ja ums Testen gehen) eignet, weil statische Codeanalyse unter statisches Testen fällt.

Daher folgende Fragen:

1. Ist es korrekt, dass man NPEs gut mit statischer Codeanalyse vorbeugen kann?

2. Falls 1. zutrifft, welche Tools würden sich bei der Prävention von NPEs ganz besonders eignen?
Das hier schon angesprochene SpotBugs? SonarQube? Oder was anderes?

3. Gibt es noch andere Möglichkeiten, die irgendwas mit Testen zu tun haben, NPEs vorzubeugen?

Lg
Zrebna

 

[LimDul]

Hi,
1. Ist es korrekt, dass man NPEs gut mit statischer Codeanalyse vorbeugen kann?

Ja. Logischerweise nicht zu 100%, aber einem signifikanten Anteil

2. Falls 1. zutrifft, welche Tools würden sich bei der Prävention von NPEs ganz besonders eignen?
Das hier schon angesprochene SpotBugs? SonarQube? Oder was anderes?

Wir nutzen bei uns SpotBugs zusammen mit den Annotationen CheckForNull / NonNull (https://spotbugs.readthedocs.io/en/stable/annotations.html)

Das deckt schon extrem viel auf. SpotBugs warnt einen dann, wenn man eine Methode oder Field mit CheckForNull annotiert und dann auf den Rückgabewert oder das Field zugreift, ohne vorher einen Null-Check zu machen. Bzw. wenn man eine Methode oder Field mit NonNull Annotiert, dann gibt es eine Warnung, wenn da Null zugewiesen wird.

Die Grenzen sind dabei externe Libs, wo man die Aufrufe ggf. wrappen muss. Zudem erkennt SpotBugs nicht alle Konstellationen, so dass Fälle gibt, wo er warnt, obwohl die Variable nie null sein kann. Das lässt sich in der Regel aber mit etwas umstellen des Codes beheben. Meist wird der Code auch lesbarer und robuster. Standardfälle sind z.B.

@CheckForNull
public Object getField()  {
  return this.,myField;
}

...
if (getField() != null) {
  getField().callMethod();
}

Da meckert Spotbugs, weil die statische Code Analyse nicht garantieren kann, dass die beiden Aufrufe von getField die gleichen Werte zurückgeben. (Und in einer Multithreaded Umgebung muss das auch nicht garantiert sein)

3. Gibt es noch andere Möglichkeiten, die irgendwas mit Testen zu tun haben, NPEs vorzubeugen?

Vernünftige Unit-Tests. Unit-Tests, die eine möglichst hohe Code-Abdeckung haben und wo man insbesondere auch Randfälle (Null, MAX_INT etc.) abdeckt decken auch schon viel auf. Grundsätzlich sollte man eine Methode immer auch mit null in Tests aufrufen und wenn man andere Systeme mockt, sollte man da auch immer mal null im Test zurückgeben lassen. Damit findet man auch schon viel.

 

[Robert Zenz]

Vernünftige Unit-Tests. Unit-Tests, die eine möglichst hohe Code-Abdeckung haben und wo man insbesondere auch Randfälle (Null, MAX_INT etc.) abdeckt decken auch schon viel auf. Grundsätzlich sollte man eine Methode immer auch mit null in Tests aufrufen...

Also um das zu verdeutlichen, bei einem Unit-Test solltest du auch ds *Fehlerverhalten( mit testen. Beispiel (so wie ich das immer mache):

@Test
public void testOperation() {
    Assertions.assertEquals("bla", instance.operation("blub"));
}

@Test
public void testOperationWithEmptyString() {
    Assertions.assertEquals("", instance.operation(""));
}

@Test
public void testOperationWithNull() {
    Assertions.assertEquals("", instance.operation(null));
}

Wenn es darum geht geworfene Ausnahme zu testen bin ich ziemlich eigen, weil ich ja eigentlich nur die Ausnahme schlucken will welche meinen Erwartungen entspricht, alles andere soll 1:1 weiterfliegen. Auch teste ich dann immer die Nachricht um sicher zu gehen dass ich die richtige erwischt habe. Das ist aber so ein biszchen ein Streitthema:

@Test
public void testOperationWithNull() {
    try {
        instance.operation(null);
      
        Assertions.fail("Could should have failed with an IllegalArgumentException because parameter is null, but did not.");
    } catch (IllegalArgumentException e){
        if (!e.getMessage().equals("Parameter \"parameter\" was null.")) {
            throw e;
        }
    }
}

Das hatte fuer mich immer den Vorteil dass wenn eine andere Ausnahme fliegt, ich keinen "Testfehler" bekomme, wo ich mir die originale Ausnahme herauskramen muss, sondern direkt den Fehler vor der Nase habe welcher passiert ist (und nicht passieren sollte).

---

Es gibt dann auch Parameterized Tests fuer solche Faelle wo amn unterschiedliche Parameter-Werte testen will. Ich fand die zuletzt aber etwas unuebersichtlicher als wenn ich die Faelle haendisch tippe.

 

[KonradN]

Auch wenn es nichts direkt mit dem Testen zu tun hat, möchte ich auch noch die Möglichkeit erwähnen, dass man in Code auch auf null verzichten kann. Dann hat man ein Optional und sieht da direkt, dass da ein Wert nur optional ist. Und man hat oft deutlich schönere Konstrukte für Zugriffe wie z.B. das orElse und so.

Aber beim Umgang mit null hat @LimDul bereits eine sehr gute Antwort geschrieben - dem kann ich bezüglich null Werte nichts hinzu fügen.

 

[Oneixee5]

Mit SonarLint sollte mögliche NPE's schon beim Programmieren in der IDE angezeigt werden. Allerdings gibt es da Limitierungen. Meiner Erfahrung nach werden aber eher zu viele als zu wenige mögliche Fehler angezeigt. Einen guten Gesamtüberblick hat man mit Sonarqube-Server. Hier sieht man die Codeanalyse, nicht nur seines eigenen Codes, sondern aller Beteiligten und beteiligten Projekte und auch mögliche Schwachstellen der Tests und sicherheitsrelevante Probleme.

 

[Oneixee5]

, dass man in Code auch auf null verzichten kann.

Ich denke das funktioniert nicht. Man verwendet nicht nur eigenen Code. Auch Code aus dem JDK oder externen Libs könnte null zurückgeben oder null erwarten.
Die Arbeit mit RUST war da erst mal ein Kulturschock, dort gibt es NULL in dem Sinne überhaupt nicht.

 

[KonradN]

Ich denke das funktioniert nicht. Man verwendet nicht nur eigenen Code. Auch Code aus dem JDK oder externen Libs könnte null zurückgeben oder null erwarten.
Die Arbeit mit RUST war da erst mal ein Kulturschock, dort gibt es NULL in dem Sinne überhaupt nicht.

Ja klar. Es geht hier um eigenen Code und darum, es dort eben besser zu machen. Bei fremden Code hast Du auch oft genug, dass eben die Annotations auch nicht da sind und Du daher auch mit Spotbugs "dumm" da stehst. Außer eben:

Die Grenzen sind dabei externe Libs, wo man die Aufrufe ggf. wrappen muss.

Aber man will natürlich nicht alles wrappen.

Aber es ist schon ein guter Anfang, wenn Entwickler erst einmal sensibilisiert sind um dann entweder Optionals zu verwenden oder eben wenigstens die Annotations setzt um eine statische Codeanalyse zu ermöglichen.

Daher wäre ansonsten mein (scherzhafter) Tipp für ein geniales Tool für den Chef:

Amazon.de

Preiswert, effektiv, verringert unnötige Diskussionen um Clean Code um 100% 😈

 

[Zrebna]

Vielen Dank schon mal!
Ich schreibe paar Anmerkungen/Fragen bold direkt in den Quote.

Ja. Logischerweise nicht zu 100%, aber einem signifikanten Anteil


Wir nutzen bei uns SpotBugs zusammen mit den Annotationen CheckForNull / NonNull (https://spotbugs.readthedocs.io/en/stable/annotations.html)

Das deckt schon extrem viel auf. SpotBugs warnt einen dann, wenn man eine Methode oder Field mit CheckForNull annotiert und dann auf den Rückgabewert oder das Field zugreift, ohne vorher einen Null-Check zu machen. Bzw. wenn man eine Methode oder Field mit NonNull Annotiert, dann gibt es eine Warnung, wenn da Null zugewiesen wird.

Die Grenzen sind dabei externe Libs, wo man die Aufrufe ggf. wrappen muss. Zudem erkennt SpotBugs nicht alle Konstellationen, so dass Fälle gibt, wo er warnt, obwohl die Variable nie null sein kann. Das lässt sich in der Regel aber mit etwas umstellen des Codes beheben. Meist wird der Code auch lesbarer und robuster. Standardfälle sind z.B.

@CheckForNull
public Object getField()  {
  return this.,myField;
}

...
if (getField() != null) {
  getField().callMethod();
}

Da meckert Spotbugs, weil die statische Code Analyse nicht garantieren kann, dass die beiden Aufrufe von getField die gleichen Werte zurückgeben. (Und in einer Multithreaded Umgebung muss das auch nicht garantiert sein)

Ich verstehe nicht ganz, wieso er da meckern würde? Denn wie mit der Annotation @CheckForNull "befohlen", hast du doch weiter unten einen null-check eingebaut...

Vernünftige Unit-Tests. Unit-Tests, die eine möglichst hohe Code-Abdeckung haben und wo man insbesondere auch Randfälle (Null, MAX_INT etc.) abdeckt decken auch schon viel auf. Grundsätzlich sollte man eine Methode immer auch mit null in Tests aufrufen und wenn man andere Systeme mockt, sollte man da auch immer mal null im Test zurückgeben lassen. Damit findet man auch schon viel.

Stimmt. Aber sehe ich das richtig, dass eine Prevention-Strategie mittles JUnit-Tests nur dann Sinn macht, wenn quasi für (fast) jede Methode ebenfalls ein Test geschrieben werden müsste, wo dann auch mit null (z.B. als Input-Param) getestet wird? Also sehr hohe punktuelle Testabdeckung notwendig?

 

[Zrebna]

Also um das zu verdeutlichen, bei einem Unit-Test solltest du auch ds *Fehlerverhalten( mit testen. Beispiel (so wie ich das immer mache):

@Test
public void testOperation() {
    Assertions.assertEquals("bla", instance.operation("blub"));
}

@Test
public void testOperationWithEmptyString() {
    Assertions.assertEquals("", instance.operation(""));
}

@Test
public void testOperationWithNull() {
    Assertions.assertEquals("", instance.operation(null));
}

Wenn es darum geht geworfene Ausnahme zu testen bin ich ziemlich eigen, weil ich ja eigentlich nur die Ausnahme schlucken will welche meinen Erwartungen entspricht, alles andere soll 1:1 weiterfliegen. Auch teste ich dann immer die Nachricht um sicher zu gehen dass ich die richtige erwischt habe. Das ist aber so ein biszchen ein Streitthema:

@Test
public void testOperationWithNull() {
    try {
        instance.operation(null);
     
        Assertions.fail("Could should have failed with an IllegalArgumentException because parameter is null, but did not.");
    } catch (IllegalArgumentException e){
        if (!e.getMessage().equals("Parameter \"parameter\" was null.")) {
            throw e;
        }
    }
}

Das hatte fuer mich immer den Vorteil dass wenn eine andere Ausnahme fliegt, ich keinen "Testfehler" bekomme, wo ich mir die originale Ausnahme herauskramen muss, sondern direkt den Fehler vor der Nase habe welcher passiert ist (und nicht passieren sollte).

---

Es gibt dann auch Parameterized Tests fuer solche Faelle wo amn unterschiedliche Parameter-Werte testen will. Ich fand die zuletzt aber etwas unuebersichtlicher als wenn ich die Faelle haendisch tippe.

Danke!

Bzgl. deinen beiden Test-Methoden 'testOperationWithNull() '.
Bei der ersten ist null als Übergabeparameter erlaubt und die Methode liefert in solchem Falle einen leeren String ("") zurück.

Bei der zweiten Methode ist quasi null als Übergabe-Param nicht mal zulässig.
Verstehe ich das richtig?

Irgendwie scheinen mir JUnit-Tests bei der Vorbeugung von NPEs "limitierter" als ggf. statische Codeanalyse?
Denn oft fallen NPEs nicht, weil null returned worden ist, oder null als Übergabe-Param übergeben worden ist, sondern weil ein Objekt, das null ist eine Methode aufgerufen hat, also z.B.:

// employee == null
employee.getFirstName(); // -> NPE

Bei "Parameterized Tests" musste ich direkt an Fuzzing denken - wäre das ggf. auch noch eine Möglichkeit NPEs vorzubeugen?

 

[Zrebna]

Auch wenn es nichts direkt mit dem Testen zu tun hat, möchte ich auch noch die Möglichkeit erwähnen, dass man in Code auch auf null verzichten kann. Dann hat man ein Optional und sieht da direkt, dass da ein Wert nur optional ist. Und man hat oft deutlich schönere Konstrukte für Zugriffe wie z.B. das orElse und so.

Aber beim Umgang mit null hat @LimDul bereits eine sehr gute Antwort geschrieben - dem kann ich bezüglich null Werte nichts hinzu fügen.

Wir verwenden bereits an vielen Stellen Optionals, aber scheinbar noch nicht häufig genug xD

 

[Robert Zenz]

Bzgl. deinen beiden Test-Methoden 'testOperationWithNull() '.
Bei der ersten ist null als Übergabeparameter erlaubt und die Methode liefert in solchem Falle einen leeren String ("") zurück.

Bei der zweiten Methode ist quasi null als Übergabe-Param nicht mal zulässig.
Verstehe ich das richtig?

Japp. Etwas konstruiert/pseudo-code das Beispiel.

Irgendwie scheinen mir JUnit-Tests bei der Vorbeugung von NPEs "limitierter" als ggf. statische Codeanalyse?

Jein. Unit-Tests werden verwendet um Verhalten festzuzementieren, also wenn du willst dass das Verhalten so bleibt, und wenn nicht, du benachrichtigt wirst dass es sich geaendert hat. Helfen beim finden von Fehlern tut es nur dann wenn du die notwendingen Permutationen der Parameter/Zustaende auch in Tests abbildest.

Bei "Parameterized Tests" musste ich direkt an Fuzzing denken - wäre das ggf. auch noch eine Möglichkeit NPEs vorzubeugen?

Ja, habe ich aber noch nie gemacht.

Denn oft fallen NPEs nicht, weil null returned worden ist, oder null als Übergabe-Param übergeben worden ist, sondern weil ein Objekt, das null ist eine Methode aufgerufen hat, also z.B.:

Ja, du muesstest eben den Ausgangszustand zu dem Fehler in einem Test abbilden. Das kann gut gehen, kann aber kompliziert sein. Da hilft dann wiederum meistens die statische Analyse.

 

[Zrebna]

Mit SonarLint sollte mögliche NPE's schon beim Programmieren in der IDE angezeigt werden. Allerdings gibt es da Limitierungen. Meiner Erfahrung nach werden aber eher zu viele als zu wenige mögliche Fehler angezeigt. Einen guten Gesamtüberblick hat man mit Sonarqube-Server. Hier sieht man die Codeanalyse, nicht nur seines eigenen Codes, sondern aller Beteiligten und beteiligten Projekte und auch mögliche Schwachstellen der Tests und sicherheitsrelevante Probleme.

Kann das SpotBugs oder SonaQube auch? Denn für die Abschlussarbeit müsste ich es mit einem OpenSource Tool probieren bzw. das muss reichen.

edit: Habe erst zu spät gelesen, dass du SonaQube später noch erwähnt hast.
Kann man SonaQube auch so konfigurieren, damit jeder Entwickler (erstmal) nur seinen eigenen lokalen Code untersuchen lassen kann?

edit 2: Weiß Jemand, ob SonaQube auch so NULL-Annotationen anbietet?

 

[LimDul]

Ich verstehe nicht ganz, wieso er da meckern würde? Denn wie mit der Annotation @CheckForNull "befohlen", hast du doch weiter unten einen null-check eingebaut...

Es gibt ja (auf Basis der statischen Code-Analyse) keine Garantie, dass zwei Aufrufe von getField das gleiche liefern.
Nehmen wir mal folgende Implementierung von getField:

public Object getField() {
return Random.newInt()%2 == 0 ? null : this.myField;
}

Nun kann es sein, dass der erste Aufruf von getField nonNull liefert, aber der zweite null.

Die Lösung ist bei sowas den Code wie folgt umzubauen:

var myVar = getField();
if (myVar != null) {
  myVar.callMethod();
}

Stimmt. Aber sehe ich das richtig, dass eine Prevention-Strategie mittles JUnit-Tests nur dann Sinn macht, wenn quasi für (fast) jede Methode ebenfalls ein Test geschrieben werden müsste, wo dann auch mit null (z.B. als Input-Param) getestet wird? Also sehr hohe punktuelle Testabdeckung notwendig?

Ja, man muss da dann entsprechend viele Unit-Tests schreiben - aber das sollte man eh.

Irgendwie scheinen mir JUnit-Tests bei der Vorbeugung von NPEs "limitierter" als ggf. statische Codeanalyse?
Denn oft fallen NPEs nicht, weil null returned worden ist, oder null als Übergabe-Param übergeben worden ist, sondern weil ein Objekt, das null ist eine Methode aufgerufen hat, also z.B.:

// employee == null
employee.getFirstName(); // -> NPE

Sowas kann man mit Unit-Tests problemlos finden.
Irgendwo kommt die Variable "employee" ja her. Entweder es ist ein Übergabe Paramater oder sie wird anderswo erzeugt. Und durch diese Codestränge sollte ein Unit-Test ja durchlaufen.

Die Idee eines Unit-Tests ist ja, eine "Unit" in allen Konstellationen zu testen. Wenn man alle Konstellationen durchtestet kann es (in der Theorie) keinen Durchlauf geben, der nicht getestet wurde.

 

[Zrebna]

Noch eine weitere Frage - Stichwort: Pair-Programming:

Bei Pair-Programming sitzen ja zwei Programmierer an einem Arbeitsplatz und arbeiten zusammen (reviewen sich u.a. live).
Fallen Review-Prozesse semantisch auch noch unter Pair-Programming oder per Definition nicht mehr?

Also wenn Entwickler sich gegenseitig reviewen, d.h. ihren Code, aber halt nicht in "Live-Code-Time". Also ich code was und lass paar Tage später den Code durch einen anderen Entwickler reviewen...

 

[KonradN]

Fallen Review-Prozesse semantisch auch noch unter Pair-Programming oder per Definition nicht mehr?

Pair-Programming bezieht sich auf den Prozess der Programmierung. Bei einem Review wird nicht aktiv Entwickelt sondern es wird nur ein Review durchgeführt. Daher fällt das nicht unter Pair-Programming.

 

[Zrebna]

Super, dann wäre das auch geklärt^^

Was anderes:
Gibt es Tools die eine Software (also den Code) so analysieren können, damit man interessante Zahlen rausfinden kann? Z.b. Wieviele Klassen hat die Software? Wieviele Methoden hat sie? Und folglich wie hoch ist die Testabdeckung?

 

[LimDul]

Code Quality Tool & Secure Analysis with SonarQube

Empower development teams with a code quality & security solution that deeply integrates into your enterprise environment that enables you to deploy Clean Code securely, consistently and reliably.

www.sonarsource.com

Das dürfte das bekannteste sein.

 

[Zrebna]

Code Quality Tool & Secure Analysis with SonarQube

Empower development teams with a code quality & security solution that deeply integrates into your enterprise environment that enables you to deploy Clean Code securely, consistently and reliably.

www.sonarsource.com

Das dürfte das bekannteste sein.

SonarQube hatten wir bis dato auch als Favoriten bzgl. Auswahl des Tools für statische Codeanalyse gehabt 👍
Dann kurz zu SonarQube:
Das kann also
a.) Dabei behilflich sein NPEs vorzubeugen (und vieles weitere) und bietet sicher auch Annotations an...?
b.) Kann eine Software auch auf interessante Zahlen analysieren - siehe letzte Frage?

 

[Oneixee5]

SonarQube hatten wir bis dato auch als Favoriten bzgl. Auswahl des Tools für statische Codeanalyse gehabt 👍
Dann kurz zu SonarQube:
Das kann also
a.) Dabei behilflich sein NPEs vorzubeugen (und vieles weitere) und bietet sicher auch Annotations an...?
b.) Kann eine Software auch auf interessante Zahlen analysieren - siehe letzte Frage?

Try out SonarQube

Follow these steps to try out SonarQube.

docs.sonarsource.com

 

[Zrebna]

Try out SonarQube

Follow these steps to try out SonarQube.

docs.sonarsource.com

Würde schon Input bzw. eine Abschätzung meiner beiden Fragen vorab schätzen, weil ich mich je nach Antwort dann auf das Tool erstmal comitte und nicht Zeit wasten will, indem ich etwas teste, was nicht mal meine zwei basic Anforderungen kann.

 

[Marinek]

Sonar Cube ist ein Tool zur Visualisierung von Ergebnissen einer statischen code Analyse.

Diese Ergebnisse kommen aus einem Tool, dass lokal die Ergebnisse sammelt. Wenn es ein Software Test gibt, dann kann auch die Testabdeckung ermittelt werden.

Eine kurze Bilder Googlesuche hat ergeben, dass die Anzahl der Klassen und Methoden durchaus dargestellt wird.

Würde schon Input bzw. eine Abschätzung meiner beiden Fragen vorab schätzen, weil ich mich je nach Antwort dann auf das Tool erstmal comitte und nicht Zeit wasten will, indem ich etwas teste, was nicht mal meine zwei basic Anforderungen kann.

Na hoffentlich wirst du deine Entscheidung nicht auf Grundlage einiger Postings in einem Forum treffen.

Wir kennen nicht alle deine Anforderungen. Lediglich dass Anzahl Klassen und Methoden aufgeführt wird. Darauf kommt es hier nicht an.

Eine Aufstellung von Anforderungen ist unerlässlich. Entsprechende Kandidaten müssen hinsichtlich der Anforderungen evaluiert und bewertet werden.

Erst dann kannst du eine sinnvolle Entscheidung treffen. Das ist egal wie du es drehst und wendest kein Time Waste.

 

[KonradN]

Also bezüglich NPE wurde das doch schon gesagt:

Mit SonarLint sollte mögliche NPE's schon beim Programmieren in der IDE angezeigt werden. Allerdings gibt es da Limitierungen. Meiner Erfahrung nach werden aber eher zu viele als zu wenige mögliche Fehler angezeigt. Einen guten Gesamtüberblick hat man mit Sonarqube-Server. Hier sieht man die Codeanalyse, nicht nur seines eigenen Codes, sondern aller Beteiligten und beteiligten Projekte und auch mögliche Schwachstellen der Tests und sicherheitsrelevante Probleme.

Und die "interessanten Zahlen" - was ist interessant?
Du willst vielleicht einfach einmal schauen, was Du so an Details unter Analyzing source code overview (sonarsource.com) findest.

Oder evtl. willst Du paar Bilder dazu ansehen?

sonarqube analysis report example - Bing

Mit der intelligenten Bing-Suche können Sie die gewünschten Informationen schneller und einfacher finden und dabei Punkte sammeln.

www.bing.com

 

[Zrebna]

Sonar Cube ist ein Tool zur Visualisierung von Ergebnissen einer statischen code Analyse.

Meiner bisherigen Infos nach ist es nicht nur ein Visualisierungstool, sondern betreibt auch selber statische Codeanalyse. Momentan bin ich noch mit der Schmerzpunkt- und "root cause"-Analyse beschäftigt, aber relativ bald fertig. Dann werde ich das Tool selber mal aufsetzen und testen...ich sammel halt vorab schon paar Infos, bevor es "ernst" wird.

Diese Ergebnisse kommen aus einem Tool, dass lokal die Ergebnisse sammelt. Wenn es ein Software Test gibt, dann kann auch die Testabdeckung ermittelt werden.

Eine kurze Bilder Googlesuche hat ergeben, dass die Anzahl der Klassen und Methoden durchaus dargestellt wird.


Na hoffentlich wirst du deine Entscheidung nicht auf Grundlage einiger Postings in einem Forum treffen.

Ich treff keine Entscheidungen aufgrund Forenposts, aber nehme hilfreichen Input, den es hier im Forum einfach oftmals gibt, auf jeden Fall mit auf...wie auch Input aus jeder anderen (auch gängigeren) Info-/Recherche-Quelle.

 

[Zrebna]

Testet auf oder beugt ihr fehlenden oder fehlerhaften DB-Migrationen (um Abwärtskompatibilität eurer SW-Versionen zu sichern) vor?

 

[Zrebna]

Eine Sache würde mich noch interessieren, und zwar speziell an Alle, die hier im Unternehmen SonarQubeServer nutzen:

Im Rahme meiner Abschlussarbeit ist nun die Entscheidung gefallen, dass wir bzgl. statischer Codeanalyse auch mit SonarQube "gehen" werden.
Nun recherchiere ich gerade bzgl. den verschiedenen Editions, weil sich ja die Frage stellt, welche Edition wir benötigen bzw. welche erstmal ausreicht. Es gibt vier Editions, jedoch schwanken wir lediglich zwischen den ersten beiden Editions:
Community Edition (Open Source) und Developer Edition.
Ich habe mir hier nun mal die Gegenüberstellung der Editions angesehen:

Download | SonarQube

Get the latest LTS and version of SonarQube the leading product for Code Quality and Security from the official download page.

www.sonarsource.com

Bei dieser Gegenüberstellung scheint es mir, dass uns die Community Edition erstmal ausreichen würde. Wir versionieren momentan noch mittels SVN (Umstieg auf Git in den nächsten 6-12 Monaten geplant) und haben letztlich wenige relevante branches, sodass das zusätzliche feature der Dev-Edition (branches separat analysieren) erstmal nicht so dringlich ist. Außerdem geht es ja bzgl. der externen Abschlussarbeit (QS verbessern) darum die ganze Basis zu analysieren und uns Metriken, Code-Smell-Hints, etc. zu liefern.

Fragen:
1. Denkt ihr, dass die Community Edition für meine Belange erstmal reicht? Hat Jemand von euch schon mal die CommunityEdition verwendet und war zufrieden, bzgl. den requirements, die ich benötige -> Metriken, Code-Smell-Hints der gesamten Code-Basis liefern.
2. Ist es richtig, dass es bei der Community Edition kein Limit bzgl. Lines of Code gibt?
3. Ist es korrekt (Quelle: stackoverflow), dass die CommunityEdition auch für commercial use erlaubt ist?
Ist eine externe Abschlussarbeit bereits commercial use, wenn sie dem Unternehmen ggf. Mehrwert bzgl. Infos liefern kann?
4. Geht der firmeneigene Code bei der SonarQube "rauß" (das wollen wir auf keinen Fall)? Gibt es diesbzgl. Unterschiede zur CommunityEdition?
5. Angenommen wir versuchen es mit der Community Edition und stellen fest, dass diese doch nicht reicht.
Kann man in diesem Fall leicht auf die Dev Edition upgraden, sodass bisherige Konfigurationen und Arbeit, die man mit der Community Edition
reingesteckt hat, erhalten bleibt? Oder ist dann alles "weg" und man muss wieder ganz von vorne beginnen?

Vielleicht hab ich ja Glück und Jemand kennt sich hier etwas aus. Recherchiere/frage natürlich auch an anderen Stellen...

Lg
Zrebna

 

[Marinek]

1. Denkt ihr, dass die Community Edition für meine Belange erstmal reicht? Hat Jemand von euch schon mal die CommunityEdition verwendet und war zufrieden, bzgl. den requirements, die ich benötige -> Metriken, Code-Smell-Hints der gesamten Code-Basis liefern.

Es gibt hierdrauf zwei Antworten:

1. Aus dem wissenschaftlichen Kontext: Du musst zwingend Anforderungen zunächst definieren, anschließend benötigst du eine Bewertungsstrategie von verschiedenen Ausprägungen. Danach kannst du sagen "Dies und das ist richtig". Alles andere ist in meinen Augen nicht wissenschaftlich und daher falsch.

Ich merke gerade gerade, dass Abschlussarbeit sich auch auf eine Ausbildun beziehen kann. In diesem Fall gilt ähnliches. Du benötigst eine eigene Entscheidung. Diese Entscheidung kannst du nur auf vorhandenen Informationen treffen. Oft wird hier genommen: Wie lange brauche ich, bis sich der Einsatz bezahlt gemacht hat. Make or Buy Entscheidung oder ähnliches.

2. Hier im Forum: Wir wissen nicht, was du berauchst. Offensichtlich unterscheiden sich die Editionen in den Sprachen, die sie unterstützen. Und ein paar sekundären Features wie bessere Darstellung von mehreren Branches und Pullrequest. Diese haben wir schon immer (Unternehmen mit 150 Personen und 4000 Personen ) mit der Community Edition gemacht.

Aber daraus kannst du keine Schlüsse auf deine Anforderungen schließen. Die kennen wir nicht. Eventuell programmiert ihr in Cobol ...

2. Ist es richtig, dass es bei der Community Edition kein Limit bzgl. Lines of Code gibt?

Die ist kostenlos. Wir haben definitiv mehr als 120 k LoC gehabt.

3. Ist es korrekt (Quelle: stackoverflow), dass die CommunityEdition auch für commercial use erlaubt ist?

Wir haben diese immer benutzt.

Ist eine externe Abschlussarbeit bereits commercial use, wenn sie dem Unternehmen ggf. Mehrwert bzgl. Infos liefern kann?

Das musst du deinen Anwalt fragen. Aus meinem Jura-Studium: Kommerziell handelt jemand mit Gewinnabsicht. Solange du also deine Abschlussarbeit nicht massenweise verkaufst mit Gewinnabsicht, dann sollte es in den privaten Bereich fallen.

4. Geht der firmeneigene Code bei der SonarQube "rauß" (das wollen wir auf keinen Fall)? Gibt es diesbzgl. Unterschiede zur CommunityEdition?

Wenn ihr die on premise Version nutzt nicht. Es gibt auch eine Cloud Variante.

Ich empfehle hier wirklich mal es auszuprobieren. Die meisten Fragen gerade solche sind dann klar. Wenn du ein System aufsetzt ohne INet Zugang, wirst du feststellen, wie gut es klappt.

Angenommen wir versuchen es mit der Community Edition und stellen fest, dass diese doch nicht reicht.
Kann man in diesem Fall leicht auf die Dev Edition upgraden, sodass bisherige Konfigurationen und Arbeit, die man mit der Community Edition
reingesteckt hat, erhalten bleibt? Oder ist dann alles "weg" und man muss wieder ganz von vorne beginnen?

Keine Ahnung. Hier müsste man den Support von Sonar Cube anschreiben.

Kurzes googel ergibt: https://community.sonarsource.com/t...-edition-to-sonarqube-developer-edition/11585

Vielleicht hab ich ja Glück und Jemand kennt sich hier etwas aus. Recherchiere/frage natürlich auch an anderen Stellen...

Das ist klar

Gruß,
Martin

 

[Zrebna]

Es gibt hierdrauf zwei Antworten:

1. Aus dem wissenschaftlichen Kontext: Du musst zwingend Anforderungen zunächst definieren, anschließend benötigst du eine Bewertungsstrategie von verschiedenen Ausprägungen. Danach kannst du sagen "Dies und das ist richtig". Alles andere ist in meinen Augen nicht wissenschaftlich und daher falsch.

Ich merke gerade gerade, dass Abschlussarbeit sich auch auf eine Ausbildun beziehen kann. In diesem Fall gilt ähnliches. Du benötigst eine eigene Entscheidung. Diese Entscheidung kannst du nur auf vorhandenen Informationen treffen. Oft wird hier genommen: Wie lange brauche ich, bis sich der Einsatz bezahlt gemacht hat. Make or Buy Entscheidung oder ähnliches.

2. Hier im Forum: Wir wissen nicht, was du berauchst. Offensichtlich unterscheiden sich die Editionen in den Sprachen, die sie unterstützen. Und ein paar sekundären Features wie bessere Darstellung von mehreren Branches und Pullrequest. Diese haben wir schon immer (Unternehmen mit 150 Personen und 4000 Personen ) mit der Community Edition gemacht.

Aber daraus kannst du keine Schlüsse auf deine Anforderungen schließen. Die kennen wir nicht. Eventuell programmiert ihr in Cobol ...

Die ist kostenlos. Wir haben definitiv mehr als 120 k LoC gehabt.


Wir haben diese immer benutzt.


Das musst du deinen Anwalt fragen. Aus meinem Jura-Studium: Kommerziell handelt jemand mit Gewinnabsicht. Solange du also deine Abschlussarbeit nicht massenweise verkaufst mit Gewinnabsicht, dann sollte es in den privaten Bereich fallen.


Wenn ihr die on premise Version nutzt nicht. Es gibt auch eine Cloud Variante.

Ich empfehle hier wirklich mal es auszuprobieren. Die meisten Fragen gerade solche sind dann klar. Wenn du ein System aufsetzt ohne INet Zugang, wirst du feststellen, wie gut es klappt.


Keine Ahnung. Hier müsste man den Support von Sonar Cube anschreiben.

Kurzes googel ergibt: https://community.sonarsource.com/t...-edition-to-sonarqube-developer-edition/11585


Das ist klar

Gruß,
Martin

Ok, thanks schon mal.

Dachte ansonsten, dass hier bereits klar geworden ist, dass wir in Java programmieren (ok, hätte sein können, dass man noch mehrere Sprachen verwendet).
Rquirements sind unspektakulär: Code-Smell-Hints und test-Abdeckungs-Metriken.

Habe auch im der SonarCommunity nachgefragt.
Sieht so aus, dass wir es erstmal mit der CommunityEdition versuchen.

Offtopic:
Hier wurde indirekt das Buch 'Clean Code' von Robert C. Martin empfohlen, einfach um seine eigene Codequalität nach vorne zu bringen. Wie wertvoll haltet ihr das Durcharbeiten der Inhalte (also wirklich damit arbeiten - keine "Wohlfühl-Lektüre") in so einem Klassiker in Zeiten von lokalen Tools wie SonarLint. Habe beides erst seit kurzem:
Von SonarLint bin ich bzgl. "Lernmöglichkeiten" begeistert - code-smell-hints mit umfangreichen Beschreibungen und Begründungen.

Bei dem Buch bin ich erst ganz zu Beginn und kann über den "Lern-Wert" noch nichts sagen.

Mich interessiert einfach, ob ihr denkt, dass solche Bücher Heute ehrlicherweise und überbetont stark ausgedrückt Richtung "Zeitverschwendung" gehen (auch wenn seiner Zeit sehr wertvoll), weil es eben so Tools wie SonarLint gibt, oder ob sie weiterhin für den eigenen Progress als Entwickler Wert haben und dieser Wert nicht durch die Verwendung von Tools wie SonarLint reduziert wird?

Lg
Zrebna

 

[Marinek]

Code-Smell-Hints und test-Abdeckungs-Metriken.

Dann brauche ich kein SonarCube dafür. Kann jede IDE + Plugin.

Mich interessiert einfach, ob ihr denkt, dass solche Bücher Heute ehrlicherweise und überbetont stark ausgedrückt Richtung "Zeitverschwendung" gehen (auch wenn seiner Zeit sehr wertvoll), weil es eben so Tools wie SonarLint gibt, oder ob sie weiterhin für den eigenen Progress als Entwickler Wert haben und dieser Wert nicht durch die Verwendung von Tools wie SonarLint reduziert wird?

Wenn man in diesem Thread ganz deutlich merkt ist, dass Bücher so mal gar keine Zeitverschwendung sind. Statische Code Analyse basisert auf etablierten Prinzipien. Einige dieser Prinzipien werden in dem Buch beschrieben. Das ist aber nur ein Sub-Set und von da aus geht es natürlich weiter.

Außerdem machen diese "Regeln" nicht immer Sinn. Und wenn ich diese in den Projekten enforcen würde, dann würde das Projekt stehen bleiben.

Das Thema ist mega komplex und ein guter Start ist dieses Buch. Lese es einfach zu Ende. Wenn hier nun jemand sagt: Zeitverschwendung - Dann legst du das weg und ja.. Irgendwie hast du nix gewonnen.