1

Fluent Assertionsを使い始めてとても気に入っていますが、次のような一般的な方法で既存のテストを拡張できるかどうか疑問に思っています。

  • hasSizeAtLeast(int limit)メソッドを追加GroupAssert
  • startsWithIgnoringCase(String prefix)メソッドを追加StringAssert
  • 次のような代替手段を使用しますx.either().isIn(someSet).or().isNull()

これらは、すぐに必要になる可能性のある例にすぎません。それぞれにいくつかの回避策を講じることができますが、読みやすさと流暢なインターフェースの使いやすさが失われます。

私の最後の例は、 iff bothx.isIn(someSet)とx.isNull()do をスローすることを意図しています。

4

1 に答える 1

2

これは、すでに処理された型でアサーションを拡張するためのAPIを開くことについての著者による投稿です。特にレッスン1では、クラスのファイナライズを解除するための変更について説明します。投稿には、サブクラス化の例も示さStringAssertれていMyStringAssertます。

StringAssertただし、 APIの「流暢さ」を維持するような方法でクラスを拡張することはできないようです。クラスは最終的なものではStringAssertありませんが、それでもStringAssertサブクラスでそのタイプ（つまり、メソッド自体によって返される「this」タイプ）をパラメーター化することはできません。たとえば、にメソッドを追加するとcheckFooしますMyStringAssert。あなたが発見したように、元のStringAssertメソッドが返すので、以下は無効ですStringAssert：

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

最初にサブクラスのメソッドを呼び出すことしかできません。これは有効ですが、ちょっと足りないものです。

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

作者に連絡するか、彼のgitプロジェクトにパッチを提出することを検討してください。考えられる解決策は、パラメータ化された型をに追加し直し、とにかく推奨されるエントリポイントである内の匿名サブクラスを介して具象型をStringAssert提供することです。そうすれば、あなたが説明したように、他の誰もがサブクラス化できます。私もこの提案をテストしていませんが、それは理にかなっているようです...StringAssertAssertions.assertThat(String)StringAssert

于 2011-07-15T04:10:22.017 に答える