うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

IntelliJ IDEA14をインストールしたら設定すること（Groovy編） #gadvent

Groovy

はじめに

これはG* Advent Calendarの4日目の記事です。今日はSpockの新機能について書きます。明日はid:kyon_mm さんのGeb 0.10の新機能について です。

概要

以前にIntelliJ IDEA 13で書いた「IntelliJ + Groovyでテストコードを書く毎日ですが、これらを設定しないと仕事にならない系ものをまとめてみました。」というやつをアップデートします。内容は変わっておらず、IntelliJ IDEA14のUIに合わせたという感じです。

各項目の「keyword」にあるものをIntelliJのメニューバーにあるHelp -> Find Actionで出てくる検索ボックスにいれると「この設定だよね？」って検索結果がでるので、それをクリックすれば一発で有効になります。また、Settingsでkeywordを入力するとそれっぽいものがフィルタリングされて表示されます。

IDEA起動時に最後に開いたプロジェクトを開く|開かない

keyword:Reopen last project on startup

  1. Settings -> Appearance & Behavior -> System Settings
  2. Startup/Shutdown -> Reopen last project on startup のチェックボックスをoffにするとIDEA起動時に最後に開いたプロジェクトを開かない。
  3. Apply

行番号を表示する

keyword:Show line number

  1. Settings -> Editor -> General -> Appearance
  2. Show line numberのチェックボックスをonにする。
  3. Apply

フリーカーソルをやめる

keyword:Allow placement of caret after end of line

  1. Settings -> Editor -> General
  2. Virtual Space -> Allow placement of caret after end of line のチェックボックスを外すとフリーカーソルが無効になる。
  3. Apply

エディタで表示しているファイルとプロジェクトのツリーの選択ファイルを同期する。

  1. プロジェクトを開いている状態で、projectの歯車をクリックする。
  2. Auto Scroll from Sourceにチェックがつく状態になるようにクリックする。

プロジェクトのツリーで選択したファイルをエディタに表示する。(ダブルクリックではなく選択で表示するようにする。)

  1. プロジェクトを開いている状態で、projectの歯車をクリックする。
  2. Auto Scroll to Sourceにチェックがつく状態になるようにクリックする。

Spockのラベルをハイライトする

  1. Settings -> Plugins
  2. Browse Repositories
  3. 右上の検索窓で Spock を入力
  4. 一覧に Spock Framework Enhancements が出るので、選択して右クリック-> Download and Install
  5. Close
  6. Apply再起動(多分)

自動保存

keyword:save files automatically

  1. Settings -> Appearance & Behavior -> System Settings -> Synchronization
  2. 4つのチェックボックスを全てonにする。
  3. save files automatically if application is idle for の数字は「何秒間操作がなかったら自動保存するか？」
  4. Apply

保存したら自動でコンパイル

keyword:Make project automatically

  1. Settings -> Build, Execution, Deployment -> Compiler
  2. Make project automaticallyのチェックボックスをonにする。
  3. Apply

テストの起動高速化

keyword:EditConfiguration

  1. Run/Debug Configuration -> Defaults -> JUnit -> Before
  2. Makeを削除する。既にあるテスト実行系(All HogeProjectやHogeTestのようなもの)は削除する。
  3. 「Make, no error check」にを追加する。
  4. OK

Ctrl(Command) + マウスホイールでエディタの拡大縮小をする。

keyword:Change font size

  1. Setting -> Editor -> General -> Change font size(Zoom) with ... のチェックボックスをonにする。
  2. Apply

Web API The Good PartsはWeb API開発必携の書籍でした。 #apijp

はじめに

これはWeb API Advent Calendar 2014の二日目の記事です。 明日はid:nobusueさんです。

概要

これはWeb API The Good Partsという書籍の感想です。Web API開発に関わる人なら必ず読んでおいたほうがいいでしょう。ここ3年くらい「URI設計はどうすべきなのか」「APIバージョンはどうすべきなのか」「続きのデータをどのように取得すべきなのか」などについて綺麗にまとまっています。 最後にWEB API開発やレビューで使いたいチェックリストがあるのも素晴らしいです。

Web API: The Good Parts

Web API: The Good Parts

続きを読む

Spock1.0でBDDとレポートが進化している！ #gadvent

Groovy Spock Testing

はじめに

これはG* Advent Calendarの2日目の記事です。今日はSpockの新機能について書きます。明日はRyotaMurohoshi さんの「初心者でも】やろうぜGroovy!〜Web APIたたいたり、レスポンスの中身確認したり、データを保存したり〜編【今すぐ使える】」です。

概要

2014/12現在、最高のユニットテスティングフレームワークであるSpockの次のメジャーバージョンである1.0の機能を紹介します。 BDDを強力にすすめるためのアノテーションと、最高にクールなテストレポーターが実装されました。個人的には本当に本当に素晴らしいリリースです。 はやくこい！！！！！

続きを読む

Gradleを入門する方法から更に知る方法まで #gadvent

Groovy Gradle

はじめに

これはG* Advent Calendarの1日目の記事です。今日はGradleの勉強方法について書きます。明日はid:kyon_mm さんの「Spock1.0でBDDする」です。

概要

GradleというGroovy製のビルドツールが最近人気になってきていますが、なにを参考に勉強するのがよいのかをここで示します。社内で広めるときの参考にしていただければ幸いです。

続きを読む

テスト戦略パターンの作り方 #swtestadvent

Testing

はじめに

これはソフトウェアテストあどべんとかれんだー 2014 の一日目の記事です。

明日は id:nobkz さんの「Lispとテスト」になります。

概要

テスト計画やテスト戦略をつくるために、ある偏りを見ることによって分類し、テスト計画やテスト戦略策定を補助する方法について紹介します。これに新規性や素晴らしさはたいしてありませんが、私は多少なりとも有効に使えている気がします。 これは「テスト戦略自身」ではなくて「テスト戦略を見つける方法の1つ」と思ってください。

重要なこと

これはkyon_mmが言っていることであって、業界の標準的な何かとかではないです。

続きを読む

週刊ソフトウェアテスト 2014-48 #swtest_jp

Testing SWTestWeekly

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容は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

Testing

概要

テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。（実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基本はこの形であり、ここにある考え方が重要だと思っています。

つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。

僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。

まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。

構成のテンプレ

基本的に3段構成です。

冒頭の「BDD-Style」と言っているのは、「回避していることを保証する手段,デシジョンテーブルなどのパラメタライズ」の部分が該当します。

例示すると（悪い例かもしれないですが、イメージを伝えるために）

  • はてなユーザーが投稿後のブログを再編集できないリスク

    • 管理画面から投稿後のブログを再編集する

      利用ブラウザ 文字数 文字種 記法 結果
      Chrome 3x 2000 日本語 Markdown 編集できる
      IE 8 50000 ギリシャ文字 Markdown 編集できる
      IE 6 50000 アラビア文字 Markdown 編集できない

    • xxxxx

      xxx xxxx
      xxx aa
      yyy bb

使うツール

これを書くためにはツールは非依存ですが、テーブルを綺麗に表示できるものがあるといいでしょう。（ライブプレビューでもいいし、表を綺麗に書けるものでもいい 例えば、MarkdownやAsciidocでやるなら、Atomなんかがいいかもしれません。別にExcelでも構わないと思います。

ちなみに僕はOrg-Mode一択です。

それぞれの説明

簡単ですが、3つそれぞれについて説明します。

回避したいリスク

トップレベルにくるのは「このプロダクトにおいて何を回避しなければいけないか」というリスクを書きます。ゴール指向などではゴールを書くべきところなのですが、それは何かを生み出すという視点で有効です。僕のような何かを安全に保つという視座においては「何が起きてはいけないのか」というリスクで書くことが有効でした。

例えば、「登録ができる」だとそれしか確認しない事が多くて、 「登録できないリスク」と書かれていると逆のパターンである「登録できる」はすぐに思いつくので、「登録できる」「登録できないって事は起きない」の両方の視座で確認しやすかったのです。

また、このリスクは「単体テスト不可能になるリスク」とかも書けますし、「チームのコアデベロッパーが来月でいなくなる」とかも書けます。

リスクのフォーマットについてはリスクベースドテストやリスクマネジメントの本で書かれているようにいろいろあります。 なんとなく考えてみる分には「誰にどんなことが起きる」というイメージでまずはいいと思います。

回避していることを保証する手段

リスクには「それを回避する手段」がひも付きます。「それが起きないことを確認する方法」であればテストになります。

これはいわゆるテストスイート名やシナリオのタイトル、ユースケースのタイトルが該当します。どのような手段をとっているかがわかれば、別に２，３の単語でもいいとは思います。わかれば。

テストではない場合、つまり先の「チームのコアデベロッパーが来月でいなくなる」とかだと「コアデベロッパーはデベロッパーと代わる代わるペアプロする」とか「コアデベロッパーが参考にしている情報をWiki化する」とかでしょうか。

デシジョンテーブルなどのパラメタライズ

テストコードでいわゆるパラメタライズされているとか、テストの組み合わせ表とか、CucumberなどでのExamplesが相当しそうなところです。 この表でどこまでを書くかはチームやシナリオの書き方に依存します。ですが、個人的にはシナリオのステップをテーブルにはあまり書かないようにしています。 だいたい次の4つに分類できます。

  • 直接入力するもの
  • 環境として入力になるもの
  • 直接出力するもの
  • 環境に出力するもの

いいところ

例えば、POだったり顧客だったりPMだったりが「プロジェクト後半に爆発しないようにテストしたいな」とか「最低限リリースできるラインは保証されているのかな」とか「何が保証されているのか」といって見たいときにはだいたい「回避したいリスク」の一覧を見ると議論できました。

これは設計であって、実装ではないというところ

先にも書きましたが、工夫をすることでももっとよくなります。リスクはタグで分類するとか、テーブルに書く内容をライブラリ化するとか。

この方法論では、書くときの考え方の補助と議論しやすい見え方の補助を目的としています。なので、「テストを実行するときに面倒になるかもしれない」ということには対応していません。 例えば「リスクAとリスクBに対応している手段Xがあるから、手段Xでそれに紐づくパラメタライズをうまくマージすれば、テストを実行する時間が短くなる！」とかはよくある話しです。 この辺はテスト実行の最適化と僕は読んでいて、いわゆるJITコンパイルみたいなものだと思っています。 それを簡単にできるようなツールを開発するのが、いまの僕のちょっとした目標です。

リスクを思いつく方法

今まで出してきたバグやチームの状況を見て、推測するのがいいと思います。ですが、何か初めてのことがあると急にできないのもよくあると思います。

そんなあなたに本当に素晴らしいものがあって、鈴木三紀夫さんの「意地悪漢字」というやつです。いわゆるガイドワードなのですが、達成したい要求やプロダクトライフサイクルとこの意地悪漢字を組み合わせるといい感じにリスクがぼんぼん見つかります。ぜひご活用ください。

意地悪テストのブログ

意地悪テストのスライド

意地悪テストのスライド

推奨書籍

体系的ソフトウェアテスト入門

体系的ソフトウェアテスト入門

ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために

ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)

まとめ

ほとんどのテストはリスクベースドテストなんだから、テストの書き方からして、リスクベースドにするのが早いです。明確にしておかないと、なんのためのテストかわからない（わからなくなる）し、自信を持ってリリースするためには、自分だけがわかればいいっていうのは少ないほどうれしいはず。