mockitoコードリーディング備忘録

オフラインになっていた間、mockitoのコードを読んでいました。自分用ですが、感想を簡単にまとめておきます。

• 全体的にとても読みやすい。
  • クラス名・変数名・メソッド名の命名が適切なのだろうが、それ以上にクラス分割の単位が適切であるように思う。
  • どうすればマネできるのかは謎だが、internalクラスの役割分割単位に従来とは違う細かさを感じる。後述するWhiteboxクラスなど。
  • 単に細かくクラスを分ければいいというモノではないわけで、理解にはもう少し読み込みが要るかも。

• 出力する文字列の改行コードはLF固定、プラットフォームによって変えたりはしていない。
  • StringJoinerに"\n"がベタ書き。
  • 複数環境で実行したテストの結果を突き合わせるケースなど、固定されていたほうが好ましい場合は多そう。
• モック処理自体はjMockのコードを再利用している様子。
  • ClassImposterizerのjavadocに"Thanks to jMock guys for this handy class that wraps all the cglib magic."と書いてある。
  • cglibとはこれのことか。
• クラスが短い。javadocを除けば数十行で収まるコードがほとんど。
  • Whitebox, StackTraceFilterといったクラスは私ならprivateメソッドとして定義してきただろうが、たしかにクラスのほうがいいのかも。
• 末端のクラスは実装が適当なことが多い。
  • AccessibilityChangerは特定のFieldインスタンスに関する状態を持つクラスなのに、フィールドにFieldインスタンスを持たない。使う側が注意する必要あり。
  • SequenceNumberはAtomicIntegerが使えるはずだが、より遅いsynchronizedが採用されている。
• 例外を投げるためのメソッドを集めたReporterクラスが面白い。
  • メンテナンスを容易にするために1箇所に集めているらしい。
  • メッセージの多言語化などを必要とするプロダクトでもこのアプローチは使えそう。

/**
 * Reports verification and misusing errors.
 * <p>
 * One of the key points of mocking library is proper verification/exception
 * messages. All messages in one place makes it easier to tune and amend them.
 * <p>
 * Reporter can be injected and therefore is easily testable.
 * <p>
 * Generally, exception messages are full of line breaks to make them easy to
 * read (xunit plugins take only fraction of screen on modern IDEs).
 */
public class Reporter {

• internalなクラスにはjavadocがほとんど無い。
  • ドキュメントがほしい箇所がないわけではない。特に出力文字列のフォーマットなどはどこかにまとめないと、新参者がキャッチアップするのは難しそう。
  • ライブラリとして公開するクラスを優先してjavadocを作成していると考えれば、正しい優先順位付けと言える。