2013年12月3日火曜日

[Spring Advent Calendar 2013 3日目] Thymesheetを使ってみる #spadc13

Spring Advent Calendar 2013 3日目です。
http://www.adventar.org/calendars/153

Thymesheetとは


Thymeleafのテンプレートからth属性を取り除いてCSSみたいに外だししようというものです。
https://github.com/connect-group/thymesheet


Thymeleafのおさらい


ThymesheetのREADMEに書いてあるので、おさらいがてら適当訳してみました。

Thymeleafは、Javaのライブラリーです。XHTML/HTML5を提供するWebはもちろんWebでない環境でもっともいい感じの、XML / XHTML / HTML5(他のフォーマットも拡張可能)のテンプレートエンジンです。
Spring MVCに組み込むためのモジュールが提供されており、Spring MVCのJSPテンプレートエンジンに対する、HTML5での完全な代替として使うことが出来ます。
Thymeleafのゴールは、エレガントでちゃんとした形式でのパワフルで自然なテンプレート、つまり静的なプロトタイプとして動作しブラウザで正しく表示できるテンプレートを作る方法を提供することです。

詳しくはこちらをご覧下さい。


Thymesheetの使い方


とっかかりレベルではREADMEみればOKって感じですが、一応サンプル作ってみました。
去年のAdvent Calendarで書いたものから修正しています。
https://bitbucket.org/twopack/spring-thymeleaf/branch/thymesheet
というわけで、さくさくと説明です。

Mavenの設定


pom.xmlに以下を追加します。
Thymesheetは、Thymeleafは2.1.0以降をサポートですのでdependencyのバージョンもチェック。
<dependency>
        <groupId>com.connect-group</groupId>
        <artifactId>thymesheet-spring3</artifactId>
        <version>2.1.0</version>
</dependency>

Spring Configration

コンテキストファイルでテンプレートエンジンの指定をThymesheetのものにします。
<beans:bean id="templateEngine" class="com.connect_group.thymesheet.spring3.SpringThymesheetTemplateEngine">
    <beans:property name="templateResolver" ref="templateResolver" />
</beans:bean>

テンプレート


今回のサンプルだとThymesheetを使う前はこんなです。
<P th:text="${serverTimeMessage}">  The time on the server is 2012/12/05 10:01:10 JST. </P>

これが、Thymesheetを使うとこんなになります。th属性はなくなりました。
<P>  The time on the server is 2012/12/05 10:01:10 JST. </P>

ただし、CSSのようにTSSファイル(Thymesheet Style Sheetかな?)をリンクします。
th属性で指定していた埋め込みの情報は、home.tssに追い出しています。
<link rel="thymesheet" href="resources/ts/home.tss"/>

TSSファイル


で、TSSファイルは以下です。とっかかり過ぎですねw
pタグは以下のth属性入れてね、ということです。
p { 
    th-text: "${serverTimeMessage}"
}

th:textがth-textになったぐらいです。わかりやすいですね。
CSSのようなイメージで以下のような表現が出来ます。READMEより拝借。
table > tbody > tr {
    th-each:"prod : ${allProducts}";
}


まとめ


Thymeleafのコンセプトを更に進めた感じのものだなと思います。
さらにHTMLとの分離が進んで、デザイナーさんとの分解点がはっきりすると思います。
ただ、実用するにはとっかかりだけじゃ不十分ですね、完全に。。。。
Standard Dialectとの対応など、いろいろ確認してみないとダメかな、という感じです。また来年w


明日はToshiaki Makiさんです!

2013年12月2日月曜日

テスト設計コンテスト’14 東京予選を見学してきた

11/30にテスト設計コンテスト’14 東京予選を見学してきました。
テスト設計コンテストは、NPO法人ASTERが行っているコンテストです。
翌日にシステムテスト自動化カンファレンス2013へ出るため東京へ前日入りの予定だったため、少し早めに行けば見れる!と早起きしました。(ついでではないw)

今年からテストベースがポットから自動販売機になりました。ポット時代もテスト設計コンテスト自体を生でみたことはなかったので、どんな感じなのかなと楽しみにしていきました。
とりあえず、会場についてAグループ、Bグループがあり、好きな方を見学できる、ということでBグループをみました。チーム名だけの情報だったので、理由は特にないですw

まだコンテスト中なので、ああだったこうだったは書けませんということになりますw(じゃあ、後で書くのかというと(ry)
Bグループは6チームでしたが、違いもあれば共通点もあり、アプローチもいろいろでした。
また、プレゼン資料だけでなく実際の成果物を見るのは初めてで、これも各チームいろいろで面白かったです。
Aグループは掲示と資料を眺めたぐらいでしたが、プレゼンも聞きたかったなあ、と思いました。

いろいろと見たり聞いたりしても、すぐに忘れる鳥頭で辛いですが、頭と心があったかい内に刷り込んでおかないとな、ということが多い半日でした。

あと地区予選の見学は、あと関西が残っていますね。お近くの方はぜひ!(まだ空いてるのかしら
http://aster.or.jp/business/contest/visitor.html

2013年10月1日火曜日

第33回勉強会(2013/09/28) Scala入学式 に参加してきました。 #nds33

9/28に新潟県長岡市でScala入学式に参加しました。 長岡IT開発者勉強会(NDS)の一環として開催されたハンズオン形式の勉強会です。 @neko_gata_sさんが講師をしてくれました。
資料はこちらで公開されています。
https://gist.github.com/Shinpeim/6740436


入学式

名前は聞いた事ありましたが触るのははじめてなScala。猫型さんがどんどんコードを書いてくれるのを追っかけていくのも精一杯!って感じでした。反面、追って書いているコードはとても分かりやすく簡潔だと思いました。Scalaもすごいですが、猫型先生の準備もすごいものがあるなあ、と。

型で作っていくというスタンス。型推論含め、コンパイラーによって型の問題を解消して値の問題に注目できるのは重要なメリットだと感じました。@trailrecOptionforが糖衣構文というのも非常に面白かったです。

モナドのあたりからは、もっと勉強せねば・・・・という感じでした。コンテナの中身を気にせず扱えるという説明は、今までもなんどか呼んだはずのモナドについての説明よりも大分すっと入ってくるものがありました。それを踏まえて、もう一度学ばねば。。。


LT&懇親会


相変わらず楽しいLT&懇親会でした!入学式でぐったり、、、だったのですが、大笑いでしたwwww
それに比べて自分のLTときたら、準備不足というかなんというか(ry
今後はGo/NoGoの判断をちゃんとしたいと思います。

懇親会でもいろいろな話がでますが、なかなか中身についていけないです;;話を聞いているだけでも、技術的にも話としても面白いんですが。
学生さんも多いので、テストの話だったりもいろいろしてみたいなあ、と思うのですが、引っ込み思案な私。。。
もっと興味をもってもらえるようなアウトプットをしないとなあ、と思いました。


というわけで


今回も非常に楽しい勉強会でした。

2013年9月10日火曜日

「ホワイトボックス単体テストにおけるペアテスティング」を読んで



上記のツイートを見て興味があったので読んでみました。
感想とか気づきのまとめ。

ペアテスティング

ペアプログラミング、と同じ感じだよな、と直感的にわかりますが、Googleさんに聞くとテスティング・ペアとかも出てきてます。
ペアでテスト設計したときの品質に与える影響、および方法、最も良いテスト品質を実現するには?というあたりが、このペーパーの内容です。
また、テストコードでのホワイトボックス単体テストを対象としています。他のテストレベルだったり、ブラックボックステストだったりすると、変わってくる部分、同じような結果になる部分がまた出てきそうだなと思いました。

テストカバレッジ

テストカバレッジが高いほど欠陥検出力が高い、という引用があります。
ここではホワイトボックス単体テストなのでコードカバレッジなのですが、テストカバレッジってコードカバレッジだけなんだっけ?と思いJSTQB用語集を見ると、coverage参照となっていて、
指定の網羅条件をテストスイートが実行した度合い。パーセンテージで表す。
となっていました。コードカバレッジは別であったので、限定的なものではないなと再確認。

ミューテーション解析

ミューテーション解析は、初めて聞いた言葉でした。テストコードの妥当性をどう担保するのか、というのはいつも説明が難しいところでした。
JavaやJavaScriptでもツールがあるようですし、Jenkinsのプラグインもあるようなので、今後使ってみたいなと思いました。

検証結果

検証の結果は予想を覆すもので面白いと感じました。特に、被験者がやりやすいと感じた「ペア1台」の方法が必ずしもテストコード品質につながっていない、というところです。
先日TDDBC Boot Camp長岡1.0でペアプロしたときに「やりやすさ」だったり「楽しい」ということ感じましたが、ペアテスィングでも同じ傾向がある気がします。
ただ、必ずしも品質につながっていない、というのはペアプロも同じで、こちらはいろいろな研究がなされていることが書かれています。
ツールとしてのペア作業も、条件下にあった形で行う事で生産性や品質に及ぼす影響が大きく違うんだと、なんか当たり前のようななんだけど、感心しました。
また、そういった研究が行われているのであれば、実際の作業に活かしていく事が重要だなあ・・・って、思いました。行われていることすら知らなかったという・・・ですが。


その他

こういうペーパーを読んでないのがバレバレですが、「妥当性の脅威」、「まとめと今後の展望」という章があり、気になったところに触れられていて、今後も気になりました。
あと、こういう研究でプラクティスへの裏付けがとられていく事は長期的にとても重要だし、すでに研究されていることを活かす事も必要だと改めて感じました。
SEMATもこういう部分をどうにかしていくものなんだと思ってます。

2013年9月2日月曜日

Niigata.rb #3 に参加してきました。 #niigatarb

新潟のRuby勉強会「Niigata.rb」に参加してきました。
RubyといえばRedmineのプラグインもやっている・・・というか、すがる思いで申し込みましたw
場所は、新潟市中央図書館「ほんぽーと」。私が8/31現在メイヤーな、行きつけの勉強スポットでした!ああいう会議するところもあるんですね。
@dictav さんをはじめ、みなさまありがとうございました。

例によってアジェンダに沿って振り返ります。

Niigata.rb について

るびこさんがマスコットな、Niigata.rbは第3回。
NDSでrubyな人たちが新潟にもいる!というところから、はじまったそうです。
今回は半数ぐらいが県外勢でまたびっくり。学生さんも多かったです。

テスト駆動開発は みんなの心の中にある (@kenchanさん)

TDDBC 長岡1.0に続き、くるものがあるお話でした。

  • 「複雑」には「Complicated」と「Complex」がある、「Complecated」な複雑は分解して一つずつ相手にするとテストが書きやすくなるというのは、なるほどなあと思いました。小さな問題にして、というのがもう少しクリアになった感じがしました。
  • 角谷さんのお話からとのことでしたが、コードにした事だけではなく、コードにしなかった事も含めてプログラミング、という話がありました。いろいろな方法から選択した理由、選択しなかった理由を捉えて、初めてコードを作っていると言えると思います。
  • TDDBC 長岡1.0 Reloadedは、自分も参加して言語は違えどやったお題だったので、なるほどなるほどと思いながら聴いていました。


初心者向けrubyの実行環境構築 (@kasacchifulさん)

Windows、Mac、Linuxでの実行環境構築のお話でした。
rbenvでのバージョン切り替えなども含んだ実践的な内容でした。
私はLinux環境でやってた頃はrvmでしたが、最近はrbenvでやってます。bundlerがあればrbenvかな、と思ってます。

エモい話かなにか(@upinetreeさん)

TideSDKというHTML5からRubyを扱いつつ、ネイティブアプリになるっていうフレームワーク?のお話でした。
艦コレ・・・なにこれ?の私には今ひとつ笑うタイミングが掴めませんでしたがw、簡単な指定で使える事、ネイティブアプリにできることは面白いと感じました。
艦これランチャーw

RubyMotion (@jewel_x12さん)

まさか、ここでつくる!?という艦コレな流れでもうwwwな、RubyMotionのお話でした。
実際にその場でライブコーディングされて、まあなにがってすごいですね、プレゼン。
テストコードの中でtapなんかもテストできるようで、面白いなと感じました。
スタイルシートみたいな感じでレイアウトができる、というのは、なんとなくVBのフォームのソースファイルを思い出しました。なんでだろ?

Redmineプラグインのテスト書いてもらえませんか?(@two_pack)

私の発表。書いてもらえませんよ、というのが答えのようですorz
RedmineのXLS Export Pluginをなんでいじっているか、という話と、誰かテスト書いてよ〜という他力本願な感じの内容でした。
真剣にxlsx exportに書き直す事を考えた方がいいのかな・・・

LT!(みなさま)

開始冒頭に「みなさんLTするってことで」的な話から「まだ発表していない人」的な流れで、みんなLTでしたww
みなさん興味深い話が多かったのですが、やはり@jewel_x12さんの「小指が痛いのがRubyのせい」っていう、3段論法的なLTが興味深いを通り越してましたw
@mihyaeru21さんのRubyのコーディング規約の話は、そういうの決まってるのか!確かにそうだ!と勉強になりました。
@bei_kanさんの「組み込みだからこそTDDで書く」という話は、とても心を打ちました。

まとめ

艦コレやらないとだめなのか、、、そうなのか、というNiigata.rbでした。アンテナ高くしていきたいと思いますw



2013年8月21日水曜日

SEMATカーネル勉強会 第2回に参加してきました! #sematj

ちょうど東京の用事と日程が重なりラッキー!ということで、SEMATカーネル勉強会へ参加してきました。
以下に資料もアップされています。
開発のよいやり方を形式値にして共有しよう! 〜パターンマイニングワークショップ〜
https://www.facebook.com/events/550763354987282/

パターンについての解説を聴き、ワークショップを時間オーバーの盛り上がりで行いました。
鷲崎さん、川口さんはじめ、みなさまありがとうございました。


パターンとは

パターンとは、
 特定の「文脈」で繰り返し起きる「問題」とその「解決」の記述
と定義されていました。
資料も見て頂くとして、ワークなどの中でポイントだなと思った点がいくつかありました。
  • 「文脈」「問題」「フォース」をどう切り出すのか?
  • 「フォース」は、理由に通じるところであったり、物事の仕組みであったりすることがある。手段や制約といったところであったりもする。
  • 「問題」は「解決」によって変化するものである。

パターン候補の簡易マイニング

資料にも書かれている、
 経験的なコツや暗黙知を、言語化して形式知にしたもの
ですが、暗黙知をどうやって形式知にして再利用可能にするか、ということへの一つの解として、パターン形式で書いてみるというのがあるんだなと思いました。

チームでのワークで「パズル的な要素」ということがでました。パターンの種になりそうなものを「パターンの形式」に当てはめていく中で、「文脈」から「結果」までのスジが通っているような、いないような、しっくり来ない状態がありました。そこをチームのメンバーの経験などで「文脈」や「問題」などを当てはめていくと、いい感じにピースがはまったんじゃない?というものがでてきました。
パターン形式で書く過程において共有を行う事で、メンバーが共通的に考えているような形式に集約されていくんだな、という印象でした。
また、他のチームは具体的なパターンから抽象度の高いパターンに変わっていたというところもあったり、他のパターンへの展開がありそうという話があったり、いろいろ面白かったです。


パターンを使いやすい形に改善していく

というお話が川口さんからありました。
GoFのデザパタのように、いいものをまとめたもの、がパターンと思っていたので、これは重要だなと思いました。
確かに、いろいろなことをカイゼン、カイゼン言っているのに、これはいいものだから!、と思考停止しちゃ駄目ですね。
特にいろいろなところで揉まれたパターンではなくて、チームの中で出してみたものなどには、この視点が欠けたら駄目だなと思います。


パターンランゲージ

パターンでコミュニケーションが取れる、つまり言語としてパターンを使える、という話だったと思います。
パターンの中の「解決」について、より具体化した新たなパターンであるとか、関連性の話や、抽象度の話もありました。


SEMATとパターンの関連

SEMATのアルファは状態を捉えるものであり、パターンは文脈(状態)の変化を表現したものとなるため、パターンの「文脈」「結果」をアルファで表現できるんじゃないか?という可能性がある。
って、最後にチラッとお話しされていたのと、頂いた資料をみてずらっと書いてみました。
アルファの置かれる状態が定義されていて、その状態変化がパターンで表現されることで、具体的なプラクティスになるということかなと思いました。あってるかな?



パターンに関しても、勉強するのと実際にチームで使い、パターン化して形式知にしてみたいなと思う勉強会でした。
次回も用事が絡む・・・なんて可能性は低いわけですが、引き続き注目していきたいなと思います。

最後に、「ブログ書くまでが勉強会」パターン、どうでしょうか?w
   文脈:勉強会に出席した。
   問題:スライドや資料だけでは後々思い出せない事が多い。
 フォース:・人間覚えていられる事には限度がある。
      ・重要な事は資料や本などでも調べる事ができる。
      ・メモはそのうちなくなる。
   解決:状況や感想も含めてブログに書く。
   結果:振り返りが出来て思い出すきっかけとして残る。

2013年7月6日土曜日

第32回勉強会(2013/07/06) Githubハンズオン に行ってきました! #nds32

第32回勉強会(2013/07/06) Githubハンズオンに行ってきました!
飲んでいるままで、感想ですw #思います多いww

(おもにデザイナー向け)やさしいGithubハンズオン

GithubのHands-onでした。
Windows版のSourceTreeがある、というところでしたが、非常に楽しめました。
My Page作るのがイマイチ分かってなかったので収穫でした。
今回は範囲外だよなあ、と思いながらRebaseの話があっても良かったかな、とか。

はじめてのnode.js

マージしてたら9割ぐらい聞いて(ry
ごめんなさいm(__)m

実録!勘違いが生んだ悲劇。〜えッ!?修正なんて聞いてないんだけど…。

リアル。まじリアル。
デザインの部分では要求定義って難しいなあ、と思います。
見える部分ということでお客様と合わせやすい、というよりも、出しても出しても見れば言いたい事がある、って感じ。
契約とかの話もでましたが、それことトリアージみたいなことが重要なとこだと思います。


高校生長岡ラーメン選手権の告知

チラっ、チラっ(-- #YAuth

Keynote+Gimpでアイコン作成

 興味深い内容でした。
アプリを作るときのアイコンとか、”アイコン 商用利用可 改変”、"Icon Createvie Commons"
とかググってる自分としては、フラットデザイン!www


Rでダイエット

Rといえば、統計、ぐらいのイメージでした。
実際、統計だったんですけど、食わず嫌いでした、すみません。
シンプルに情報の偏りを出すあのデモは、衝撃的でした。
言葉だけのビッグデータ、DWHではなく、アカデミックなところでのRは非常に落ちるものがありました。

VCS入門

お世話になってますw


NDSの(ry

プロジェクト・アンブレラ、まじリスペクトです。@civicさん。

懇親会

楽しかった!

2013年6月3日月曜日

自ら行動する技術者についての首都圏と地方における違い

JaSST'13 Tohoku の情報交換会で、そんな話題がありました。で、地方を盛り上げていくにはどうしたらいいのか?という感じ。
参加者からの質問がきっかけでパネルディスカッションのお題になったものでした。具体的な質問は失念orz
追記: @leecom さんから質問を教えてもらいました。ありがとうございます!「大都市圏ではない国内各地域のIT技術者・管理者がもっと元気に、より高い成果をあげるために自ら行動するようになるには何が必要でしょうか?」でした。

首都圏だからといって「自ら行動する技術者」の割合が多いわけではない、という意見。母数の大きさから大勢いるように見える。
そこから、母数の大きさから実数が多くなる事で、「なにかをしたい」というときの始めやすさ(勉強会するにも人数が集まるとか)はあるのではと。
また、同様の理由で、自発的な行動へとつながる「刺激」が多くなるのも首都圏の利点ではないかと。

組織内でも「刺激」の多寡がある。10ウン年同じ領域の同じ仕事をやり続けているベテランにとって、「刺激」の重要性は低く同じ方法で同じく仕事を回す事に重きが置かれる。
そのようなところに、例えば新人が配属されたとして「自ら行動する技術者」になる「刺激」を享受する機会は少なくなるのではないかと。
反面、地方ではやる気のある人で集まって勉強会などを行うから母数の多い首都圏と比べて、議論の密度は濃いのではないか?という話も。

JaSST'13 Tohokuでの議論を正しく捉えているか、が心もとないのですが、こんな話があったと記憶しています。


ここからは私の感じている事です。
新潟にいる私は、「地方」にいる技術者です。丸10年ほど開発に携わっています。
私は、「刺激」があるだけでは不十分で、「きっかけ」が必要ではないかと思います。
現在、「刺激」を受けることはインターネットの普及なんて大昔という勢いで、むしろ取捨スキルが必要なぐらい、刺激多すぎと言う状況ですw
しかし、その「刺激」を軸に自ら行動へとつなげる「きっかけ」は、また別のところにある気がします。

私の場合、ソフトウェアテストPRESSが初めての「刺激」だった気がします。そこからテストについて興味を持ち、自分の視野の中での「開発」について疑問を持ち、アジャイルといったテスト以外のことへも興味を持ちました。直交表、XDDP、USDM、マインドマップ、Redmine、Hudson(Jenkins)、xUnit、あげればきりがないです。
しかし、本とネット、自分の周りでの実践というところから外へ出ることはなかったです。頭にはなんども「新潟で勉強会があればいいのに。東京はいろいろあるよなあ」と思いながらもです。

私にとっての「きっかけ」は、JaSST'11 Niigataでした。あの、JaSSTが「新潟」で!、って有給とって行きました。スエットでw
それはもう「刺激」を受けました。なんか違うんですよね、本とかネットとかだけでは感じれないものがあると思います。
そして、@3rd_Violin さんに乗っかって、すわにいが始まりました。今も続いています。
最近はNDSにも参加したりしました。そして、あのTDDBCが、「長岡」1.0で!wも参加しました。

でも、まだWACATEは行った事無いし、Agile Japanも行った事無いし、JaSST Tokyoも行った事無いです。shinagawa.redmineも行った事無いです。
今でしょ!なのかもですが、やっぱり時間も金もかかります。
今の私には、「行きたい!だがしかし」ですが、昔の私には「新潟でもあればなあ。。いやない。」だったわけです。
そういうところが、「地方」にはあるんじゃないかなあ、と思うわけです。
私の内向きな性格が反映されているのでw、地方の人みんながこんな感じで考えてるわけではもちろんない(というか反例はいくらでもあるw)ですが、こんな封に考えてるのって私だけかな?


今回は第二の故郷wってことでJaSST'13 Tohoku行きましたが、やっぱり行ってよかったなあ、と思ってます。
新潟も、「NDS」に「すわにい」といろいろな「きっかけ」の場があるって、最近やっと気がつきました(ちゃんと検索しろ>俺w
「行きたい!だがしかし」の自分のためにも、少しでも新潟に「きっかけ」の場を作れるようにと、そこに集まった人たちと「刺激」を受け合う事ができたらいいなと、改めて考えた次第でした。




2013年6月2日日曜日

JaSST'13 Tohokuに参加してきました! #jassttohoku

JaSST'13 Tohoku(以降JaSST)に参加してきました!
新潟以外のJaSSTは初参加。コミュ症なんでドキドキでしたが、すごく楽しい一日になりました。
@nnasaki さんが、Togetterで当日のつぶやきをまとめてくださっています。
というわけで、感想をつらつら。

午前の勉強会

JaSSTは午後からで、午前中は東北デベロッパーズコミュニティ(TDC)の「ソフトウェアテスト勉強会(番外編)~レッツ!テスト!~」に参加しました。
@kitanosirokumaさんが、講師としてお話しされながら、実際に使われているWebサービスに対して、チームで探索的なテストを行うというワーク形式のものでした。実際に動かしてバグを見る、というのは非常に面白いし、JaSSTの中でも触れられていた、「達成感」を感じる事ができ、いいお題だなあ、と思いました。
特にポイントだと思ったのは以下。

  • 意図をもってバグを狙う。それによって、見つかっても見つからなくても次につながる。
  • できるだけ情報源を使い切る。

情報源としてソースもあったので、私ソースみたいです!って、ソースから重大バグ探しをしてました。
Railsわかんねww、って感じの時点で切り返した方が良かったかな、と後で思ったりもしました。

最後にチームごとに一番重大だと考えたものを発表して、その中でも重大だと参加者が考えたチームに送られる「ネモリン賞」を頂きました!
そして、おいしいお菓子を頂きました!やったね!w

午後のJaSST

そしてJaSSTです!とりあえず、タイムテーブルはこちら

基調講演:「開発を楽しくするソフトウェアテスト」 @yumotsuyoさん

命題的な講演でした。テストに限らずソフトウェア開発の現場では、楽しく開発をするということが「目指す」になっている現状があると思います。
まあ、仕事だから楽しい事もあれば辛い事もあるのは当たり前なんですが、そこで思考停止してたらいかんですよね。
日頃から考えている事に対しての一つの視点という意味で、非常に楽しく考えながら聞きました。
特にポイントだと思ったのは以下。#書ききれない。。。

  • 出来事 -> 考え -> 気分 という思考の流れ。
  • 「楽しい」の意味、仕掛け。達成感。ゲーミフィケーション。
  • 全員の立場でのソフトウェアテストに向き合う。
  • テスト対象に対して、ユーザーの視点から論理的に分解していく。
  • やるってきめたらやる!

事例発表1:「ソフトウェアテストの7原則とゲンバで向き合う」 @snskさん

もう、ほんと、ね!って、感じでした。
「ソフトウェアテストの7原則」について、経営層・マネージャが知るべき事、現場の技術で達成できる事に分け、それぞれへの対策を示されていました。私、JSTQB FL持っているのに、7原則知らない時点で終わって(ry

  • 自然の法則!
  • 品質モデルからトレーサビリティが取れるテストを考える。十分性の条件。品質モデルを決めることが重要。
  • 初期からチームを組織しなくても、テストリーダーが一人だけでも最初から開発チームに加わるべき。もっとテストに関して開発の計画段階から考えるプロセスが必要だと感じました。

事例発表2:「SeleniumとJenkinsではじめる受入テストの自動化」 @masanobuimaiさん

最近Web系に手をつけているのでSelenium気になって、実はこれを聞きにきた、という感じでした。
動画でのデモもあり、イメージが掴みやすかったです。

  • SeleniumIDEでアサーションまで入れれる!これは知らなかった!
  • Seleniumのクセがあるとのこと。万能でないってのは、どんなツールでもそうですよね。
  • 意外にJenkins、Seleniumを知らない参加者が多かった。これは本当に意外だった。
  • JenkinsのSlaveもこんなに簡単に作れるのか、という感じ。
  • というわけで、やるしか!

ライトニングトークス

それぞれ味のある面白いトークでした。

  • このLTが黒歴史wwww

テスティングライブ:「テスティングライブ~新人K 初めてのテスト~」

非常に斬新な企画でした。もう、なんというか、面白かったですwww
とても言葉では表せないですが、とりあえず演技には見えなかったwww

情報交換会:「ゆるパネ」

JaSSTの申し込みアンケートの質問にパネリストが答えるという形で進行・・・なんだけど、ゆるい?ゆるいの?www
とてもアツい感じでした。

懇親会

なかなか自分から口を開くのが苦手なんですが、大学の後輩の @hinac0 と酒が入ると少しは口が回るようになる体質のおかげでw、いろいろお話しできて楽しかったです。
@hinac0 からもSeleniumの話を聞きたかったので、自動化の話ができてよかったです。
バスの時間で帰らないとだめだったのが、残念。。。。

というわけで

ほんと楽しかったです!
みなさまお疲れさまでした!




2013年5月25日土曜日

JavaScript+QUnitでTDDしてみた。

TDD Boot Camp 行ったので復習を兼ねて JavaScript で TDD してみました
なんでC言語でやら(ry

お題

JQueryを使ってFizzBuzz、にしました。
ちなみに、JavaScriptはわかりません。Google先生に誰が知ってるか聞きました。
JQueryもわかりません。Google先生に誰が知ってるか聞きました。
いろいろ調べ過ぎてどこみたかも不明ですが、ツイート参照ということで、先人に感謝。

準備

環境は QUnit + Eclipse + JSDT Plugin という感じでやりました。
jsTestDriver を使おうとしたのですが、うまく行かず、テストの実行自体はブラウザです。
JQueryはダウンロードしてきて、main/js/external/ というフォルダを作っていれました。

QUnitの準備

QUnit は npm で入れました。package.jsonを作ったので、PJルートで以下のコマンドでインストールされます。
/node_modules にインストールされるので、そこのパスをみるように実装しています。
$ npm install

テスト実装のHTMLは /test/html/runner.html です。
基本的にはオフィシャルをみれば分かる感じでしたが、 #qunit-fixture のdivタグの中に、評価条件のHTMLを入れるというのがポイントでした。
テストコードの setup() でタグを置き換えても良さそうでしたが、今回は複雑ではないので固定にして、プロダクトコードの body と一緒にしています。
ちなみに、 #qunit-fixture の divタグ内は、テストケースごとに初期化されます。

この状態でブラウザで runner.html を開いておいて随時テストを実行します。

TDDをやった経過

TODOリストも随時コミットすれば良かった・・・と思ったのは後の祭り。
でも、最終的なものをコミットしています。
Red -> Green -> Refactoring の流れのうち、Red -> Green でコミット、 Refactoring でコミットを基本にして、 Red -> Green -> Refactoring でコミット、大きなリファクタリングでのコミットと、ログで経過が追えるようにしました。
仮実装、三角測量といった TDD Boot Camp で体験した事を意識してやりました。

気になるポイント

  • ”Refactors that Expected exchanges Result.” のコミットで修正したのですが、 QUnit では (期待値, 実測値) ではなく (実測値, 期待値) なんですね。
    ちゃんと調べてやらないから(ry
  • そもそも大きくないコード量なのですが、”Refactors selecting colors.”のコミットは、if文がちょっと・・・でリファクタリングしたのですが、なんかもっといい方法がありそうな?
  • HTMLからのイベント(onClick)、表示を扱うViewModel(fizzbuzz_vm.js)と、fizzbuzzのロジックを扱うModel(fizzbuzz.js)に分けて作りはじめました(最後までそうなのですが)。MVVMって言葉に憧れてwこういう名前にしただけですが、イメージ合ってるのかしら?
  • モックを使う必要は今回なかったですが、ModelとVM分けたのでテストを書きやすくなった、というかテストすべき範囲がはっきりした感じはしました。
    Modelの振る舞いという視点と、操作とそれをきっかけにした表示更新という視点で分けやすくなりました。 #当たり前?

残課題

  • 折角の JavaScript なんで BitBucket 上で動かしてみれるようにしてみたい、、、、と index.html を入れてみたんだけども動かず。
  • jsTestDriver がイマイチうまく動かず。Phantom.js での CI 以外にも各ブラウザでテスト実行できるのは良さそうなので、もうちょっと調べてみたいです。

最後に

やっぱ、TDDいいです。楽しい。TDD Boot Campバンザイw

2013年5月19日日曜日

TDD Boot Camp 長岡 1.0に参加してきました! #tddbc

TDD Boot Camp 長岡 1.0に参加してきました!
ずっと参加してみたかったTDDBCが長岡で!、ということで飛びつきました。
長岡での開催にアクションして頂いた @masaru_b_cl さん、講師の @t_wada、TAのみなさま、協賛のNDSのみなさま、本当にありがとうございました。

時系列で心に留まったところをメモをみながらピックアップします。

自己紹介

  • みなさんの自己紹介。県外から参加されている方もいました。
  • 学生さんから普段はPMをされている方まで、幅広い人が集まっている印象でした。

Keynote

  • @t_wada さんのキーノートからスタート。
  • 「現代ソフトウェア開発の三本柱」として、VCS、テスティング、自動化のお話。関連して頭に浮かんだのが、VCS、ITS、CIという三種の神器でした。ITSの位置づけも重要だけど、3脚椅子のメタファーを4脚椅子にすると足を一つ削っても結構安定するから駄目だな、って思いましたw
  • 「テスト」という言葉の捉え方について。Developer Testing, Customer Testing, QA Testingという分類で説明され、TDDの文脈ではDeveloper Testingが該当。テストに関する用語の標準化という意味ではISTQBの用語集もあります、ってツイートしました。
  • TDDのこころもち、というお話。なるほどなあ、という感じ。サイクルが1分 -> 1分 -> 2分というのは衝撃的でした。
  • TDDの真の目的は健康。健康なコードと健康なチーム。健康第一ですよね!

    ペアプログラミングによるTDDデモ&写経タイム

    • 写経タイムだ!と思ったのに、CppUTestでやろうと思ったらEclipseではまってついていけずorz
    • ペアとは終始話をしながらやっているなという印象。沈黙がない感じでした。
    • アサートファースト。テストケースの後ろから書いていくことで、テストも見やすくなるとのこと。
    • 仮実装、三角測量といった方法。なるほどなあ、という感じ。


    ペアプログラミングによるTDDハンズオン

    • @bei_kan さんとC言語+CppUTestでハンズオンしました。ありがとうございました!>べいかんさん
    • ペアプロではキー配列とかショートカットとかが普段と違うと大変だと痛感。私のPC(MBA)でやらせてもらったので、私はよかったですが、ペアのべいかんさんには不自由をおかけしちゃいました。
    • そして、久々すぎるC言語ですっかり忘れている・・・・からのでしたorz
    • 初のペアプロでしたが、いわゆるペアプロの効用といわれていることを実感できた感じがしました。そして、とても楽しいけど疲れる(^^;
    • リファクタリングするとコードが本当にきれいになっていくし、振る舞いがかわればきっちりRedになるし、もうなんていうか、楽しい! 大々的にリファクタリングする場面があったのですが、あのときテストが通ったのはキターーーー!でしたw
    • TODOリスト大切ですね。道しるべになって達成感が生まれました。

    レビュータイム

    • 各言語のペアからLT形式で感想とコードの発表。
    • テストケースの粒度がやはり言語、ペアによって差があるなと思いました。クロージングでもでたテスト技法のあたりだったり、テスト設計だったりをこころにとめておくと、変更に強いテストコードになるんじゃないかな、と思いました。

    クロージングセッション

    • 最後に @t_wada さんのクロージング
    • TDDの効果に関する数字的なところの紹介。
    • TDDによる欠陥密度の低下と実装時間の増加、開発時間が短くなっているというアンケート結果、デバッグの仮説検証プロセスを短くすることで工数が見込みにくい部分を少なくできる、などなど、なるほどなるほどでした。
    • 「こんなとき」の足がかりになる本の紹介。技法ドリルの本が出てきたときには、よし!と思いましたw
    • グリーンバンドの話。そう、プロフェッショナルですもん!


    その他

    • 懇親会には残念ながら参加できず。。。
    • グリーンバンドゲット!
    • やっぱり、コード書くって楽しい!

    という感じで、時間をみてお題をもう一度TDDで書いてみたいなあ・・・と思ってます。

    2013年5月18日土曜日

    Redmine XLS Export Plugin で Iconv::InvalidEncoding

    掲題のエラーになる、とのチケットが発行されました。
    BitNami Redmine Stack使われてますねえ。
    https://github.com/two-pack/redmine_xls_export/issues/23

    エクスポート時にspreadsheet内でIconvを呼び出しているところが該当箇所でした。
    UTF-8 から UTF-16LE の変換で失敗しています。
    Iconv::InvalidEncoding (invalid encoding ("UTF-16LE//TRANSLIT//IGNORE", "UTF-8")):
    spreadsheet (0.8.5) lib/spreadsheet/encodings.rb:38:in initialize'
    

    spreadsheetを調べてみるとruby 1.8と1.9で処理が分かれていました。
    1.9.x以上はString#encodeメソッドなどで変換してます。
    1.8.x以下は、Iconvを使って変換しています。
    今回問題が起きている環境はRuby 1.8.7でした。

    そもそもUTF-8でないデータが渡ってきてるのでは??と思いBitNami Redmineでの文字化け情報がないかなあ、、、と調べたら以下がありました。
    これによると、データベースはずいぶん前からUTF-8になっているようなので、大丈夫そうです。。。
    ■[redmine]bitnami::redmine で文字化けしなくなった!

    他を調べると以下のようなものもありました。環境問題っぽいのでそれで終わりにしました、、、なのか?w
    http://stackoverflow.com/questions/4965796/convert-utf-8-to-unicode-in-ruby

    2013年4月25日木曜日

    コードカバレッジにテストケース分も含むべきか?

    JaCoCO Maven Pluginでテストケースのカバレッジもとるの後、パッチを書いてpull requestを出しました。
    結論から言うと、一旦取り下げました。

    作ったパッチは、

    • mavenでJUnitのテストを実行した際に、テストのオブジェクトファイルができる場所(例えばtest-classes)をカバレッジ対象に加える

    というものです。前のブログで書いたような結果が得られます。
    しかし、以下のような点からデフォルトで含むのはどうなの?という意見がでました。

    1. あまりコードカバレッジにテストケース分を含むのは一般的じゃないんじゃない?
    2. だって、プロダクションコードのカバレッジと混ざって、ほんとのカバレッジが見づらくなるじゃん?
    3. EclipseのプラグインであるEclEMMAの場合は、テストコードの場所に決まりが無いから全部にしてるんだよね。
      #やばい、closeした時、誤訳してたと書いてて気づいた。。。
    4. 少なくともデフォルトは出さない方がいいよね。

    1は、普通フォルダだったりパッケージだったりを分けるんじゃないかな?と思います。
    カバレッジもそれぞれで分けて表示できると思うので、問題にならないんじゃないかな、と。
    2は、1のように分けていなければ、その通りだと思います。

    そもそもパッチを書いた理由は、テストケースのカバレッジも見えるべきじゃない?ということでした。
    他の意見としても、デフォルトは出さずオプションで選択できるようにしたらいいんじゃない?というものでした。
    Maven pluginの形をとるという事は、いろんなケースがありえる前提に立って2のようなことを避ける方に倒すべきかな、と考え直し取り下げました。
    オプション形式に書き直そうと思ってます。

    で、JaCoCo Maven Pluginではパッケージで階層化されたレポート出力になるので、混ざらないように書いておくのが良いのかな?
    ベストプラクティスとかあるんですかね?

    2013年4月21日日曜日

    JaCoCO Maven Pluginでテストケースのカバレッジもとる

    JaCoCoというJavaのカバレッジライブラリを調べています。

    テストコードを書いて確認。EclipseのプラグインであるEclEMMAは内部でJaCoCoを使っています。
    とりあえずオールグリーンです。


    カバレッジが100%ではないですが、ここでは問題にしません。#ほんとはこれを調べてたんですが。
    ちゃんとテストコードのカバレッジもとれてます。


    次にMaven Pluginです。使ったバージョンは、0.6.3-SNAPSHOT。
    HTML、XML、CSVでレポートが出力されます。HTMLのレポートを開いたものです。テストコードのカバレッジが無いです。


    調べていくと、prepare-agentゴールでデータを作って、reportゴールでレポート化しています。
    prepare-agentゴールでは、JavaAgentを使ってデータを取っています。この辺はたぶんEclEMMAも一緒のはず。
    実際、HTMLレポートのSessionsのリンクをたどると、実行時のデータがすべて出てます。


    ここを見るとちゃんとテストコードも通ってます。ということは、データは取れているけどレポートできてない、EclEMMAで出てるという事は、Maven Pluginで出ていないですね。


    で、いろいろとpomをいじってみましたが駄目だったのでソースをみることに。
    https://github.com/two-pack/jacoco/blob/master/jacoco-maven-plugin/src/org/jacoco/maven/BundleCreator.java
     public IBundleCoverage createBundle(
       final ExecutionDataStore executionDataStore) throws IOException {
      final CoverageBuilder builder = new CoverageBuilder();
      final Analyzer analyzer = new Analyzer(executionDataStore, builder);
      final File classesDir = new File(this.project.getBuild()
        .getOutputDirectory());
    
      @SuppressWarnings("unchecked")
      final List<File> filesToAnalyze = FileUtils.getFiles(classesDir,
        fileFilter.getIncludes(), fileFilter.getExcludes());
    
      for (final File file : filesToAnalyze) {
       analyzer.analyzeAll(file);
      }
    
      return builder.getBundle(this.project.getName());
     }
    

    classesDirがgetOutputDirectory()になってます。target/classesだけみたい。。。
    ということは、target/test-classesも入れれば良いってことかな?
     @SuppressWarnings("unchecked")
     public IBundleCoverage createBundle(
       final ExecutionDataStore executionDataStore) throws IOException {
      final CoverageBuilder builder = new CoverageBuilder();
      final Analyzer analyzer = new Analyzer(executionDataStore, builder);
      final File classesDir = new File(this.project.getBuild()
        .getOutputDirectory());
      final File testClassesDir = new File(this.project.getBuild()
        .getTestOutputDirectory());
    
      final List filesToAnalyze = FileUtils.getFiles(classesDir,
        fileFilter.getIncludes(), fileFilter.getExcludes());
      filesToAnalyze.addAll(FileUtils.getFiles(testClassesDir,
        fileFilter.getIncludes(), fileFilter.getExcludes()));
    
      for (final File file : filesToAnalyze) {
       analyzer.analyzeAll(file);
      }
    
      return builder.getBundle(this.project.getName());
     }
    

    ということでビルドして入れてレポート出した見た結果がこちら。ちゃんと出ました。


    テストコードのカバレッジってデフォルトで出た方が、テストが思いがけず通ってない場合が見れていいと思うんですが、どうですかね?
    フラグとテスト作ってリクエストしてみようかな。

    2013年4月9日火曜日

    長岡 IT開発者 勉強会(NDS) 第31回勉強会に参加しました。 #nds31

    長岡 IT開発者 勉強会(NDS) 第31回勉強会に参加しました。
    NDS自体初めての参加でしたが、とても楽しむ事ができました。
    http://nagaoka.techtalk.jp/no31

    テーマは「はじめての~」。初心者向けのテーマでなにか話して!ということでした。
    以下、発表のまとめというよりも、気になったところの備忘録。発表順です。
    スライドなど最新は上のページでまとまってます。

    第31回勉強会 アジェンダ(@civicさん)

    はじめてNDSに参加されたかたも多かったとの事で、@civicさんからNDSについての説明がありました。
    誰にでも発表の場を提供します!、というのは、新潟において貴重な場ではないかと感じました。

    はじめてのChrome App (@civicさん)

    Chromeアプリでデバイスなどの低いレイヤーのAPIもあるということでした。
    実際にUDPでメッセージを受けるデモをされてました。
    bluetoothとかもあったので、今後何かやっていたいと思いました。

    はじめてのmac用ビューアアプリ(@piras4さん)

    最近はMBAべったりなのにXCode使ってみたこともない、、、、という私にはぴったりでした。
    こんな風にするんだ、という感じでした。

    はじめてのテスト技法 (@two_pack)

    NDSの実施ポリシーが非常にいいね!と思い、NDS初参加でしたが私も発表してきました。
    http://nagaoka.techtalk.jp/Home
    中身はテスト技法の話はしておらずw、「ソフトウェアテスト」に触れるきっかけになれればいいなということで書きました。
    初めてSlideshareにも載せてみました。100viewいくとメールが来るんですねw

    はじめてのPerl(のモダン?な環境構築) (@hajyajoさん)

    Perlの開発環境についてでした。システムPerlという言葉を初めて知りましたorz
    開発環境用にバージョンを入れ替えるとか、ライブラリを指定のところに入れるとか、rvmみたいのか、と聞いていました。
    IDEもあるようですw

    はじめてのWindowsストアアプリ (@AILightさん)

    生MVPだよ!生Surfaceだよ!と思ってたのは秘密ですw
    ちょうど前の日に8のアプリを少し見たのもあって、非常に興味深かったです。
    8がないのが痛いですが、やってみたいなあ、と思いました。

    新潟スピリチュアル専科・または恋は言ってみりゃアウトプット (@neko_gata_sさん)

    いきなりCoooolな音楽から始まりました!
    新人教育で使いたいと思うし、うんうんとうなる、非常に良い話でした。楽しいって大事ですよね!
    waveずたずたは原曲が気になるレベルのアウトプットでした。
    プロセスさんには、ぜひpullRequestできるように読み込んでみたいです。

    はじめてのメタプログラミング (@neko_gata_sさん)

    メタな話でした。
    ちょうどRubyGemのrequireでそんなのみたところだったので、Perlだとあんな感じでできるのか、と聞いてました。

    わたしのRubyとの出会い (@kasacchifulさん)

    @kasacchifulさんは、すわにいでもご一緒している方なんですが、ruby長いんだなあ、と今更w
    Redmineのプラグインみてるのに、しっかり勉強してない、ってところを痛感したので、お勧めの本を読もうと思います。

    懇親会

    開発者で飲むってこういうのだよね、って感じですごく楽しかったです。
    ただ、ちょっと楽しみ過ぎたのが玉にきずでした。。。 #おかげでこれ書くのも遅くなってる。。。

    その他
    そして、名刺のgithubとbitbucketのURLが逆になっているという@neko_gata_sさんからの指摘に愕然としましたorz
    テストの話しておいて、このバグ。。。。

    2013年3月30日土曜日

    Redmine XLS Export PluginのRedmine 2.3.0対応

    XLS Export PluginのRedmine 2.3.0対応を行って0.2.1.t2にバージョンをあげました。
    https://github.com/two-pack/redmine_xls_export/tree/0.2.1.t2


    2.3.0での問題

    Redmineのapplication.cssが変わったため、管理者のプラグイン設定画面の表示が崩れていました。以下のチケットです。
    https://github.com/two-pack/redmine_xls_export/issues/19


    対処

    XLS Export Pluginは、作者のVitaly Klimovが同じく作成しているPlugin views revisionsを使ってRedmineのバージョン違いに対応しているため、今回も使ってみました。
    revフォルダの下にバージョンごとのファイルを作成すれば、インストール手順にある以下のRakeコマンドでRedmineのバージョンに合わせたファイルが使われます。
    $ rake redmine:plugins:process_version_change RAILS_ENV=production
    

    実際に行った対応は、このコミットで概略は以下の通りです。

    1. もともとのCSSである assets/stylesheets/xls_export.cssrev/assets/stylesheets/1.3.0-xls_export.css として移動。
    2. redmine_xls_export/rev/assets/stylesheets/2.3.0-xls_export.cssとして、Redmine 2.3.0用のCSSを作成。


    Redmine XLS Export Pluginの競合

    年頭にXLS Export Pluginのフォーラムで、チケットリストのQUICKリンクでzipファイルが正しく作られないという問題が報告されてました。

    調べてみると拡張子はzipなんだけど、実際にはxlsファイルだと判明。。。
    ソースを追っていくと以下の部分が該当箇所。
    export_nameには出力するファイル名と拡張子が入っています。issues_xlsはxlsファイルの内容で、zipの場合はこの後にrubyzipを使ってzipファイルにする処理があります。
    export_name[1] == 'zip'trueだけど、Zip::ZipOutputStream::write_bufferfalseの場合は、現象が起きるルートになります。
    issues_xls=issues_to_xls2(@issues, @project, @query, @settings)
        return issues_xls unless export_name[1] == 'zip' && defined?(Zip::ZipOutputStream::write_buffer)


    Zip::ZipOutputStream::write_bufferがない?

    rubyzipをrequireしているのにZip::ZipOutputStream::write_bufferがないってどういうこと?
    いろいろ調べていくと、Redmine DMSF Pluginが入っている場合に起きる事が判明。
    DMSF Pluginではrubyzipではなくzipbundlerでインストールしていました

    これによってrubyzipzipの両方がgemに入っている状態になります。
    どちらのプラグインも、以下のようにしてロードしています。
    require 'zip/zip'
    

    しかし、ロードパスの優先順位の関係でzipのほうがrubyzipよりも先に見つかるので、zipがrequireされます。
    そして、zipにはZip::ZipOutputStream::write_bufferが含まれていない、というのが原因でした。


    調査と対応

    XLS Export Pluginだけrubyzipを呼び出す方法とかないのかな?と、いろいろ調べてみたんですが分からず。
    rubyzipzipでdiffをとるとrubyzipのほうが包含しているようにみえたので、DMSF Pluginにrubyzip使ってもらえないかとPull-Requestしたら取り込んでもらえました。
    いっけんらくちゃくw

    #でも、そもそもZip::ZipOutputStream::write_bufferが無い場合にzip拡張子で出すという処理自体にも問題があると思うんですが。。。


    2013年3月24日日曜日

    JaSST'13 Niigataに参加してきました。

    2013/3/15に行われたJaSST'13 Niigataに参加してきました。
    今回は参加している勉強会「すわにい」の成果発表で登壇もしてきました。
    http://www.jasst.jp/symposium/jasst13niigata.html

    遅くなりましたが、気づきのあった事を書いてみます。
    ちゃんと内容理解できているか不安ですが。。。

    2013/4/10追記
    JaSSTのサイトにレポートがアップされました。スライドも見れます!
    http://www.jasst.jp/symposium/jasst13niigata/report.html

    基調講演
    「仕様ベースのソフトウェアテストを上手に進めるには
    ~明文化された要求仕様に対して漏れなくテストするための観点とは~」
    大西 建児さん

    仕様ベースのテストで何がむずかしいか、を4つの視点からむずかしさを説明されました。「むずかしさ」を整理するポイントを教えて頂けたと感じました。

    • ISTQBとは、というお話から。JSTQBのFoundation Levelを持っているはずの私ですが、成果発表の資料の用語からしてISTQBの用語に沿ってない・・・・と焦りました(ーー; もう一度シラバスを読もうと思います。
    • 自然言語による仕様記述でのあいまいさ。言葉を尽くして表現しなくてはならない。
    • 情報が絡み合ってごちゃごちゃしている状態。情報の整理が必要。
    • 複数のテストアイテムに対するテスト条件がいっぱいあり整理できない。
    • テスト条件とは、テストアイテムについてテストしなくてはならないこと。
    • 現在ではユースケースが膨大になるのが当たり前。どこまで保証するか範囲を決めることになる。
    • 製品、サービスの領域に関する知識は持っている必要がある。すべてを知っている必要があるということではなく、テスト対象が目的を果たせるか確認するのに必要なことは知っている必要がある。

    演習付きチュートリアル
    「マインドマップを用いたテスト要求分析・設計エクササイズ」
    鈴木 三紀夫さん

    テスト分析、設計でマインドマップを活用する、、、の前にテストケースに至までのテストプロセスのお話がありました。また、講演自体をマインドマップで各自書いていく、という流れ。私は結局A3で2枚ぶんになりました。

    • テストレベルごとにテストプロセスがあり、そのプロセスがフェーズ(時間の流れ)の中に当てはまっていく。これははじめて絵をみてなるほどと思いました。
    • 視座、視野、視点を意識してテスト観点を列挙していく。
    • 演習ではある機能に対してどんなテストが必要かをマインドマップで考えるというものでした。
    • 情報交換会や打ち上げなどで他の人のものを聞いてみると、自分で気づかなかったところも多々あり。なるほどなあ、というところも多く、視野が狭いなあと感じました。

    事例発表
    「新潟ソフトウェア開発勉強会『すわにい』の活動」
    すわにい

    すわにいで行ったテスト設計の成果発表を行いました。あとは、参加者募集!の宣伝w
    独自のテスト設計アプローチとして、利用者の安全をキーワードにアバター抽出とそれぞれに対するフローからポイントを洗い出す、というものでした。
    ご講評として、大きく2点コメントを頂きました。アプローチ、手法という観点ではなるほどなあ、と感じ入りました。

    • アプローチでの結果の再現性。同じ事をやったときに同じ結果につながるのか?ということ。アバターの抽出、フローの作成ともに「気づき」を促すもので、再現性があるかというと乏しいと確かに感じました。
    • フローである事の意義。前述の通り「気づき」を促すものとしてフローではなくマインドマップなども同じような効果が得られそうです。


    去年は参加できずのJaSST Niigataでしたが、一昨年同様多くの気づきを得ることができました。
    やはり本やネットだけでなく、実際に聞いて話してみると感じる事があります。それを実際の開発にもつなげていけたらと思いました。
    #オフィシャルのレポートが上がったらリンクを追記しようと思います。

    2013年3月7日木曜日

    Redmine 2.2.x でのXLS Export Pluginの動作確認

    ぐぐったら、動いている風な記載がありました。


    なんで、自分の追加したところの確認をしました。
    特に問題なく動いていました。

    環境


    • OS
      Mac OS X 10.7.5
    • 環境
      Redmine version 2.2.3.stable
      Ruby version 1.8.7 (universal-darwin11.0)
      Rails version 3.2.12
      Environment production
      Database adapter SQLite
    • Redmine plugins
      redmine_plugin_views_revisions 0.0.1
      redmine_xls_export 0.2.1.t1

    2013年1月9日水曜日

    [Spring] Autowiredアノテーションを使っているクラスのユニットテスト

    ちょっと確認のために試してみました。ソースは以下。
    https://bitbucket.org/twopack/jsonrest/commits/e5353d883dffe31f99948a977b938c69
    試したかったのは、 @Autowired でインジェクションしているクラスをJUnitで動かすにはどうするかです。

    上記のソースで autoPerson@Autowired してます。
    決めうちでアクセスすると、autoPerson にアクセスして Micheal を返すようにしています。

    テスト側で対応を行わない場合、テストを実行すると autoPersonNullPointerException になります。JUnitで実行時には、 @Autowired でインジェクションが行われていないことが原因です。
    対策のポイントは、以下のサイトを参照しました。



    @Autowiredアノテーションを有効にする

    1つ目のポイントは、JUnitのテストに @RunWith(SpringJUnit4ClassRunner.class)@ContextConfiguration を記載して、 Spring の TestRunner で動くようにします。
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration
    public class HomeControllerTest {
    ....
    }
    

    @ContextConfiguration を記載すると、クラスパス上の テストクラス名-context.xml を読み込んで設定します。
    この中で、インジェクションするbeanを設定します。
    <beans:beans xmlns="http://www.springframework.org/schema/mvc"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:beans="http://www.springframework.org/schema/beans"
      xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
      <beans:bean name="Person" class="jp.gr.java_conf.twopack.sample.jsonrest.Person"></beans:bean>
      </beans:beans>
    

    テスト対象クラスのインスタンス化

    1つ目のポイントでOK・・・かと思いきや、状況は変わりませんでした。
    以下のようにアプリケーションコンテキストのメソッドを使ってテスト対象をインスタンス化する必要がありました。
    @Autowired
    ApplicationContext ctx;
     
    HomeController sut;
      
    @Before
    public void setup() {
      sut = ctx.getAutowireCapableBeanFactory().createBean(HomeController.class);
    }
    


    ここまでで、テストも通るようになりました。