Datenzeilen werden nicht gelöscht

[TM69]

Bezugnehmend auf: https://www.java-forum.org/thema/repository-wird-null-im-test.199617/
und den hier befindlichen Beiträgen.

Meine Test sieht jetzt wie folgt aus:

    @Test
    @Transactional
    void testUpdateUserWithValidData() throws ResourceNotFoundException, NullPointerException, DuplicateException {
        // create user
        String firstname = "firstname";
        String lastname = "lastname";
        String email = "email@email.com";
        String password = "password";
        
        User user = new User(
                firstname,                // password
                lastname,                 // lastname
                email,                     // email
                password                // password
                );

        User createdUser = userService.createUser(null, user);
        Optional<User> foundUser = userService.findUserById(createdUser.getId());
        
        assertTrue( foundUser.isPresent(), "testUpdateUserWithValidData(): User (" + user + ") not stored");

        // create updater
        String creator_firstname = "creator firstname";
        String creator_lastname = "creator lastname";
        String creator_email = "creator_email@email.com";
        String creator_password = "creator password";
        
        User creator = new User(
                creator_firstname,                // password
                creator_lastname,                 // lastname
                creator_email,                     // email
                creator_password                // password
                );

        User creatorUser = userService.createUser(null, creator);
        Optional<User> foundCreator = userService.findUserById(creatorUser.getId());
        
        assertTrue( foundCreator.isPresent(), "testUpdateUserWithValidData(): Creator (" + creator + ") not stored");
        
        // update user
        String updatedFirstname = "updated firstname";
        String updatedLastname = "updated lastname";
        String updatedEmail = "new_email@email.com";
        String updatedPassword = "new password";
        
        User updatedUserData = new User(
                updatedFirstname,                // password
                updatedLastname,                 // lastname
                updatedEmail,                     // email
                updatedPassword                    // password
        );
        
        User updatedUser = userService.updateUser(foundCreator.get(), foundUser.get().getId(), updatedUserData);
        Optional<User> foundUpdatedUser = userService.findUserById(updatedUser.getId());
        
        assertTrue( foundUpdatedUser.isPresent(), "testUpdateUserWithValidData(): Updated User (" + updatedUser + ") not stored");
        
        assertEquals(foundUser.get().getId(), foundUpdatedUser.get().getId(), "testCreateUserWithMinimalistValidData(): User (" + foundUpdatedUser.get() + ") ID not identical with " + foundUser.get().getId());
        assertNull(foundUpdatedUser.get().getCreatedBy(), "testUpdateUserWithValidData(): Updated User (" + foundUpdatedUser.get() + ") creator was set to null");
        assertNotNull(foundUpdatedUser.get().getCreatedAt(), "testUpdateUserWithValidData(): Updated User (" + foundUpdatedUser.get()  + ") creator date was set to null");
        assertEquals(foundCreator.get().getId(), foundUpdatedUser.get().getUpdatedBy().getId(), "testUpdateUserWithValidData(): Updated User (" + foundUpdatedUser.get().getUpdatedBy() + ") updater was not set to " + foundCreator.get().getId());
        assertNotNull(foundUpdatedUser.get().getUpdatedAt(), "testUpdateUserWithValidData(): Updated User (" + foundUpdatedUser.get() + ") updater date was not set");
        assertNull(foundUpdatedUser.get().getDeletedBy(), "testUpdateUserWithValidData(): updated User (" + foundUpdatedUser.get() + ") deleter was set");
        assertNull(foundUpdatedUser.get().getDeletedAt(), "testUpdateUserWithValidData(): Updated User (" + foundUpdatedUser.get() + ") deleter date was set");
        assertEquals(updatedFirstname, foundUpdatedUser.get().getFirstname(), "testCreateUserWithMinimalistValidData(): User (" + foundUpdatedUser.get() + ") Firstname not identical with " + updatedFirstname);
        assertEquals(updatedLastname, foundUpdatedUser.get().getLastname(), "testCreateUserWithMinimalistValidData(): User (" + foundUpdatedUser.get() + ") Lastname not identical with " + updatedLastname);
        assertEquals(updatedEmail, foundUpdatedUser.get().getEmail(), "testCreateUserWithMinimalistValidData(): User (" + foundUpdatedUser.get() + ") Email not identical with " + updatedEmail);
        assertEquals(updatedPassword, foundUpdatedUser.get().getPassword(), "testCreateUserWithMinimalistValidData(): User (" + foundUpdatedUser.get() + ") Password not identical with " + updatedPassword);
        
        // clean up
        userService.removeUser(foundCreator.get().getId());
        userService.removeUser(foundUser.get().getId());
    }

Nachdem dieser Test ausgeführt wurde werden aber die erzeugten Datensätze nicht gelöscht? Soweit ich weis wird nach der Funktion ein commit, wenn keine Exception aufgetreten ist, ausgeführt, da @Transactional gekennzeichnet.
Bei einer Exception wird ein rollback ausgeführt. Da keine Exception geworfen wurde, müssten doch eigentlich die beiden letzten Zeilen auch ausgeführt werden?

 

[LimDul]

Woran machst du fest, das sieht nicht ausgeführt werden?

 

[TM69]

Woran machst du fest, das sieht nicht ausgeführt werden?

ich sehe es in der Datenbank, da dort immer noch die Datenzeilen enthalten sind

 

[LimDul]

Ich bin mir nicht sicher, inwieweit bei Tests korrekt beim beenden alles wirklich weggeschrieben wird - normalerweise laufen die ja gegen eine InMemoryDb die nach dem Test eh weg ist.

Man lässt eher selten Unit-Tests gegen eine echte, persistente Datenbank laufen. Das sind normalerweise größere Integrationstests.

 

[TM69]

Ich bin mir nicht sicher, inwieweit bei Tests korrekt beim beenden alles wirklich weggeschrieben wird - normalerweise laufen die ja gegen eine InMemoryDb die nach dem Test eh weg ist.

Man lässt eher selten Unit-Tests gegen eine echte, persistente Datenbank laufen. Das sind normalerweise größere Integrationstests.

Dann würde sich für mich auf der anderen Seite allerdings die Frage stelle, wie will man es sonst testen?

Zumal ohne Löschung würde dieser oder andere Test-Cases mosern z.B. weil versucht wird ein weiterer Datensatz mit identischer EMail erzeugt wird.

 

[KonradN]

Dann würde sich für mich auf der anderen Seite allerdings die Frage stelle, wie will man es sonst testen?

Das ist so wie @LimDul gesagt hat: Du testest mit einer Datenbank, die bei jedem Start der Unit Tests neu erstellt wird. Bei reinen in Memory Datenbanken ist es normal, aber das geht auch mit normalen Datenbanken. Für den Test hinterlegt man dann eine Konfiguration, die angibt, dass die Datenbank bei jedem Start neu angelegt werden soll.

Dann kannst Du die Datenbank zu müllen wie Du willst. So Dinge am Ende zu machen ist auch blöd, denn bei einem Fehler sind die Daten ja auch noch da, weil er da ja auch nicht zu dem Löschen kommt.

 

[LimDul]

Es sind ansonsten eigentlich auch keine Unit-Test. Ein Unit Test muss meines Erachtens wiederholbar und unabhängig von anderen sein. Eigentlich am besten auch parallel ausführbar

Das heißt, egal was Test A macht, das darf keine Auswirkungen auf Test B haben.

Deswegen laufen in der Regel Unit Tests gegen eine In-Memory Datenbank, die für jeden einzelnen Unit-Test neu aufgebaut wird.

Wenn du wirklich testen willst, ob der User wirklich gelöscht wird, würde ich es anders machen und mich nicht auf ein Transactional verlassen. Sondern:

a) Das Transactional entfernen und den EntityManager injecten
b) Die Transaktion am Anfang des Unit-Tests starten und am Ende explizit commiten undflushen

Wenn du das gegen eine Shared DB machen willst, brauchst zusätzlich ein BeforeEach/AfterEach, was sicherstellt, dass egal in welchem Zustand der Unit-Test die DB hinterlässt (Der kann ja in jeder Zeile abbrechen), die DB danach wieder im definierten Zustand ist. Das dürfte aber so aufwendig sein, dass es sinnvoller ist, einfach für jeden Test mit einer separaten DB zu starten.