Spock1.0でBDDとレポートが進化している！ #gadvent
はじめに
これはG* Advent Calendarの2日目の記事です。今日はSpockの新機能について書きます。明日はRyotaMurohoshi さんの「初心者でも】やろうぜGroovy!〜Web APIたたいたり、レスポンスの中身確認したり、データを保存したり〜編【今すぐ使える】」です。
概要
2014/12現在、最高のユニットテスティングフレームワークであるSpockの次のメジャーバージョンである1.0の機能を紹介します。 BDDを強力にすすめるためのアノテーションと、最高にクールなテストレポーターが実装されました。個人的には本当に本当に素晴らしいリリースです。 はやくこい！！！！！
続きを読むGradleを入門する方法から更に知る方法まで #gadvent
はじめに
これはG* Advent Calendarの1日目の記事です。今日はGradleの勉強方法について書きます。明日はid:kyon_mm さんの「Spock1.0でBDDする」です。
概要
GradleというGroovy製のビルドツールが最近人気になってきていますが、なにを参考に勉強するのがよいのかをここで示します。社内で広めるときの参考にしていただければ幸いです。
続きを読む週刊ソフトウェアテスト 2014-48 #swtest_jp
前書き
ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。
ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！
kyon_mmの意見
POSTDさんが【翻訳】「ほとんどのユニットテストが役に立たない理由」を読んで | POSTDを公開してくださいましたが、翻訳対象の記事を書いた人はJames O Coplienの「ほとんどのユニットテストが無駄になる理由」を勘違いしているということ、元記事自体また、元記事でのJames O Coplienからのコメントでも明らかです。この記事を読んでたくさんの人がCoplienの意見を誤解してしまったのではないかと非常に心配です。ということで、現在カウンター記事を執筆中です。（Coplienの言いたかったことを要約する感じの記事です）あまりにも無駄なユニットテストを書いている人がたくさんいるという現状をなんとかするために、丁寧に解説した記事への冒涜だと思う程度には私はイライラしました。TDD is Deadほど投げやりな話でもないのですから。（TDD is Deadは記事は投げやりだったけど、投稿後のHangoutsの会談？が素晴らしかったのです。）
先週末にはTDDBootCampが東京で開催されました。xUTPの著者であるGerardが基調講演をしてくださり、彼に様々な質問をできてとても楽しかったです。自分が主催ではなかったこともあり、あまりBDDについて伝えられませんでしたが、最後に短い時間でしたがいくつかサンプルコードと書き方の手順を見せられたことはよかったと思います。"Addしたら1件増えている"だけのテストの相対的な価値の低さに気づいた人が増えてくれればうれしいです。
続きを読むテスト全体の良い書き方について。 #swtest_jp
概要
テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。（実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基本はこの形であり、ここにある考え方が重要だと思っています。
つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。
僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。
まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。
構成のテンプレ
基本的に3段構成です。
- 回避したいリスク
- 回避していることを保証する手段
- デシジョンテーブルなどのパラメタライズ
- 回避していることを保証する手段
冒頭の「BDD-Style」と言っているのは、「回避していることを保証する手段,デシジョンテーブルなどのパラメタライズ」の部分が該当します。
例示すると（悪い例かもしれないですが、イメージを伝えるために）
- はてなユーザーが投稿後のブログを再編集できないリスク
使うツール
これを書くためにはツールは非依存ですが、テーブルを綺麗に表示できるものがあるといいでしょう。（ライブプレビューでもいいし、表を綺麗に書けるものでもいい 例えば、MarkdownやAsciidocでやるなら、Atomなんかがいいかもしれません。別にExcelでも構わないと思います。
ちなみに僕はOrg-Mode一択です。
それぞれの説明
簡単ですが、3つそれぞれについて説明します。
回避したいリスク
トップレベルにくるのは「このプロダクトにおいて何を回避しなければいけないか」というリスクを書きます。ゴール指向などではゴールを書くべきところなのですが、それは何かを生み出すという視点で有効です。僕のような何かを安全に保つという視座においては「何が起きてはいけないのか」というリスクで書くことが有効でした。
例えば、「登録ができる」だとそれしか確認しない事が多くて、 「登録できないリスク」と書かれていると逆のパターンである「登録できる」はすぐに思いつくので、「登録できる」「登録できないって事は起きない」の両方の視座で確認しやすかったのです。
また、このリスクは「単体テスト不可能になるリスク」とかも書けますし、「チームのコアデベロッパーが来月でいなくなる」とかも書けます。
リスクのフォーマットについてはリスクベースドテストやリスクマネジメントの本で書かれているようにいろいろあります。 なんとなく考えてみる分には「誰にどんなことが起きる」というイメージでまずはいいと思います。
回避していることを保証する手段
リスクには「それを回避する手段」がひも付きます。「それが起きないことを確認する方法」であればテストになります。
これはいわゆるテストスイート名やシナリオのタイトル、ユースケースのタイトルが該当します。どのような手段をとっているかがわかれば、別に２，３の単語でもいいとは思います。わかれば。
テストではない場合、つまり先の「チームのコアデベロッパーが来月でいなくなる」とかだと「コアデベロッパーはデベロッパーと代わる代わるペアプロする」とか「コアデベロッパーが参考にしている情報をWiki化する」とかでしょうか。
デシジョンテーブルなどのパラメタライズ
テストコードでいわゆるパラメタライズされているとか、テストの組み合わせ表とか、CucumberなどでのExamplesが相当しそうなところです。 この表でどこまでを書くかはチームやシナリオの書き方に依存します。ですが、個人的にはシナリオのステップをテーブルにはあまり書かないようにしています。 だいたい次の4つに分類できます。
- 直接入力するもの
- 環境として入力になるもの
- 直接出力するもの
- 環境に出力するもの
いいところ
例えば、POだったり顧客だったりPMだったりが「プロジェクト後半に爆発しないようにテストしたいな」とか「最低限リリースできるラインは保証されているのかな」とか「何が保証されているのか」といって見たいときにはだいたい「回避したいリスク」の一覧を見ると議論できました。
これは設計であって、実装ではないというところ
先にも書きましたが、工夫をすることでももっとよくなります。リスクはタグで分類するとか、テーブルに書く内容をライブラリ化するとか。
この方法論では、書くときの考え方の補助と議論しやすい見え方の補助を目的としています。なので、「テストを実行するときに面倒になるかもしれない」ということには対応していません。 例えば「リスクAとリスクBに対応している手段Xがあるから、手段Xでそれに紐づくパラメタライズをうまくマージすれば、テストを実行する時間が短くなる！」とかはよくある話しです。 この辺はテスト実行の最適化と僕は読んでいて、いわゆるJITコンパイルみたいなものだと思っています。 それを簡単にできるようなツールを開発するのが、いまの僕のちょっとした目標です。
リスクを思いつく方法
今まで出してきたバグやチームの状況を見て、推測するのがいいと思います。ですが、何か初めてのことがあると急にできないのもよくあると思います。
そんなあなたに本当に素晴らしいものがあって、鈴木三紀夫さんの「意地悪漢字」というやつです。いわゆるガイドワードなのですが、達成したい要求やプロダクトライフサイクルとこの意地悪漢字を組み合わせるといい感じにリスクがぼんぼん見つかります。ぜひご活用ください。
意地悪テストのブログ
意地悪テストのスライド
推奨書籍
- 作者: Rick Craig,Stefan P Jaskiel,成田光彰,宗雅彦
- 出版社/メーカー: 日経BP出版センター
- 発売日: 2004/10/22
- メディア: 単行本
- 購入: 1人 クリック: 36回
- この商品を含むブログ (12件) を見る
ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために
- 作者: Rex Black,テスト技術者交流会,トップスタジオ
- 出版社/メーカー: 日経BP社
- 発売日: 2005/01/27
- メディア: 単行本
- 購入: 2人 クリック: 11回
- この商品を含むブログ (8件) を見る
ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)
- 作者: SQuBOK策定部会
- 出版社/メーカー: オーム社
- 発売日: 2014/11/29
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)
- 作者: ナンシー・G・レブソン,松原友夫,西康晴,青木美津江,吉岡律夫,片平真史
- 出版社/メーカー: 翔泳社
- 発売日: 2009/10/30
- メディア: 大型本
- 購入: 3人 クリック: 26回
- この商品を含むブログ (9件) を見る
まとめ
ほとんどのテストはリスクベースドテストなんだから、テストの書き方からして、リスクベースドにするのが早いです。明確にしておかないと、なんのためのテストかわからない（わからなくなる）し、自信を持ってリリースするためには、自分だけがわかればいいっていうのは少ないほどうれしいはず。
週刊ソフトウェアテスト 2014-創刊号 #swtest_jp
前書き
ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。創刊号なので、若干時期が広めになってるのと、選択基準がまだハッキリしていない部分もございます。
ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！
Summary
- CIaaS(CI as a Service)のCircle CIに無料のプランが追加されました。個人的には、CloudBeesの無料枠からの移行組をとろうとしているのかなぁ？と感じました。
- HTTPSの無償利用が実現に向けて動き出しました。実現すれば、HTTPSのテストをしづらかったたくさんの開発チームが救われそうですし、HTTPSを利用するようなアプリケーションを作りやすくなりそうですね。
- Webアプリケーションのセキュリティのためのテストに使える無償ツール「Firing Range」をGoogle が公開しました。他のツールよりも実際にありえそうなテストケースを実行するツールのようです。GitHubで公開されているので、コードを読んでみようかと思います。
- モバイルフレンドリーなWebアプリケーションであるかのガイドと確認するためのツールである「Webmaster's Mobile Guide」をGoogleが公開しています。URLを入力するだけでレポートしてくれるので、勉強しながら開発するのに良さそうです。
- モダンなビルドツールであるGradleの日本語書籍である「Gradle徹底入門」が発売されました。自動化の強い味方になるので、ぜひご参考にしてください。
- 週末にはTDDのイベントであるTDD Boot Camp in Tokyoが開催されます。xUnit Test Patternsというユニットテストのバイブルを著者であるGerardが基調講演をします。
- 先週は、JaSST 四国 2014が開催されました。レポートが待ち遠しいところです。
- 来週末にはJaSST 九州 2014が沖縄で開催されます。参加費は無料で、申し込み受付中のようです。
- JavaScriptの静的検査ツールとしても、altJSとしても使える「Flow」というツール、プログラミング言語をFacebookが公開しました。OCamlで開発されているようで、先日公開していたHackといい、Facebookは前衛的ですごいですね。
Gradleの最新版を簡単に使う方法
Gradleの最新を使いたい
Gradleは素晴しいビルドツールで、インストールも簡単です。でも、成長がはやいので、いったい何がGradleのトレンドなのかわからなくなることも最もです。また、Gradleのバグが直っている可能性を考えると最新版を使いたくなります。
つまり、僕が一番使っているGradleのバージョンはmasterブランチなんですよ。実は簡単に使えるので、紹介します。
最新版を利用する準備
次のツールがインストールされている前提です。
- gvm / posh-gvm
- JDK8
- git
gvm install gradleでgradleをインストールできます。基本的にgradle.orgでリリースされているものが使えます。でも、それでは満足できないです。ということで、次のコマンドを実行しましょう。
git clone https://github.com/gradle/gradle.git cd gradle sh ./gradlew install /path/to/gradle-master # もしくは gradlew.bat install /path/to/gradle-master gvm install gradle master-version /path/to/gradle-master gvm default gradle master-version gradle -v
これで、あなたの環境ではgvmで最新版のGradleとリリース済のGradleを利用することができます！！
一行ずつ解説しましょう。
- git clone https://github.com/gradle/gradle.git
- Githubからgradleをクローン
- cd gradle
- ディレクトリを移動
- sh ./gradlew install /path/to/gradle-master, gradlew.bat install /path/to/gradle-master
- gradleをビルド gradleはgradlewrapperという機能によって、gradleがインストールされていなくてもgradleを実行することができます。(実行時に必要なgradleをダウンロードしてきて利用する)
- gvm install gradle master-version /path/to/gradle-master
- gvm install fooBarとすると、普段はgvmが管理しているバージョンのみがインストールできますが、gvm install toolName customVersion toolpathとすることで、任意のバージョン名でローカルにあるツールをgvmの管理配下に追加できます。
- gvm default gradle master-version
- デフォルトで利用するgradleのバージョンを先に指定したmaster-versionにします。
- gradle -v
- gradleのバージョンが2.3.xxxx などと出ることを確認します。
まとめ
Gradle masterブランチを利用するためにビルドツールをインストールする必要もないし、gvmでリリース済のものと簡単に切り換えられます。前衛的にGradleを使い倒しましょう。
Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築
- 作者: 綿引琢磨,須江信洋,林政利,今井勝信
- 出版社/メーカー: 翔泳社
- 発売日: 2014/11/05
- メディア: 大型本
- この商品を含むブログ (2件) を見る
