[assertj] Conditions to test Objects and Lists

[stbischof]

AssertJ provides an way to Extend Asserations see AssertJ

Conditions helpes to test Objects and Lists using is/has, isNot/hasNot, contains, doesNotContain ... They are kind of a described Predicate.

This PR provides a these Conditions.

Would be nice to get some FeedbackThe The output-message of join-Conditions will look better in next assertj version. fix in assertj

       List<ServiceEvents> serviceEvents;
    
        // ListAsserts in combination with Conditions
        serviceEvents
            .areAtLeast(1, typeModified())
            .are(hasObjectClass(A.class))
            .areExactly(3, objectClass(A.class))
            .areNot(typeModifiedEndmatch())

           serviceEvents
            .element(0)
            .is(typeRegistered())
            .is(objectClass(A.class))
            .is(typeRegistered(A.class))
            .is(containServiceProperty(k1, v1))
            .is(matches(REGISTERED, A.class, dictionaryOf(k1, v1)));

[codecov-io]

Codecov Report

Merging #256 (81299dc) into main (ea005ce) will increase coverage by 0.54%. The diff coverage is 71.83%.

@@             Coverage Diff              @@
##               main     #256      +/-   ##
============================================
+ Coverage     65.54%   66.09%   +0.54%     
- Complexity      676      694      +18     
============================================
  Files            76       79       +3     
  Lines          2316     2486     +170     
  Branches        267      278      +11     
============================================
+ Hits           1518     1643     +125     
- Misses          732      772      +40     
- Partials         66       71       +5     

Impacted Files	Coverage Δ	Complexity Δ
...main/java/org/osgi/test/common/bitmaps/Bitmap.java	0.00% <0.00%> (ø)	0.00 <0.00> (ø)
...a/org/osgi/test/assertj/conditions/Conditions.java	66.37% <66.37%> (ø)	0.00 <0.00> (?)
.../org/osgi/test/assertj/conditions/Descriptive.java	89.28% <89.28%> (ø)	11.00 <11.00> (?)
.../java/org/osgi/test/assertj/conditions/Mapped.java	89.28% <89.28%> (ø)	7.00 <7.00> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update ea005ce...81299dc. Read the comment docs.

[bjhargrave]

This is hard to understand how this is supposed to be used. That is, LOTS more javadoc is needed with descriptions and example usage.

[stbischof]

This is hard to understand how this is supposed to be used. That is, LOTS more javadoc is needed with descriptions and example usage.

@bjhargrave Could you have a look on the doc and give me a hint whether this matches what you expect?

[bjhargrave]

The output-message of join-Conditions will look better in next assertj version. fix in assertj

AssertJ 3.19.0 is released and our build is updated to use it now.

[stbischof]

rebase on main and also switched the copyright header to Eclipse.

[stbischof]

Rebased and used the new Mapped- and Verbose-Condition from AssertJ

[codecov-commenter]

Codecov Report

Merging #256 (a36922a) into main (58e59ce) will decrease coverage by 0.87%. The diff coverage is 90.19%.

@@             Coverage Diff              @@
##               main     #256      +/-   ##
============================================
- Coverage     66.02%   65.15%   -0.88%     
- Complexity      696      762      +66     
============================================
  Files            80       87       +7     
  Lines          2449     2623     +174     
  Branches        284      288       +4     
============================================
+ Hits           1617     1709      +92     
- Misses          758      837      +79     
- Partials         74       77       +3     

Impacted Files	Coverage Δ
...org/osgi/test/assertj/bundle/BundleConditions.java	75.00% <75.00%> (ø)
...est/assertj/bundleevent/BundleEventConditions.java	80.95% <80.95%> (ø)
...t/assertj/serviceevent/ServiceEventConditions.java	92.30% <92.30%> (ø)
...j/servicereference/ServiceReferenceConditions.java	92.85% <92.85%> (ø)
.../servicereference/ServicePropertiesConditions.java	93.33% <93.33%> (ø)
...sertj/frameworkevent/FrameworkEventConditions.java	95.45% <95.45%> (ø)
...org/osgi/test/junit5/service/ServiceExtension.java	89.33% <0.00%> (ø)
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 58e59ce...a36922a. Read the comment docs.

[stbischof]

I would like to add some more conditions in an extra PR especially for

• ConfigurationEvents
• OSGiFeatures
• RuntimeDTO's

not all of them are part of the Framework.

So I am not sure what the best place would be. should all Framework Conditions move from org.osgi.test.assertj.conditions to org.osgi.test.assertj.framework.conditions

It might be better so split the Conditions-Class into:

• BundleConditions
• BundleEventConditions
• DictionaryConditions
• FrameworkEventConditions
• ServiceEventConditions
• ServiceReferenceConditions

What do you think @bjhargrave @kriegfrj

[bjhargrave]

Do conditions need their own package? Can't framework conditions just be placed in the proper existing packages (by splitting them into multiple condition classes.)

[stbischof]

Sure, i think i looked to much to an Global Contitions entry-point. I splitted everything

[stbischof]

@bjhargrave This PR Seems complete to me. Could you please review?

[stbischof]

@bjhargrave i did the requested changes

[stbischof]

will add changes in next days

[stbischof]

@bjhargrave could you please review again?

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be closed if no further activity occurs. If you intend to work on this pull request, please reopen the PR. Thank you for your contributions.

[github-actions[bot]]

This pull request has been automatically closed due to inactivity. If you are still interested in contributing this, please ensure that it is rebased against the latest main branch, all review comments have been addressed and the build is passing.