Platform: debian 11.7 "bullseye", amd64
openjdk-17-jdk:amd64 17.0.6+10-1~deb11u1 (ie. java 17)
karaf 4.4.3
pax-exam 4.13.5
eclipse 2023-03 (4.27.0)
What I usually do when creating JUnit tests is to run in a
red-green-red-green... rythm, the way Martin Fowler taught me.
I.e. I create the test first to be failing and then I make the test
green, create a new failure situation, fix the failure to make the test
green and so on.
When doing this on a pax exam test I saw some weird behaviour: the first
assert in the test was failing, and when I changed the expected value to
satisfy the test, the assert failed in the opposite way.
When I commented out the test, the test failed in an even more drastic
way: it failed in uniqueness constraints in the derby database used in
the test.
And the behaviour was completely repeatable, remove this and see this
error. I got the same behaviour inside eclipse as I did when running
with surefire in maven.
So I figured there had to be some bug in my code: some value or array
that was reused somehow, and I spent some time digging into that without
being able to figure it out. As far as I could tell I created new
ArrayLists containing new data objects.
I eventually figured it had to be related to my new
expected-to-be-failing asserts: and when I made them green, the entire
test ran green.
I tought that was weird and google found me nothing, so I thought I'd
ask here: is triggering the wrong assert when having a failing assert,
normal behaviour in pax exam?
Or is it just me? :-)
Here is what happened/happens (I can reproduce this behaviour at will):
Here is my test:
https://gist.github.com/steinarb/fbfb78c8b69a61c92d66bde6b9994573
If I change the assert on line 32 to fail, ie.:
https://gist.github.com/steinarb/ecdf40e201c85b671e301e9fea5a09e5
(change "jad" in the expected value to be "jod")
then what fails, is the assert on line 24, ie
assertEquals(1, initialAccounts.size());
The failure stack trace looks like this:
https://gist.github.com/steinarb/5792ab35596e47cbca8f086a9bcfde2b
If I change the expected value on line 24 from 1 to 2, ie.
assertEquals(2, initialAccounts.size());
then the test fails because it gets 1 when 2 is expected (ie. you can't win!
:-) )
https://gist.github.com/steinarb/8b971ee7729bcaeecfdbc2254b8f9caf
If I comment out the first assert, ie. like this:
//assertEquals(2, initialAccounts.size());
then I get an DerbySQLIntegrityConstraintViolationException exception
that has deserialization issues, but is a constraints error in the table
(what I would get if I tried ti insert an account with an existing
username)
https://gist.github.com/steinarb/ce5f845ca7d67754281b1f42f35fa92e
If I continue to comment out asserts further downn in the test I
continue to get DerbySQLIntegrityConstraintViolationException
exceptions.
But if I change all asserts so that they are green, then everything runs
normal.
Weird!
The project with the karaf pax exam integration test, is here:
https://github.com/steinarb/liquibase-karaf-feature
The pax exam test is here:
https://github.com/steinarb/liquibase-karaf-feature/blob/master/liquibase-integration-test/karaf.liquibase.tests/src/test/java/no/priv/bang/karaf/liquibase/tests/LiquibaseKarafFeatureIntegrationTest.java
--
--
------------------
OPS4J - http://www.ops4j.org - [email protected]
---
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ops4j/87mt1fjhiz.fsf%40dod.no.
