Automatisiertes Testen von größeren und komplexen Prozessen

[KonradN]

Also generell ist es so, dass man Regeln nicht blind befolgen. Das wäre das Niveau eines Anfängers. Man macht, was der Senior / Lehrer / Professor sagt aber man versteht nicht, was da abgeht.

Es gibt zu Regeln immer Erläuterungen, die weiter helfen, aber das bietet noch keine wirkliche Tiefe was das Verständnis angeht.

Für ein tieferes Verständnis kommt man meiner Meinung nach um gewisse Theorie nicht herum. Und da kommt man oft genug auf SOLID zurück und da führt dann kein Weg um Uncle Bob (Robert C Martin) herum. Ob man nun seine Bücher liest oder seine "Vorlesungen" genießt, das ist dann erst einmal egal.

Und auch ganz wichtig: Mit den Regeln bei SonarLint / SonarCube / ... habt Ihr nur einen kleinen Buchteil abgedeckt. Zur erfolgreichen Software Entwicklung gehört deutlich mehr. Das fängt beim Vorgehen an (agile Methoden sind derzeit, was wohl üblich ist) und geht über das Testing (incl. dem Vorgehen dabei, also TDD!)

Das muss man aus meiner Sicht einheitlich sehen. Das sind alles wichtige Pfeiler der Software Entwicklung und es nützt Dir nichts, wenn Du einen Pfeiler gut und stabil hast - das Haus wird zusammen brechen ohne die Anderen!

Uncle Bob deckt da sehr viel ab. Wenn Du die Learning Platform von Oreily mal ein paar Monate beziehen kannst (im Quartal um 100€ pro Person - sollte für eine Firma doch ok sein!), dann schau Dir Uncle Bob da an. Da hat er die diversen Themengebiete sehr gut abgedeckt und spricht über Clean Code, SOLID, TDD, legacy Code, ....
Aber er ist da nicht der Einzige - es gibt viele Autoren mit Themen in diesem Gebiet.

Das ist wichtig - ebenso der intensive Austausch mit anderen Entwicklern.

Ein guter Weg, da heran zu gehen: clean-code-developer.de - da ist es Stufenweise aufgebaut und enthält eigentlich alle Themen.

 

[Zrebna]

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

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.

Das stimmt -> Hints mit z.B. SonarLint und Metriken mit JaCoCo

aber langfristig wollen wir eh SonarQube nutzen und es macht für mich Sinn schon mal zu untersuchen, was es sonst noch so kann, um z.B. zum Ende hin Empfehlungen geben zu können, oder ähnliches.

Diesen Satz verstehe ich nicht:
"Wenn hier nun jemand sagt: Zeitverschwendung - Dann legst du das weg und ja.. Irgendwie hast du nix gewonnen."

Wie meinst du das?
Also wäre es Zeitverschwendung und ich lege es weg, dann hab ich schon was gewonnen, und zwar Zeit.
Ist es keine Zeitverschwendung und ich lege es weg, dann habe ich "Lern-Value" verloren.
Daher ja die Eingangs-Frage...

Also finde den Input zur Frage weiter oben gut, nur dieser Satz hat mich verwirrt^^

Fand übrigens den Input von chatGPT4 nicht schlecht diesbzgl.:
ChatGPT4 ist trotz Tools wie SonarLint in diesem Zusammenhang ein "Fan" von guten Klassikern wie dem Buch "Clean Code", weil gerad das durchackern durch gute Bücher das tiefergehende Verständnis für bestimmte Aspekte entwickelt.

Intuitiv stimme ich hier zu.

 

[Zrebna]

Also generell ist es so, dass man Regeln nicht blind befolgen. Das wäre das Niveau eines Anfängers. Man macht, was der Senior / Lehrer / Professor sagt aber man versteht nicht, was da abgeht.

Es gibt zu Regeln immer Erläuterungen, die weiter helfen, aber das bietet noch keine wirkliche Tiefe was das Verständnis angeht.

Für ein tieferes Verständnis kommt man meiner Meinung nach um gewisse Theorie nicht herum. Und da kommt man oft genug auf SOLID zurück und da führt dann kein Weg um Uncle Bob (Robert C Martin) herum. Ob man nun seine Bücher liest oder seine "Vorlesungen" genießt, das ist dann erst einmal egal.

Klingt gut! Danke für den Input^^

Und auch ganz wichtig: Mit den Regeln bei SonarLint / SonarCube / ... habt Ihr nur einen kleinen Buchteil abgedeckt. Zur erfolgreichen Software Entwicklung gehört deutlich mehr. Das fängt beim Vorgehen an (agile Methoden sind derzeit, was wohl üblich ist) und geht über das Testing (incl. dem Vorgehen dabei, also TDD!)

Das muss man aus meiner Sicht einheitlich sehen. Das sind alles wichtige Pfeiler der Software Entwicklung und es nützt Dir nichts, wenn Du einen Pfeiler gut und stabil hast - das Haus wird zusammen brechen ohne die Anderen!

Uncle Bob deckt da sehr viel ab. Wenn Du die Learning Platform von Oreily mal ein paar Monate beziehen kannst (im Quartal um 100€ pro Person - sollte für eine Firma doch ok sein!), dann schau Dir Uncle Bob da an. Da hat er die diversen Themengebiete sehr gut abgedeckt und spricht über Clean Code, SOLID, TDD, legacy Code, ....
Aber er ist da nicht der Einzige - es gibt viele Autoren mit Themen in diesem Gebiet.

Das ist wichtig - ebenso der intensive Austausch mit anderen Entwicklern.

Ein guter Weg, da heran zu gehen: clean-code-developer.de - da ist es Stufenweise aufgebaut und enthält eigentlich alle Themen.

Stimme mit allem überein. QS ist ein weites Thema, da sind auf jeden Fall auch Entwickler-Workflows mit enthalten, sowie "Clean Code"-Practices. Ich cover diese Punkt auch in meiner Arbeit. Jedoch habe ich auch ein Kapitel, bei dem halt dann schon prototypisch was implementiert werden muss, um zu zeigen ,dass mit bestimmten Tests/Vorgehen ausgewählte Fehler, die meine Schmerzpunkt-Analyse ergeben hat, vorab entdeckt worden wären, oder auch nicht. Jedoch ist das ein kleiner Teil der Arbeit. Der größere Teil der Arbeit ist dann abstrakt, theoretisch und da versuche ich schon recht viel anzusprechen, was unter QS fällt - auch wenn das wirklich ein rießen Thema ist, wie mir mittlerweile mehr und mehr klar wird.

 

[Zrebna]

Hallo!


Nochmal kurz zu statischen Code-Analyse als einer der Teile, den ich im kleinen "Praktischen Scope" meiner Abschlussarbeit zeigen will. Für den Scope der BA haben wir uns entschieden, dass ich mich da erstmal auf folgende zwei Aspekte beschränke und hierfür dann auch erstmal nur lokale Open-Source Tools nutze - also für die BA erstmal nicht SonarQubeServer:

1. Code-Smells-Hints - > hierfür nutze ich dann SonarLint.
2. Testabdeckungs-Metriken, und zwar am besten ein lokales Tool oder Plugin, das
a.) die Testabdeckung bzgl. Anweisungen
b. die Testabdeckung bzgl. Zweigabdeckung
ermitteln und anzeigen kann.

Kennt von Euch Jemand evtl. ein lokales open-srouce-Tool, das mir bei dem 2tem Aspekt helfen kann?

Lg
Zrebna

 

[Marinek]

Welche IDE benutzt ihr denn?

In der Regel reicht es aus den jeweiligen Market Place nach Code Coverage zu durchsuchen und dann hat man es.

 

[Zrebna]

Welche IDE benutzt ihr denn?

In der Regel reicht es aus den jeweiligen Market Place nach Code Coverage zu durchsuchen und dann hat man es.

Eclipse oder optional IntelliJ für Festangestellte, d.h. ich noch Eclipse.

Ich werde es mit diesem PlugIn versuchen:

EclEmma Java Code Coverage

EclEmma is a free Java code coverage tool for Eclipse, available under the Eclipse Public License. It brings code coverage analysis directly into the Eclipse workbench:

marketplace.eclipse.org

Das basiert wohl auf JaCoCo-Libraries. JaCoCo hat mein Professor als gute Möglichkeit an TestCoverage-Metriken heranzukommen genannt, daher sollte es schon passen.

 

[Zrebna]

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.

@LimDul
Nochmal diesen Post aufgegriffen:
Bei eurer "großen" automatisierten Testausführung, die dann 1x Nachts durchgeführt wird, wird da auch nach Testfällen im folgendem Sinne priorisiert?
-> Angenommen ihr habt einen Test A, dessen Ausführung sehr schnell geht und einen Test B, dessen Ausführung lange dauert.
Nun ist es so, dass wenn Test A nicht erfolgreich durchläuft (also es da Probleme gibt), dann hat das negative Auswirkungen für Test B.

Einfaches Beispiel wäre:
Test A testet, ob eine erfolgreiche Datenbankverbindung aufgebaut werden kann und geht schnell.
Test B testet einen Anwendungsfall bei euch, dessen Funktionalitäten Zugriff auf die Datenbank benötigen. Hier dauert die Testausführung lange.

Stellt ihr es da so ein, dass Test A immer vor Test B ausgeführt wird, oder achtet ihr auch solche Aspekte nicht?