Hello
Sorry, but I didn't have time to check/run your integration tests.
You've mentioned that the test may be run twice - that's possible depending
on the configuration of maven-surefire/failsafe-plugin. I don't know.
Usually in such cases I turn on quite detailed logging, so I can see how
all the threads interact. For example in Pax Web I use this logging
configuration:
https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.20/pax-web-itest/pax-web-itest-karaf/src/test/resources/log4j2-test.properties#L38
appender.file.layout.pattern = %d{HH:mm:ss.SSS} [%thread] %-5level (%F:%L)
%logger - %msg%n
The most important part is to ensure you have full thread name (%thread),
so you can see how the threads interact. I've detected many deadlocks and
thread synchronization problems in last years simply by looking at the logs.
If the green tests are fine, you're half way to success ;)
regards
Grzegorz Grzybek
niedz., 11 cze 2023 o 15:51 Steinar Bang <s...@dod.no> napisał(a):
> >>>>> Steinar Bang <sb-1rlz5cwd...@public.gmane.org>:
> >> You seem to be testing everything including verification of database
> >> content. Getting assertion exceptions in your tests code _may_ lead to
> >> transaction rollback (I have no idea if this is true - I'd have to see
> >> your entire test setup).
>
> > Maybe...? There shouldn't be any open transactions across the asserts or
> > even across the methods called between the asserts.
>
> > I wrap all of my read and write interactions with JDBC in a
> > try-with-resource for a JDBC Connection instance.
>
> I think it is related to the test somehow being run twice, when an
> assert fails...?
>
> That would explain both the non-causal behaviour of breaking a late
> assert making an earlier assert fail, and the database constraints
> failure caused by trying to add the same username twice (see other,
> related thread).
>
> I think maybe, if I make each run of the integration test have an unique
> database name, then both the weird non-causal asserts, and the database
> constraint failures will go away, and then, maybe, the correct failing
> assert will be highlighted.
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/87o7lmgla7.fsf%40dod.no.
>
--
--
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
---
You received this message because you are subscribed to the Google Groups
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ops4j/CAAdXmhoyEDVViconCS4v00DVCvy6sCvJnPwZM44BCncgm3V%3DJA%40mail.gmail.com.
