Re: モッククラス、下から見るか？横から見るか？

先日Twitterでリプライがきたのでみてみたら素晴らしいブログ( モッククラス、下から見るか？横から見るか？ )がありました。

プログラムにおける自動単体テストでモックをつかうべきかどうか悩んでいるというもの。

私なりにこれに回答しようとおもいます。みんなもなにかおもうところがあれば、SNSではなくブログにしてほしい。(Webからそのままアクセスできるという点において)

1. 基本方針

1. 可能なかぎりモックライブラリはつかわず、コンストラクタDI(Dependency Injection)で解決できるならそうする
2. 往々にして厳密な単体テスト(1ファイルにとじたテスト)はしておらずコンポーネントテスト(複数ファイルにまたがったテスト)がおおい

2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう

自動化されたテストがなく、これからリファクタリングをしたいというときには、既存のプロダクトコードを変更せずに自動テストを実装すべきです。そのときには時刻やDBやAPIなどに依存したコードをテストしなければいけないでしょう。

テスタビリティの低い設計ではこれらを「テストから設定」することがむずかしかったり、高速な単体テストとすることがむずかしかったりします。そのときには、モックライブラリをつかって時刻やDBやAPIなどをテストダブル(スタブやモック)におきかえます。

モックライブラリは実質的にリフレクションなどをつかっているものがおおく、プロダクトコードを変更せずにプログラマーが自由なコードで一部の処理を代替させることができます。これによって自動テストを実行できるようにしてから、徐々にリファクタリングをすすめていく。という場面ではモックライブラリが適切でしょう。

3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。

たとえばトランザクションやコネクションのコミットやクローズ処理が確実にされているかを検知したい場合につかえます。 単体テストのメリットとして、IO処理が失敗した場合を簡単に模倣できるという点があります。それ自体はコンストラクタDIな設計における簡易なテスト用のスタブクラスでもできます。

ですが、たとえばDB操作が失敗したときに必ずコネクションがcloseされていることのテストはなかなか検知できません。モックライブラリであればできます。 もちろん静的コード解析でも対応できる部分はありますので、一概にモックライブラリでやるべきとはいいませんが、なかなかに便利なときがあります。

Javaだとtry-with-resourcesとかでかいておけばいいじゃんというのもありますが、rx系というかpromise系というかのライブラリをつかっていたり、いくつかの設計においてはtry-with-resourcesをうまくつかえないことがあります。そのときには、モックライブラリで検知させるというのは妥当だとかんがえています。

実践テスト駆動開発 (Object Oriented SELECTION)

テスト駆動開発

Effective Java 第3版

ソフトウェアコードのはじめかた

• プロジェクト名や名前空間の雑さはIDEなどの強力さを考慮して決めること
  • IntelliJ IDEAなど => 名前空間やファイル名変更が強力なので、雑に決めてもあとから変更できる
  • Vimのみ => 名前空間やファイル名変更が
• プロジェクトをつくるときは次の手順でやること
  • てきとうにスキャッフォルドでつくる。gradle initとか。
  • gitignoreを追加する gitignore.io - Create Useful .gitignore Files For Your Project
  • git init
  • git add
  • git commit で↑までにやったコマンドやWebサービスでの指定方法などをコメントにのこす
• 要件を確認してアーキテクチャと単語の整理
  • noteという名前空間をつくり、そこにメモ書き用テストファイルをつくる。
  • 要件をテストコードにはりつける
• 要件の一部をテストコードに翻訳する。簡単なケースだけでいい。 : RED
• プロダクトコードを仮実装する。 : GREEN
• 他の入出力のケースをテストに追加する。三角測量。 : RED
• プロダクトコードを修正する。 : GREEN
• テストコードをリファクタリングする。 : GREEN
• 何をクラスとして切り出すかは、何をつくりたいのかを定義している段階できまるので、コードをかきながら決めないほうがいい。
• テストコードはできるだけ長く書きはじめていく。テストコードは動的構造を記述する部分であり、プロトコル定義ツールとして使う。
  • 小さいテストコードはあくまでデバッグのサポート、型システムのサポート程度に考えて記述する。
• 静的構造はプロダクトコード側で記述できる内容なので、プロダクトコードのリファクタリングや大枠の設計でおこなうようにする。
• テストコードとプロダクトコードの設計がかたまったら、noteにあるテストコードを適切な名前空間にきりだしてあげる。
  • ユースケースを確認するようなテストは userguide, デバッグサポートのテストは developerguideなどがわかりやすい。ただ、developerguideのほうはビルドツール、IDEなどの連携をかんがみて、プロダクトコードと同じ名前空間にしたほうが便利なときもある。

メールのテストとか気になっているやつ

メールのテストを中心にまとめました。

フロントエンドのテストツールとか気になっているやつ

テストツールというかサービス中心なんだけど、書籍情報も。

機械学習のテスト、自動テスト入門書籍など気になっているやつ

ここ1ヶ月くらいで気になったものまとめ

週刊ソフトウェアテスト 2015-14 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

週刊ソフトウェアテスト 2015-13 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

kyon_mmの意見

テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（後編） JaSST'15 Tokyo － Publickeyを読んでいて、概ねいいと思ったのですが、この例示というか現場はクソだなー辛そうだなって思ったのが次の文章の後半です。

私は実はQuality Assuarance（品質保証）という名前を
（私たちの仕事の名前として）使うことは反対です。
質の高い製品を作る、確約するというのはプロジェクトの誰もが持つ共通の目的です。

テスターはコードを変更する権利はなありません。
スケジュールを変更することも、予算をコントロールすることもできない。
スコープも変えられないし、プログラマの採用もできずクビにもできません。
リリースするかどうかを決定する権限もありません。

チームにおいてテスター、プログラマー、マネージャーは得意分野の宣言でしかないのに、なにを言っているんだって感じ。人の採用については難しいかもしれませんが、最低でもコードを変更する権利がないっていうのはどうかと思いますし、コードを変更するスキルがあまりにもないテスターってよっぽど特定分野でハイスキルじゃないと辛そうっていう感じが。