Hello
I'd like to help, but seeing this in your shared test:
final MavenArtifactUrlReference sampleappFeatureRepo = maven()
> .groupId("no.priv.bang.karaf")
> .artifactId("karaf.liquibase.sample.datasource.receiver")
>
doesn't help - this is your private artifact and you'd have to share entire
project and not a @Test method.
I completely support red-green-red-green-... cycle. But I'm pretty sure
Martin Fowler didn't have integration tests in mind. It was about unit
tests.
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).
I can't help with any particular issue here - I recommend you to check
Karaf's own Pax Exam integration tests:
https://github.com/apache/karaf/tree/main/itests/test - see how the tests
are structured.
I also can suggest Pax Web tests where I tried very hard to put as many
comments/explanations I could:
https://github.com/ops4j/org.ops4j.pax.web/tree/main/pax-web-itest/pax-web-itest-karaf
regards
Grzegorz Grzybek
niedz., 4 cze 2023 o 18:53 Steinar Bang <s...@dod.no> napisał(a):
> 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 - 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/87mt1fjhiz.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/CAAdXmhrS%2BVe5FOXvV%2BTSHWmFdmv4Q5DZYuWQkm4hcMY-sMEUgA%40mail.gmail.com.
