isUnmodifiable assertion for Collections

[scordio]

Summary

Considering the java.util.Collections.unmodifiableXXX() methods, we could add a isUnmodifiable() method to the assert classes for collections.

Implementation Proposal

Under the hood, the assertion should try to call all the collection APIs which are expected to throw UnsupportedOperationException. The assertion succeeds if all of them are throwing the expected exception, otherwise it fails.

We could define a new AbstractCollectionAssert which would inherit from AbstractIterableAssert and would be the parent class for all the other assert classes for collection subtypes. AbstractCollectionAssert would expose isUnmodifiable(). Also, Assertions.assertThat(Collection) and BDDAssertions.then(Collection) would be needed.

Below is the mapping between the collection type and the APIs to test. Each subtype would cover also the methods of the parent type. E.g., if we have a List, the assertion should also verify Collection methods.

Instance Of	APIs to test
Collection	add(E), addAll(Collection), clear(), iterator().remove(), remove(Object), removeAll(Collection), removeIf(Predicate), retainAll(Collection)
List	add(int, E), addAll(int, Collection), listIterator().add(E), listIterator().remove(), listIterator().set(E), remove(int), replaceAll(UnaryOperator), set(int, E), sort(Comparator)
NavigableSet	descendingIterator().remove(), pollFirst(), pollLast()
Set	-
SortedSet	-

Example

List<Integer> list = Collections.unmodifiableList(Arrays.asList(1, 2, 3));
assertThat(list).isUnmodifiable();

[HaydenMeloche]

That would be cool! How would we assert the list is unmodifiable under the hood?
We could do:

list.getClass().isInstance(Collections.unmodifiableList(Arrays.asList("any value")))

This should work if UnmodifiableList or UnmodifiableRandomAccessList is returned.

[joel-costigliola]

@HaydenMeloche that would cover the JDK types but if I use a Guava ImmutableCollection that won't work so the best implementation IMO is following the possible workaround by calling clear and catching the UnsupportedOperationException, if no exceptin is caught then fail the assertion

[HaydenMeloche]

@joel-costigliola Fair point. I'd be willing to tackle this if you think it's worth working on :)

[joel-costigliola]

Sure, go ahead, thanks!

[scordio]

@HaydenMeloche thank you! Before start working on it please let me put together a more detailed description of the approach I have in mind, so we can blame it also considering Guava. I should be able to do it today or tomorrow max.

[scordio]

I added some more details and I'll complete them during the weekend. However, this should give already a feeling so please let me know your thoughts.

I'd suggest starting the implementation of AbstractCollectionAssert which would inherit from AbstractIterableAssert and provide isUnmodifiable, covering Collection APIs only. The other types are extension points and can be done incrementally.

[HaydenMeloche]

@scordio Thanks for the detailed explanation. I'll get started when I have some time this week. I might create a draft PR when I have something concrete so I can get feedback

[HaydenMeloche]

hey @scordio got a chance to working on this over the weekend. I setup my assertion class as such

public abstract class AbstractCollectionAssert <SELF extends AbstractCollectionAssert<SELF, ACTUAL, ELEMENT, ELEMENT_ASSERT>,
  ACTUAL extends java.util.Collection<? extends ELEMENT>,
  ELEMENT,
  ELEMENT_ASSERT extends AbstractAssert<ELEMENT_ASSERT, ELEMENT>>
  extends AbstractIterableAssert<SELF, ACTUAL, ELEMENT, ELEMENT_ASSERT>
  implements IndexedObjectEnumerableAssert<SELF, ELEMENT> {

I'm running into an issue now with this setup. Existing test cases that test the Iterable type are now looking for a Collection assert rather than a Iterator assert.

Ex: This test case:
https://github.com/assertj/assertj-core/blob/4fad9a03993e66fd4e2735352c22c52d206e9a1e/src/test/java/org/assertj/core/api/Assertions_assertThat_with_Iterable_Test.java#L30

Gives error:

Required type:
AbstractIterableAssert
<?,
java.lang.Iterable<? extends java.lang.Object>,
java.lang.Object,
org.assertj.core.api.ObjectAssert<java.lang.Object>>
Provided:
CollectionAssert
<Object,



no instance(s) of type variable(s) ELEMENT, T exist so that Collection<? extends ELEMENT> conforms to Iterable<?>

In Assertions.java I setup the collection assert as

  public static <ELEMENT> CollectionAssert<ELEMENT> assertThat(Collection<? extends ELEMENT> actual) {
    return AssertionsForInterfaceTypes.assertThat(actual);
  }

Since Collection extends Iterable I understand why this is happening just not sure what the recommended action would be...
any ideas/help would be appreciated :) I can push the code up to a branch if it's easier.

[scordio]

Hi @HaydenMeloche, yes please, just push/raise a draft PR and I'll have a look.

[scordio]

Closing as the implementation for collections has been done in #2315/#2328. Maps will be covered in #2381.