Расширение свободного интерфейса

Question

Я начинаю использовать Fluent Assertions, и мне это очень нравится, но мне интересно, возможно ли расширить существующие тесты в общем виде, например так:

• добавить метод hasSizeAtLeast(int limit) в GroupAssert
• добавить метод startsWithIgnoringCase(String prefix) в StringAssert
• использовать альтернативы, такие как x.either().isIn(someSet).or().isNull()

Это всего лишь примеры того, что мне может понадобиться в ближайшее время. Я могу сделать некоторые обходные пути для каждого из них, но затем я теряю удобочитаемость и простоту использования свободного интерфейса.

Мой последний пример предназначен для того, чтобы x.isIn(someSet) а также x.isNull() делать.

Answer 1

Вот сообщение автора об открытии его API для расширения утверждений на уже обработанные типы. В частности, на занятии № 1 обсуждается переход к незавершенным занятиям. В посте также приводится пример подкласса StringAssert как MyStringAssert,

Тем не менее, похоже, что вы не можете расширять классы, такие как StringAssert таким образом, что поддерживает "беглость" API. StringAssert класс не является окончательным, но все же он не позволяет вам параметризовать его тип (то есть тип "this", который возвращается методами в StringAssert сам) в подклассах. Например, допустим, вы добавляете метод checkFoo в MyStringAssert, Как вы обнаружили, следующее неверно, потому что оригинал StringAssert методы возврата StringAssert:

new MyStringAssert("abcd").contains("a").checkFoo(); // compile-time error!

Сначала вы можете вызвать только методы вашего подкласса, что допустимо, но в некотором смысле неубедительно:

new MyStringAssert("abcd").checkFoo().contains("a"); // compiles

Возможно, вы захотите связаться с автором или даже представить патч для его проекта git. Возможным решением было бы добавить параметризованный тип обратно в StringAssert, а также предоставить StringAssert конкретный тип через анонимный подкласс в Assertions.assertThat(String), который является рекомендуемой точкой входа в любом случае. Тогда все остальные могут подкласс StringAssert как вы описали. Я тоже не проверял это предложение, но, похоже, оно имеет смысл...