Programmierstil beim Mocken

Avalon

Bekanntes Mitglied
Hallo, wenn man mockt, erstellt man eine Testklasse in der alle Methoden der Ursprungsklasse gemockt werden, oder erstellt man für jede Methode eine separate Testklasse? Letzteres könnte unübersichtlich werden. Oder? Wie ist den da die Best Practice?
 
Beste Antwort
Mal ein Beispiel von einem Programm von mir

Java:
    private final ZutatenRepository zutatenRepository = Mockito.mock(ZutatenRepository.class);

    private final ZutatenService service = new ZutatenService(zutatenRepository);

    private final List<Zutat> zutatenList = new ArrayList<>();

    @Test
    public void testFindeZutat_Name() {
        Mockito.when(zutatenRepository.findAll()).thenReturn(zutatenList);
        Zutat zutat1 = new Zutat();
        zutat1.setName("Test");
        Zutat zutat2 = new Zutat();
        zutat2.setName("Sonstiges");
        zutatenList.add(zutat1);
        zutatenList.add(zutat2);

        Optional<Zutat> zutat = service.findeZutat("test");

        assertThat(zutat.isPresent(), is(true))...
Hab ich, Testklasse muss ich trotzdem erstellen. Die werden dann mit den Annotationen von Mockito angereichert. Aktuell erstelle ich im Ordner src/test/java (Eclipse) eine Testklasse mit allen Methoden drin. So sieht das dann aus.
[CODE lang="java" title="Beispiel"]package com.example.demo.service;

import static org.mockito.Mockito.when;

import java.sql.Date;
import java.util.Optional;

import org.junit.Assert;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.example.demo.entity.Patient;
import com.example.demo.repository.IPatientRepository;



class PatientServiceImplTest {

Logger logger = LoggerFactory.getLogger(PatientServiceImplTest.class);

@InjectMocks
PatientServiceImpl patientService;

@Mock
IPatientRepository patientRepository;

@BeforeEach
void setUp() throws Exception {
MockitoAnnotations.initMocks(this);
}

@Test
void testCreatePatient() {
Patient patient = new Patient();
long id = 1;
patient.setId(id);
patient.setNachname("Test");
patient.setVorname("Tester");
when(patientRepository.existsById(id)).thenReturn(true);
logger.info(patient.getNachname());
}

@Test
void testGetPatientByID() {
Patient patient = new Patient();
long millis = 1556175797428L;
Date date = new Date(millis);
Assert.assertEquals(millis, date.getTime());
long id = 2;
patient.setId(id);
patient.setGeburtsdatum(date);
patient.setNachname("Test");
patient.setVorname("Tester");
logger.info(patient.toString());
when(patientRepository.findById(id)).thenReturn(Optional.of(patient));
}
}
[/CODE]
 
"Das sind keine Test, was du da schreibst." Sind es nicht? Ich habe eine RESTful API geschrieben (MVC, Spring-Boot, Spring, Swagger, Actuator, Prometheus, Mapping, Paging, Java Doc, WebClient... alles was eben so dazu gehört). Einiges fehlt noch und jetzt bin ich grad am Mocken, weil mein Chef das will. RESTful Api läuft, Mocken auch. Aber bevor ich jetzt alle Methoden durchmocke, wollte ich wissen, wie man das im Kontext der Lesbarkeit am Besten umsetzt. So wie in meiner Eingangsfrage beschrieben. Ich will nicht alles umbauen müssen, wenn ich fertig bin.
 
Zuletzt bearbeitet:
"Das sind keine Test, was du da schreibst." Sind es nicht?
Nein, die Tests machen einfach nur "irgendwas" getestet wird dabei allerdings nicht wirklich was.

Um das mal eben durchzugehen an der einen Methode:

Java:
@Test
void testCreatePatient() {
    Patient patient = new Patient();
    long id = 1;
    patient.setId(id);
    patient.setNachname("Test");
    patient.setVorname("Tester");
    when(patientRepository.existsById(id)).thenReturn(true);
    logger.info(patient.getNachname());
}

Zeile 3-7 legst du einfach nur ein Objekt an.
Zeile 8 sagst du: "falls auf meinen gemockten patientRepository existsById aufgerufen wird, wird true zurück gegeben".
Und in Zeile 9 wird dann der Nachname ausgegeben.

Das einzige, was damit implizit getestet werden würde, ist das keine Exception geworfen wird. Irgendeine Funktionalität wird da aber nicht getestet – in einem Test musst du immer erst irgendwas machen, und dann auch überprüfen (mit Assertions, nicht mit Log-Ausgaben), ob das korrekt funktioniert hat, das fehlt hier.



Mocken macht man ja nur, damit man Funktionalität, die man nicht testen will, "simulieren" kann – ob man das braucht und wie man das sinnvoll nutzt, fängt sehr davon ab, was man testen will.

Fang bei Tests immer erst an, in normalen Worten zu beschreiben, was du eigentlich testen willst – noch bevor du die erste Zeile Code dafür schreibst. Und wenn du das sinnvoll formuliert hast, kannst du es in Code übersetzen.
 
Fang bei Tests immer erst an, in normalen Worten zu beschreiben, was du eigentlich testen willst – noch bevor du die erste Zeile Code dafür schreibst. Und wenn du das sinnvoll formuliert hast, kannst du es in Code übersetzen.
So sehe ich das eigentlich auch. Erst der Test und dann den Code daraus ableiten. Aber Chefchen hat mich gezwungen andersherum anzufangen, ich soll jetzt anfangen Dinge "wegzumocken". Das obige zitierte Beispiel ist aus einem recht gut bewertetem Tutorial und nur zum probieren. Entscheidend ist aber diese hier

Java:
@Test
    void testGetPatientByID() {
        Patient patient = new Patient();
        long millis = 1556175797428L;
        Date date = new Date(millis);
        Assert.assertEquals(millis, date.getTime());
        long id = 2;
        patient.setId(id);
        patient.setGeburtsdatum(date);
        patient.setNachname("Test");
        patient.setVorname("Tester");
        logger.info(patient.toString());
        when(patientRepository.findById(id)).thenReturn(Optional.of(patient));
    }

Die Sinnhaftigkeit erschließt sich mir auch nicht so richtig. Jedenfalls tut die Methode was sie soll. Den Test brauch ich dazu eigentlich nicht wirklich. Da gebe ich Dir recht. Was die logger Ausgaben betrifft, die sind nur ein zusätzliche Kontrolle und Altlast. Aber wie mach ich das jetzt am Besten mit der Lesbarkeit?
 
So sehe ich das eigentlich auch. Erst der Test und dann den Code daraus ableiten. Aber Chefchen hat mich gezwungen andersherum anzufangen, ich soll jetzt anfangen Dinge "wegzumocken". Das obige zitierte Beispiel ist aus einem recht gut bewertetem Tutorial und nur zum probieren. Entscheidend ist aber diese hier
Meine Aussage bezog sich nicht auf "Test First", sondern rein auf die Tests 🙂 Um Tests zu schreiben, erst den Testfall ohne Code beschreiben, dann den Testfall mit Code schreiben 🙂

Die Sinnhaftigkeit erschließt sich mir auch nicht so richtig.
Naja, die Sinnhaftigkeit ist da ja auch nicht vorhanden 😀 Beschreib mal in normalen Worten, was du dort testen willst.

Jedenfalls tut die Methode was sie soll. Den Test brauch ich dazu eigentlich nicht wirklich.
Durch den Test kannst du sicherstellen, dass deine Methode tut, was sie soll 🙂

Dann, wenn andere an dem Code arbeiten, wenn der Code refactored wird etc, hast du mit dem Tests doe Sicherheit, dass nichts dabei kaputt geht. Ohne den Test müsstest du es jedes Mal manuell testen.
 
Wie gesagt, beschreib erst mal was du testen willst.
Danach kannst du in Tutorials und Co schauen. So rum scheint es für dich nicht sinnvoll zu sein.

Du willst - zumindest den Namen nach - unter anderem die Methode getPatientById testen.

Was genau willst du testen? In der Regel heißt ein Test:

* Rufe die Methode auf
* Überpüfe, ob das Ergebnis der Methode, das ist, was du erwartet hast.

Dieser Schritt ist kommt bevor man anfängt zu mocken & Co uns ist das essientielle beim Testen.

Das Mocken ist nur notewendig, wenn die Aufgerufene Methode Resourcen braucht, die (wie z.B. eine DB) nicht zur Verfügung stehen.
 
Von welchem Objekt/Klasse? Unter welchen Bedingungen?

Und in dem Fall darfst du natürlich die Methode findById nicht mocken. Sonst testet du Unfug. Und dann sollte deine Test-Methode auch testFindById heißen.
 
Ich mocke die Methode nicht, aber das Repository. Die Methode findById wird in der TestKlasse testGetPatientByID() aufgerufen. Die Zeile
Java:
when(patientRepository.findById(id)).thenReturn(Optional.of(patient));
zeigt doch eigentlich was ich will. Wenn der zuvor angelegte Patient gefunden hat, soll er zurückgeben werden und es kommt kein Fehler. Oder verstehe ich da was falsch?
 
Ich mocke die Methode nicht, aber das Repository. Die Methode findById wird in der TestKlasse testGetPatientByID() aufgerufen. Die Zeile
Java:
when(patientRepository.findById(id)).thenReturn(Optional.of(patient));
zeigt doch eigentlich was ich will. Wenn der zuvor angelegte Patient gefunden hat, soll er zurückgeben werden und es kommt kein Fehler. Oder verstehe ich da was falsch?
Ja. Vollkommen. Du mockst damit die Methode. Du sagst Mockito "Wenn die Methode findById mit "Id" aufgerufen wird, dann gib das Optional von patient zurück.

Die Methode wird zum einen dadurch nicht aufgerufen, zum anderen testet du sie nicht, sondern machst eine Dummy-Implementierung dieser Methode.
 
Mal ein Beispiel von einem Programm von mir

Java:
    private final ZutatenRepository zutatenRepository = Mockito.mock(ZutatenRepository.class);

    private final ZutatenService service = new ZutatenService(zutatenRepository);

    private final List<Zutat> zutatenList = new ArrayList<>();

    @Test
    public void testFindeZutat_Name() {
        Mockito.when(zutatenRepository.findAll()).thenReturn(zutatenList);
        Zutat zutat1 = new Zutat();
        zutat1.setName("Test");
        Zutat zutat2 = new Zutat();
        zutat2.setName("Sonstiges");
        zutatenList.add(zutat1);
        zutatenList.add(zutat2);

        Optional<Zutat> zutat = service.findeZutat("test");

        assertThat(zutat.isPresent(), is(true));
        assertThat(zutat.get(), is(zutat1));
    }

Ich will die Methode findeZutat vom Service testen. Der Service braucht ein Repository für den Zugriff auf die Datenbank. Da ich im Test aber keine Datenbank erzeugen will, mocke ich das Repository und sage "Wenn die Methode findAll vom Repository aufegerufen wird, gib die zutatenList zurück". Ich simuliere also, als wäre in der DB genau die Elemnete der Liste gespeichert. Und dann kann ich die Methode des Service testen in dem ich sie aufrufe mit findeZutat("test") und danach mit einem assert überprüfen, dass aus der aus der gemockten DB gelesenen Liste genau das richtige Element rausgesucht hat.

Nachtrag:
Hier sieht man auch schön die Dreiteilung die man in der Regel in den meisten Unit-Tests hat.

* Testdaten erzeugen
* Zu testende Methode aufrufen
* Ergebnis überprüfen
 
Beste Antwort
Das Überprüfen, hat der im Tutorial nicht gemacht. Vergessen oder Absicht?
Da hat der Zuschauer nicht aufgepasst. Sein letzter Satz war "We can now test ... let's do that in the following video".

Stumpfes abtippen von Code aus Tutorials, solange man wie in dem Fall bei dir gar nicht weiß, was man da eigentlich tut, ist halt nicht sinnvoll. Erst sollte man verstehen, was man eigentlich machen will, bevor man weitergeht. Und wenn es ums mocken & Co geht sollte man zumindest mal verstehen, wie ein Unit Test funktioniert.
 
Da hat der Zuschauer nicht aufgepasst.
Sehr gut. 🙂 Ist halt meine Art. Erstmal gucken wie andere das machen. Dann nachtippen. Ansehen, versuchen zu verstehen und wenn Fragen sind, diese im Forum stellen. Ein Gesamtbild und Verständnis ergibt sich in der Regel später aus einem Mix von Allem. Ist eben ein Lernporozess. Geduldige Mitstreiter wie Euch, vorausgesetzt. Meinen Dank, habt ihr jedenfalls.
 
Mein Tipp wäre erst mal mit simplen Unit-Tests von einfachen Klassen ohne weitere Abhängigkeiten anzufangen - dann ergibt sich wenn man weitermacht der Bedarf fürs Mocken von ganz alleine und man weiß dann auch direkt, warum das braucht 🙂
 
Mein Tipp wäre erst mal mit simplen Unit-Tests von einfachen Klassen ohne weitere Abhängigkeiten anzufangen - dann ergibt sich wenn man weitermacht der Bedarf fürs Mocken von ganz alleine und man weiß dann auch direkt, warum das braucht 🙂
Keine Zeit. :-D Wenn Chef sagt Mocken, dann Mocken. Die A-Karte liegt bei mir. :-D simple Unit Tests wären ja schön. Sind sie ja auch. Aber da ist der Wunsch der Vater des Gedanken. Aber ihr habt mir in jedem Fall schon weiter geholfen. Nochmals Danke.
 
Ich bin in einer Umschulung. Habe Nachsicht. Vor 4 Monaten hab ich meine erstes Hello World Programm geschrieben, bin jetzt im Praktikum und bekomme gleich die volle Dröhnung. Meine Aufgabe ist es, sein 20 jahre altes Modulsystem im Onlinehandel auf Microservices und so ein Zeug umzustellen. Wenn Chef sagt, mocken, dann Mocken. Das Schlimme ist, ich weiß das er sich was dabei denkt. Und mein Chef hilft mir nicht. Wahrscheinlich will er das später hören... "wenn notwendig". Deswegen finde ich das hier ja so reizend. Das soll ich bestimmt rausfinden. Er vertritt auch die Meinung, daß alles im Internet steht. So verbringe ich nun Tag für Tag, mir Massen an Halbwahrheiten zusammenzusuchen, durch andere zu ergänzen, zu filtern, bis dann irgendwann mal was ganzes halbwegs brauchbares rauskommt. Nicht einfach.
 
Meine Aufgabe ist es, sein 20 jahre altes Modulsystem im Onlinehandel auf Microservices und so ein Zeug umzustellen.
4 Monate nach "Hello World" einen existierenden Monolithen auf Microservices umstellen... denk Dir nix, wenns nicht klappt. Wenn die Anwendung eine gewisse, na sagen wir mal, Komplexität erreicht hat, zählt das zu den schwierigsten Aufgaben aus dem Bereich der Microservices (vgl. Fowler, Wolff, Tilkov).

Und mein Chef hilft mir nicht.
Der wird schon wissen, warum 🙂

Aber wir sind hier ja bei Unit-Tests. Dir muss klar werden, was ein Unit-Test macht, und wofür Du Mocks brauchst.
 
Ich bin in einer Umschulung. Habe Nachsicht. Vor 4 Monaten hab ich meine erstes Hello World Programm geschrieben, bin jetzt im Praktikum und bekomme gleich die volle Dröhnung. Meine Aufgabe ist es, sein 20 jahre altes Modulsystem im Onlinehandel auf Microservices und so ein Zeug umzustellen. Wenn Chef sagt, mocken, dann Mocken. Das Schlimme ist, ich weiß das er sich was dabei denkt. Und mein Chef hilft mir nicht. Wahrscheinlich will er das später hören... "wenn notwendig". Deswegen finde ich das hier ja so reizend. Das soll ich bestimmt rausfinden. Er vertritt auch die Meinung, daß alles im Internet steht. So verbringe ich nun Tag für Tag, mir Massen an Halbwahrheiten zusammenzusuchen, durch andere zu ergänzen, zu filtern, bis dann irgendwann mal was ganzes halbwegs brauchbares rauskommt. Nicht einfach.
Hast Du denn eine vernünftige Lernmittel-Quelle? Ohne Werbung machen zu wollen:
- OReilly hat eine Learning Plattform. Kostet um 45€/Monat und bietet sehr viel an Bücher, Videos und auch viele Online Präsentationen. Kann man ja vielleicht einmal testen und ggf. den Chef belabern, einem das (temporär) zu bezahlen ... (Ehemals Safari Books Online)
- Packtpub.com hat eine Subscription für 10€/Monat aber halt deutlich eingeschränkter. Da hat man dann in erster Linie nur die Bücher und Videos dieses Verlages. Da hat man dann somit viele "Standardwerke" nicht, die man sich sonst rein ziehen würde/sollte ... Kann man natürlich auch testen ...

Das wäre dann meiner Meinung nach ein Weg, um sich weniger Halbwahrheiten zusammen suchen zu müssen und statt dessen ein Thema aufbereitet durchgehen kann.
 
Literatur wird mir auch nicht finanziert. Veraltet zu schnell. Deswegen Internet. Die Grundlagen (in Java) haben sie (Bildungsträger) mir versucht in den letzten vier Monaten beizubringen (sehr komprimiert), davor nur das üblich Gedöns (Pflichtenheft, BWL, UML usw.) und jetzt in der Praxis, sehe ich mich mit lauter Tools und Frameworks konfrontiert ("Tag des Erwachens"), die ich irgendwie zusammenschalten muss. Wie weiter oben schon beschrieben... Spring, Spring-Boot, Maven, Swagger, Actuator, Promtheus, Endpoints, RESTful API, Metrics, Eventhandling, Eventbus, Webclient, MVC, Mocking und da kommt ja noch Einiges (nichts davon bei den Grundlagen, wenigstens erwähnen hätten sie es können, moderne Softwareentwicklung). Bis vor 2 Monaten, hab ich noch nichts davon gehört. :-D Aber eins kann ich Euch sagen. Ich werde dafür verantwortlich sein, das Eure Daten mal in andere Hände fallen werden. Irgendwie scheint keine Zeit mehr für fundierte Ausbildung zu sein. Nur noch learning by doing. Zum Kotz...
 
Ernst gemeinter Rat: Beiß dich durch, bilde dich fort und sobald das Gefühl hast, einigermaßen Boden unter den Füßen zu haben und verstanden zu haben, was tu tust - such dir eine neue Firma.
 
woher stammt denn diese Aussage?
Chef. Kann ich aber nach meinen Recherchen der letzten Monate bestätigen. Was die Grundlagen betrifft, das Handwerkszeug, mag das zutreffen. Da ist Literatur erste Wahl. Aber was die Frameworks und ganzen Tools betrifft, die täglich überarbeitet werden, kann das nicht funktionieren. Gerade bei Spring und Spring Boot (mittlerweile alte Hasen) hab ich bemerkt, das da keiner schnell genug ist. Selbst Baeldung kommt mit einigen Sachen nicht hinterher. Code den sie diese Anfang diesen Jahres publiziert haben, wird jetzt nicht mehr unterstützt und als deprecated klassifiziert. Und bei denen denke ich, das sie am Ball sind.
 
Ernst gemeinter Rat: Beiß dich durch, bilde dich fort und sobald das Gefühl hast, einigermaßen Boden unter den Füßen zu haben und verstanden zu haben, was tu tust - such dir eine neue Firma.
:-D In den nächsten Wochen werde ich auf seine sehr, sehr, sehr große Kundendatenbank eines Onlinehandelportals losgelassen. Ohne Netz und doppelten Boden! :-D . Was bis jetzt lief, war alles nur Schnupperkurs. Ich denke, da wird mir dann schon jemand über die Schulter schauen. Alles andere wäre fahrlässig. Die Firma an sich ist schon super. Nur das man sich alles selber beibringen muss, ist ka...e
 
Literatur wird mir auch nicht finanziert. Veraltet zu schnell. Deswegen Internet. Die Grundlagen (in Java) haben sie (Bildungsträger) mir versucht in den letzten vier Monaten beizubringen (sehr komprimiert), davor nur das üblich Gedöns (Pflichtenheft, BWL, UML usw.) und jetzt in der Praxis, sehe ich mich mit lauter Tools und Frameworks konfrontiert ("Tag des Erwachens"), die ich irgendwie zusammenschalten muss. Wie weiter oben schon beschrieben... Spring, Spring-Boot, Maven, Swagger, Actuator, Promtheus, Endpoints, RESTful API, Metrics, Eventhandling, Eventbus, Webclient, MVC, Mocking und da kommt ja noch Einiges (nichts davon bei den Grundlagen, wenigstens erwähnen hätten sie es können, moderne Softwareentwicklung). Bis vor 2 Monaten, hab ich noch nichts davon gehört. :-D Aber eins kann ich Euch sagen. Ich werde dafür verantwortlich sein, das Eure Daten mal in andere Hände fallen werden. Irgendwie scheint keine Zeit mehr für fundierte Ausbildung zu sein. Nur noch learning by doing. Zum Kotz...
Also das klingt alles relativ dubios.

Du bist ein Junior Developer. Dieser benötigt selbstverständlich Weiterbildung und Führung. Du wirst - so ich Dich richtig verstanden habe - nicht von Deinem Chef geführt. (Chef bitte einfach als fachlich Vorgesetzten ansehen. Das kann auch ein erfahrener Kollege sein.... Aber jemand muss Dich an die Hand nehmen, Fehler erkennen, Korrekturen erläutern, ...)
==> Es fehlt also jemand, der als Ansprechpartner fungiert, der Fragen ausführlich beantworten kann und Zwischenergebnisse abfragt und prüft!

Weiterbildung: Es ist toll, dass Du da auf irgendwelche Fortbildungen kommst. Die bringen aber nur begrenzt etwas. Und dann dieses Stückwerk aus dem Internet: Ganz mangelhaft. Die einzelnen Seiten mögen sogar gut sein, aber dann wird lediglich auf einen Punkt Wert gelegt und andere werden teilweise komplett ignoriert. Wichtige Dinge werden weggelassen um es kurz und einfach zu halten. Also ich sehe da ein riesiges Problem.

Und bei dem, was ich vorgestellt habe, bekommst Du nicht ein Buch oder so. Du hast Zugriff auf extrem viele Bücher. Also du kannst alte Schinken lesen, weil es einfach Standard Werke sind. Oder du liest das neue Buch von einem Autor. Ich bin überzeugt, dass das eine Firma einem stellen sollte. (Ich arbeite bei einem Konzern, wo alle Mitarbeiter entsprechenden Zugang zu Lerninhalten haben und da sind Online Schulungen ebenso enthalten wie Zugriff auf Bücher und so... Allerding in technisch nicht optimalem Weg, was mich etwas stört, so dass ich mir die genannten Angebote selbst von meinem Geld gönne. (Packt habe ich generell, Oreilly nur hin und wieder für einen Monat, wenn ich weiss, dass ich auch die Zeit habe, es richtig zu nutzen.)

Aber klar: Man muss damit leben, was der Chef einem gibt. Aber da wäre dann ggf. die Überlegung: Selbst Geld in die Hand nehmen, um besser voran zu kommen? Und mit dem Chef etwas reden. Ansonsten arbeite an Dir. Versuch möglichst viel zu lernen. Und dann wechselst du den Chef. Angebote sollte es genug geben. Aber natürlich gut überlegen: Versuch erst einmal so viel es geht zu lernen um dann eine möglichst gute Position für einen Wechsel zu haben...

Das alles hilft Dir aber jetzt bei der konkreten Problematik nicht wirklich weiter. Aber es sind vielleicht generell hilfreiche Dinge ...
 
Chef. Kann ich aber nach meinen Recherchen der letzten Monate bestätigen. Was die Grundlagen betrifft, das Handwerkszeug, mag das zutreffen. Da ist Literatur erste Wahl. Aber was die Frameworks und ganzen Tools betrifft, die täglich überarbeitet werden, kann das nicht funktionieren. Gerade bei Spring und Spring Boot (mittlerweile alte Hasen) hab ich bemerkt, das da keiner schnell genug ist. Selbst Baeldung kommt mit einigen Sachen nicht hinterher. Code den sie diese Anfang diesen Jahres publiziert haben, wird jetzt nicht mehr unterstützt und als deprecated klassifiziert. Und bei denen denke ich, das sie am Ball sind.
Vorneweg - das soll jetzt keine Kritik an dir sein.

Techniken ändern sich im Detail, aber Fundamente und Methoden bleiben gleich.

Wenn ich:
* weiß, wie Unit-Tests geschrieben werden, was da die typischen Probleme und Prinzipien sind
* weiß, wie Mockito funktioniert, wofür es da ist und wie man es im Prinzip einsetzt.

Dann kann ich solche Bruchstücken-Tutorials wie das was du erwähnst verwenden um zu lernen, wie ich diese beiden Prinzipien auf mein konkretes Spring Boot Problem anwende. Und dann ist es auch egal, wenn sich das nicht auf die Version bezieht, die ich verwende. Die sind ähnlich genug, dass man die Transferleistung erbringen kann.

Dir fehlt - soweit man das Beurteilen kann anhand des Threads - einiges an Grundlagen bzw. Fundament. Was bei einer Umschulung von 4 Monaten jetzt auch nicht verwunderlich ist - es spricht eher für dich, dass du dich da überhaupt etwas zurechtfindest.

Du wirst die Detailprobleme vielleicht mit viel Mühe, Googeln und dem Forum hier gelöst bekommen. Ob du aber immer verstehst, was genau du da tust, hab ich meine Zweifel. Und du wirst deutlich mehr Mühe haben, als wenn du jemanden an der Seite hätte, der dich unterstützt, der Zugang zu entsprechenden Materialen und Co gibt. Diese Unterstützung scheinst du in der Firma nicht zu haben, so dass zum einen das was da rauskommt von zumindest fragwürdiger Qualität ist und zum anderen für dich leicht in ungesunden Stress ausarten kann - weil du es nicht schaffst das zu liefern was (unrealisitischerweise) gefordert ist.

Deswegen der ernstgemeinte Rat, dir ein Exit-Szenario auszudenken mit einem Firmen-Wechsel.
 
Chef. Kann ich aber nach meinen Recherchen der letzten Monate bestätigen. Was die Grundlagen betrifft, das Handwerkszeug, mag das zutreffen. Da ist Literatur erste Wahl. Aber was die Frameworks und ganzen Tools betrifft, die täglich überarbeitet werden, kann das nicht funktionieren. Gerade bei Spring und Spring Boot (mittlerweile alte Hasen) hab ich bemerkt, das da keiner schnell genug ist. Selbst Baeldung kommt mit einigen Sachen nicht hinterher. Code den sie diese Anfang diesen Jahres publiziert haben, wird jetzt nicht mehr unterstützt und als deprecated klassifiziert. Und bei denen denke ich, das sie am Ball sind.
Dann schau Dir doch einmal die Plattform von Oreilly an. Da ist dann u.a. auch Josh Long aktiv und bietet diese Online Sessions an. (Er gehört mit direkt zum Spring Team ... also up to date. Bei den Sessions kann man auch Fragen stellen ...)

Und Dir ist hoffentlich auch klar: Dir fehlt es nicht an irgendwelchen Spezialitäten-Wissen. Dir fehlen Grundlagen! Existenzielle Grundlagen!
Das TDD Buch von Kent Beck wäre für Dich bestimmt hilfreich um bezüglich Unit Testing weiter zu kommen.

Oder So eine Online Session bezüglich JUnit 5 / Mockito 3 - Auf Oreily hat z.B. Ken Kousen da einiges angeboten...

Aber das aufzuzählen wird wohl kaum etwas bringen. Du hast Dich scheinbar entschieden und bist überzeugt von Deinem Weg. Daher wünsche ich Dir da viel Erfolg.
 
Oh Gott. Das war jetz viel. Aber gut.

Auszugsweise:


Du bist ein Junior Developer.
Knapp 50 Jahre alt, aber ja.

Dieser benötigt selbstverständlich Weiterbildung und Führung
Ja, nein. :-D
Es fehlt also jemand, der als Ansprechpartner fungiert, der Fragen ausführlich beantworten kann und Zwischenergebnisse abfragt und prüft!
Zwischenergebnisse werden abgefragt, für Fragen beantworten, fehlt meist die Zeit.
Weiterbildung: Es ist toll, dass Du da auf irgendwelche Fortbildungen kommst. Die bringen aber nur begrenzt etwas. Und dann dieses Stückwerk aus dem Internet: Ganz mangelhaft. Die einzelnen Seiten mögen sogar gut sein, aber dann wird lediglich auf einen Punkt Wert gelegt und andere werden teilweise komplett ignoriert. Wichtige Dinge werden weggelassen um es kurz und einfach zu halten. Also ich sehe da ein riesiges Problem.
Es handelt sich um eine Umschulung zum Fachinformatiker/Anwendungsentwicklung (Sorry ich muss grad lachen). Dauer 2 Jahre. In den zwei Jahren sollte man das lernen, wofür in der normalen Ausbildung 3,5 Jahre vorgesehen sind (da geht schon eher was).
Ich arbeite bei einem Konzern, wo alle Mitarbeiter entsprechenden Zugang zu Lerninhalten haben und da sind Online Schulungen ebenso enthalten wie Zugriff auf Bücher und so...
Wie geil ist das denn?
Selbst Geld in die Hand nehmen
Mir fehlen im Schnitt jeden Monat 200 Euro zum normalen Leben für mich und meine Familie. Bei 1500 für 3 Personen, bleibt nur das Inet als Informationsquelle. Vor 15 Jahren mit 4000 ging es besser :-D. Ich hab aus der Zeit noch ein Haufen C Bücher im Regal! :-D
Dir fehlt - soweit man das Beurteilen kann anhand des Threads - einiges an Grundlagen bzw. Fundament.
Gibt es von Fehlen eigentlich noch eine Steigerungsform? :-D Kann, was einem unbekannt ist, als es fehlen bezeichnet werden? Es fehlt ja alles erst jetzt, seitdem ich davon weiß. :-D Sehr philosophisch. Dieser verdammte Makel sollte eigentlich in der Ausbildung beseitigt werden. Du hast natürlich recht. Ich hab von allem was gehört, zu allem was gelesen, alles in Code umgesetzt, einen funktionierenden RESTfull Service mit fast allem Pipapo aufgesetzt, sagen kann ich auch was dazu, aber von Fachwissen kann man da nicht sprechen. Im Detail ist Eventhandling ist noch eine riesen Baustelle. Kapier ich nicht. Nur mal so nebenbei.
Ob du aber immer verstehst, was genau du da tust
Das können ja wohl nun wirklich die Wenigsten. Also ich meine, nicht was ich tue, sondern was sie selbst tun. :-D Aber auch da hast Du recht. Trotzdem, es wird, nicht zuletzt durch solche Konversationen hier, mit Euch, nicht weniger sondern mehr. Heute früh wusste ich weniger als jetzt. Dank Euch. Besser kanns nicht laufen.
Deswegen der ernstgemeinte Rat, dir ein Exit-Szenario auszudenken mit einem Firmen-Wechsel.
Problem ist, das ist ein Praktikumsplatz. Ohne Praktikum, keine IHK Abschlussprüfung. Wir sind 24 Leute in der Ausbildunsgtruppe (verteilt auf ganz Deutschland). Nur 3 haben einen Praktikumsplatz bekommen (alle anderen Absagen wegen Corona). Einer davon bin ich. Ich hab einen. Aber auch nur, weil es ein alter Bekannter ist, mit dem ich zusammen Informatik studiert habe. Und ja, ich bin nach zwei Semestern wegen Mathe rausgeflogen. :-D Das war aber im Pleistozän. Da wart ihr alle noch flüssig (ist jetzt mal eine Vermutung :-D, ein bisschen Spaß muss sein)
Schau ich mir an.
Du hast Dich scheinbar entschieden und bist überzeugt von Deinem Weg
An welcher Stelle hab ich das raushängen lassen. War dann ein Versehen. Ich bin alles andere als überzeugt. Aber die Umstände zwingen mich dazu weiterzumachen. Ein Zurück oder einen Richtungswechsel gibt es derzeit nicht. Und ganz nebenbei, macht es auch Spaß 10 Stunden vor dem Monitor zu hängen. Die letzten 2 Monate habe ich 15 Kilo abgenommen, weil ich vergessen habe zu essen. :-D
 
Problem ist, das ist ein Praktikumsplatz. Ohne Praktikum, keine IHK Abschlussprüfung. Wir sind 24 Leute in der Ausbildunsgtruppe (verteilt auf ganz Deutschland). Nur 3 haben einen Praktikumsplatz bekommen (alle anderen Absagen wegen Corona). Einer davon bin ich. Ich hab einen. Aber auch nur, weil es ein alter Bekannter ist, mit dem ich zusammen Informatik studiert habe. Und ja, ich bin nach zwei Semestern wegen Mathe rausgeflogen. :-D Das war aber im Pleistozän. Da wart ihr alle noch flüssig (ist jetzt mal eine Vermutung :-D, ein bisschen Spaß muss sein)
Deswegen hab ich es ja auch als Exit-Szenario bezeichnet 🙂 Zumindest die Option aktiv im Hinterkopf behalten und schauen was muss ich aufbauen um mir das zu ermöglichen. Das das in der aktuellen Lage nichts ist, was du jetzt kommenden Montag machen sollst, ist klar. Ich sehe halt zwei Pfade:

* Entweder die Unterstützung bessert sich, du bekommst sinnvollere Unterstützung und kannst absehen das es so bleibt => Alles gut
* Du merkst, dass du in eine gefährliche Spirale kommst, in dem Sinne das mehr von dir erwartet wird, als du realistisch leisten kannst und das sich in einem negativen Zyklus verstärkt.

Und für den zweiten Fall schadet es nicht, links und rechts zu schauen und zu schauen, wie man geschickt es schafft sich Grundlagen und breiteres Wissen anzueignen um nach Abschluss der Ausbildung die Karten selber in der Hand zu haben.
 
Ok, dann bist Du meine Altersklasse. Danke für die vielen Informationen zu Deiner Situation, ich kann Dich jetzt deutlich besser verstehen.

Und ja - die Ausbildung solltest Du dann auf jeden Fall durchziehen! Ich drücke Dir da die Daumen. Die meisten Ratschläge sind dann tatsächlich erst einmal für die Katz', da ich einfach von einer anderen Situation ausgegangen bin.

Dann bist Du auf jeden Fall hier im Forum richtig. Ich hoffe, dass Dir hier immer weiter geholfen werden kann, so dass Du Deine Ziele erreichen kannst.
 
woher stammt denn diese Aussage?
Chef. Kann ich aber nach meinen Recherchen der letzten Monate bestätigen. Was die Grundlagen betrifft, das Handwerkszeug, mag das zutreffen. Da ist Literatur erste Wahl. Aber was die Frameworks und ganzen Tools betrifft, die täglich überarbeitet werden, kann das nicht funktionieren. Gerade bei Spring und Spring Boot (mittlerweile alte Hasen) hab ich bemerkt, das da keiner schnell genug ist. Selbst Baeldung kommt mit einigen Sachen nicht hinterher. Code den sie diese Anfang diesen Jahres publiziert haben, wird jetzt nicht mehr unterstützt und als deprecated klassifiziert. Und bei denen denke ich, das sie am Ball sind.
 
Die gesunde Gesichtsfarbe kommt nicht von der Sonne - der Kaffee hat für den Teint gesorgt 🙂
Ich schmeiß mich grad wech vor lachen. :-D Zumal ich in Kannen rechne, nicht in Tassen. Als abschließenden Satz möchte ich noch loswerden, daß ich die Konversation mit Euch sehr genossen habe und Euch für die aufmunternden Worte von ganzem Herzen danke. Danke für Eure Geduld. Jetzt muss ich aber erstmal meine schon kleineren Wissenlücken mit JUnit Jupiter und Mocken schließen. Vielleicht esse ich auch ne Kleinigkeit. Zur Kanne Kaffee.
 
Dann bist Du auf jeden Fall hier im Forum richtig. Ich hoffe, dass Dir hier immer weiter geholfen werden kann, so dass Du Deine Ziele erreichen kannst.
Ich bin zwar kein Anfänger mehr, da ich nicht mehr da stehe, wo ich losgegangen bin, aber ihr seid viel weiter und darüber bin ich sehr froh. Auch menschlich ist das hier eine andere Hausnummer. In anderen Foren benehmen sich viele so, als ob sie als Softwareentwickler auf die Welt gekommen wären. Hier nicht. Welch ein Glück für mich. Danke.
 
Zuletzt bearbeitet:
Das ist ein Klischee, das nicht ganz von der Hand zu weisen ist: Programmierer = Mensch, der Kaffee in Code verwandelt.

Aber nochmal zum Thema: wenn Du 10 Std. vor dem Monitor sitzt, bist Du am Ende schneller, wenn Du langsam machst. Beim Unit-Test geht es ja gerade darum, die betreffende Einheit zu testen, daher sind Abhängigkeiten störend und werden ggf. durch Dummies ersetzt.

Übrigens hat @mrBrown hier zwei ausführliche Beispiele zum Thema TDD gepostet: https://www.java-forum.org/thema/test-driven-development-anhand-von-fizzbuzz.189510/ und https://www.java-forum.org/thema/tdd-beispiel-2-kuerzeste-pfade-in-graphen.189527/ Könnten evtl. ganz nützlich für Dich sein.
 
Ich würde hier den DDD-Ansatz nicht außer Acht lassen. Der Ensatz vom Mirkroservices ist meiner Meinung eng mit der Domänengetriebenen Entwicklung verbunden. Und ich schlage mal vor dir die "Pet-Clinik" anzusehen. Ein Beispiel, das du bei den "SpringTool Suite" mit angeboten bekommst, und eine vollständige Anwendung darstellt. Da hast du auch die Testfälle, die so sind wie sie hier schon erklärt wurden. Hilfe zu Mocken an sich, findest du auf der "mockito.com" Seite. Ich glaube das ist so richtig.

Ansonsten hat mir mein Prüfer vorgeworfen, wieso ich nicht UML genutzt habe. Das war eine gute Frage. Nutze es. Sowohl zur ananlyse des vorhandenen als auch zur Erstellung des neuen. Auf keinen Fall PAP, dann eher Struktogramme. Und dann eben auch sowohl statische als auch dynamische Diagramme.
 
Ich würde hier den DDD-Ansatz nicht außer Acht lassen.
Übrigens auch durch ein fast 20 Jahre altes Buch geprägt 🙂

Ansonsten hat mir mein Prüfer vorgeworfen, wieso ich nicht UML genutzt habe.
Persönliche Meinung (und zT Erfahrung): Diagramme sind ungemein hilfreich, auf syntaktisch korrekte UML-Diagramme würde ich aber nur selten achten, meist sind die den Aufwand nicht wert.
 

Zurück
Oben