Subscribed unsubscribe Subscribe Subscribe

Kengo's blog

Technical articles about original projects, JVM, Static Analysis and JavaScript.

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

プログラミング Java

オフラインになっていた間、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を作成していると考えれば、正しい優先順位付けと言える。