ユニットテストの綺麗な書き方 - 超ウィザード級ハッカーのたのしみ
テストばっかり書いている。テストコードなんかの綺麗さを追求しても仕方ないかなと思っていたのだけれど、適当に書いていると重複が多くて大変で、シンプルに楽に書くコツみたいなのを掴んできたのでメモしておく。JUnitを対象にする。 テストクラスの単位 ユニットテストは機能要件をテストするものだ。非機能要件（性能、保守性、etc）などはテストできない。ユニットテストを書けるようなコードは保守性も上がるし、テストがあるコードは壊せないのでチューニングもしやすいというのは事実だろうが、これらをユニットテストで確認することはできない。 機能をテストするのだから、JUnitのクラスは機能（function)ごとに分けるのが自然だ。基本的にはクラス・メソッドごとになるかと思う。普通は機能ごとにクラスがあって、そのサブ機能がメソッドになっているものでしょう。したがって、クラスとそのテストのクラスは１対多にする
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
