これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita

もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」

[mas-higa]

原理主義じゃないけど、テストファーストで書いてると自然とこうなる。/ id:lainof 条件によって出力が異なる場合は、出力先を引数で渡すんです。テストのときは StringWriter を渡せばいい。

[lainof]

標準出力の例は、条件によって出力される場合とされない場合があるときにどうテストするつもりなんだろう？結局フックするのかな？

[dorapon2000]

"ユニットテストで最も意識を傾けないといけないのはロジックのテストです。 ファイル入出力や標準入出力、あるいはログ出力のような既に品質が十分に確認されたテストをする必要はありません。"

[areyoukicking]

テストケースの書き方参考になる

[D_first]

テストが書かれていない元のコードを改変するわけにはいかないから、ここでいう意識高い系ダメテストを書かざるを得ないのではないか

[incep]

↓ブクマに対するフォローアップ記事でもある

[takasing]

“ロジック内からファイルの直接の取り扱いを分離し、Reader/WriterやInputStream/OutputStreamといった インタフェースに対してプログラミングをし、テストではStringReader/StringWriter等を使うと簡単です。”

[nihonbuson]

"まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。"

[Dai_Kamijo]

400いいね！ | これだけは覚えたい、ユニットテストを書くための４つのデザイン by @koduki — キータ (@Qiita) February 2, 2017 from Twitter https://twitter.com/Dai_Kamijo February 02, 2017 at 12:01PM via IFTTT

[gen0083]

ユニットテストのコツはロジックと入出力を分離すること

[tofu-kun]

これ意識できてないとテストコードつらい

[kojiro-s]

勉強になりました

[nacika_inscatolare]

とてもよい記事です。

[masaru_b_cl]

暗黙の入出力を明示化しようねって感じですよね。さっくり読むのによい。

[itouhiro]

「Java。ユニットテストを書きやすい元のコードを設計する→基本『ロジックとI/Oを分離、繰り返しても同じ値が返る』　出力内容組み立てとIOを別メソッド。乱数は引数で。ロジックだけテストでいい。初期化は注意」