プライベートフィールドに対するテスト | DevelopersIO

クラスメソッドの渡辺です。 弊社では業務時間内にブログを書くことが推奨されており、ネタも何でも良いということで、自動化やユニットテスト関連も投下していきます。今日は結構良く話題に出るプライベートフィールドに対するテストです。 オブジェクト指向プログラミングと可視性 オブジェクト指向プログラミングのひとつの特徴はカプセル化です。簡単に言えば、フィールド（情報）やメソッド（機能や操作）の公開範囲を可能な限り狭くすることで、安全にオブジェクトを扱うことができる、ということです。このため、古典的なJavaのコーディング標準では、次のように、「全てのフィールドをprivateに設定し、必要に応じてアクセサメソッドを定義すること」となっています。 public class Item { private String name; private int price; public String getN

[uxlayman]

例が悪すぎる。カウント回数が取得できないカウンターなんてあり得ない。 あるメソッドの実行によって、別メソッドの実行結果が変化したことをテストする、が正攻法

[tak4hir0]

プライベートフィールドに対するテスト ｜ Developers.IO

[asa_ca3]

試したいことを思いついた

[kimutansk]

プライベートフィールドは、やはりリフレクションでないと無理ですか。一昔前、リフレクションの嵐で無駄に量が多いテストコードを書いてましたねぇ・・

[nkazuki]

重箱の隅だけど，最初の例のItemはフィールドがfinalであるべきか，さもなくばアクセッサを提供したほうが良い気がする．アクセッサのメリットは例えば: http://www.alles.or.jp/~torutk/oojava/codingStandard/writingrobustjavacode_pidid93_c3.html

[diary193]

テスト技法の知識がリフレクションで止まってた。再学習しよ。

[bouzuya]

正確には「デフォルトアクセス」じゃなかったっけ、関係ないし記憶違いなら悪いけど。

[daisuke-m]

俺もパッケージプライベート派。

[bufferings]

僕もデフォルトでパッケージプライベートにしてるなぁ名前の通り。spyするのにprotectedにしたり。