hi *, trying to get an integration test working and the data saved is not getting rolled back after the test passes otherwise. i’m extending AbstractTransactionalTestNGSpringContextTests, and all the data is created via the end-point/controller that the test calls

are your testing methods annotated?

im trying to avoid adding a delete api for this object, because users deleting their accounts is supposed to sipmly disable them

i’ve tried using @Rollback

AFAIR transactional testing requires some annotations

and the class itself?

also as context im also using random_port not mock server, and testRestTemplate instead of mockMvc

class is annotated w/currently @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)

let me check an old project that I have with that kind of test

sweet thanks @dh44t. btw the genesis of this is that i added jwt auth, and want to have some level of test coverage that its working. so the way im approaching it so far is having 1 test that hits an open api, and 1 test that only allows access with a valid jwt. i wrote the tests but the test database is not getting cleaned out, probably the context that the test function runs doesn’t fully span the scope of the running test server

@dh44t uploaded a file: Untitled

That's a JUnit test, TestNG should not be that different

You also need to check that your resource is transactional, e.g. Sequences aren't transactionals

When writing integration tests there are sometimes situations where there are several independent transactions. In that case and having the same reluctance of having delete in the common API, I usually still add it but keep it under @Profile checks. Delete functionality is active under

Profiles.TEST

and inactive otherwise.

they're easy to configure

TransactionConfiguration is deprecated fyi. i don’t have a context configuration currently, so just added @Transactional and … the data which is created via the end-point is still retained after test completion

where is that info stored?

im using postgres for everything atm

ok

last option is to manually delete with an @After method

i wonder if i should just skip this and find a way to just manually delete the object at the end of the test

yes 🙂 hacky but ..

🧌

still interesting to check how those test should work on Spring Boot/5

yeah really

jumping into kotlin means i have to also figure out all the compatibility niggles

any idea why testRestTemplate.getForEntity would route to the controller get handler as expected, but postForEntity, on the same URL, would not route to the post handler

oh wait, i was missing auth.

FYI I will shortly add Kotlin extensions for

TestRestTemplate

to have same ones than

RestTemplate

@sdeleuze what does that mean specifically?