これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
Bash用ユニットテストフレームワーク作りました - Folioscope
Bash用テストフレームワークに、Batsやshunit2がありますが、イケてないなーと思ってたら、気づいたら自分で作ってました。 github.com テストの結果はモダンなテストフレームワークのように、カラフルに表示します。 またFAIL時は、FAILしたテストの結果を表示します。 自分の Arch Linux 上の Bash 4.3.42 および、Travis CI 上で動作することを確認しています。 インストール curl -o ~/bin/bashtub https://raw.githubusercontent.com/ueokande/bashtub/v0.1/bin/bashtub chmod +x ~/bin/bashtub です。ただし~/binはパスが通ってるとします。 これでターミナルから bashtub と打つことで実行できます。 bashtub テストを書く 各
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
