connpass
http://connpass.com/event/2270/
togetter
http://togetter.com/li/490112
以下の書籍をターゲットとした写経会なのです。
 | JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) (2012/11/21) 渡辺 修司 商品詳細を見る |
場所はいつもの横浜、タネマキさんです。参加者は20名くらいかな。
今回は特別編ということで、著者の @shuji_w6e 氏が参加！
しかもお題はSelenium！期待せずにはいられない！
というのも私、前回のJUnit写経会の事前アンケートの、「触ってみたいツール」的な回答項目に、ちょうど「Selenium」と回答したばっかりなのです。
一応お仕事でもJenkinsで自動テストは仕掛けているのですが、仕掛けているのはロジック部分の単体テストのみ。
んで常々、Webアプリの自動テストをなんとかできないものかなぁ、Seleniumというものがあるらしいんだけど試してみたいなぁ、とか思っていたところなのでした。
そんな私にとって、今回のテーマはストライクすぎる！
今回の写経会は、事前に開発環境を構築をするための準備までされてます。この充実ぶりは素晴らしい！
書きました。当日参加予定の皆様、是非ご一読をお願い致します。/ 『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) 開催についての諸々お知らせ #junitbook - Shinya’s Daily Report d.hatena.ne.jp/absj31/2013050…
— しんやさん (@shinyaa31) 2013年5月6日■本日のご案内
by 主催者 @shinyaa31 氏
毎度、アジェンダの作成とか司会進行アリガトウございます。
今回は更にお弁当の手配とか、至れり尽くせりです。感謝！
以下、スライドに無いトコ中心に、個人的にとったメモ。
■講演『テスト駆動開発を継続する』
by @irof 氏 (“TDDBC Osaka 2013 1月 外伝”再演)
テスト駆動開発を継続する from irof N
@irof 氏による講演です。
発表スライドはまだ公開されてないようなので、1月のものを貼ってます。
■P.36 ついで症候群
・最初の２つのassertはいらない。他のユニットテストでやってるはずなので。
・ついでに書けるからといって余分なテストを書くと、プロダクトコードを1箇所変更するだけで、あちこちのテストでコケる。
（テストケースに重複があるので）
■テスト大変だからテスト失敗しないようにしよう、となるとダメ。
■開発が進むにつれドメインが明らかになってくる。
・適切な名前もわかってくる。なのに変更/リファクタリングできない、というジレンマの事象が出てくる。
・変えたい、と思ったときに変えられるようにする必要がある。
■失敗が特別行事になると、変更やリファクタリングができなくなる。
・なので、失敗は特別行事じゃなくて、あたりまえのことにする。
■場当たり的な対処は、新たなミスを生む。
■テストを書く、ということは、想定できることしか書けない。
・でも、プロダクトコードを修正すると、想定できないバグが起こる。
・なので、プロダクトコードを変更してもバグは起きない、ということが定量的に言えない。
・そこを保証しようと思ったら、網羅性を考慮するしかない。
・どういうテストを自動化するか、を考えることが重要。
・予測不可能なことが起こるなら、設計が間違っているのでは。
・環境がおかしくてテストがコケることを検知するテストはまた別にある。
■受け入れテストの自動化とユースケース駆動開発
by @shuji_w6e 氏
(↑はTDDBC 大阪の資料。これと当日資料はほぼ同じとのこと）
■状況によってはJUnitのテストが無くてもアリだと思っている。
・Railsはほとんど設定でおわり。コードあんまり書かない。
・ユニットテストをすると、Railsのサクサク感がなくなる。
・Railsだとテストで○か×かはない。設定されているかされていないかだけ。
・ユニットテストやるよりは、いっそのこと受け入れテストやっちゃった方が良い場合がある。
・受入テストを厚く書いて、ユニットテストは不安なとこだけ書く。
・そのようにやってみたら、Railsならこっちのほうが良いと思った。
・ユニットテストは、不安なところをやるのが結論だと思う。
■テスト駆動開発かユニットテストかの違いは、テストファーストを実践しているかどうか。
・テスト駆動開発はプログラマを救ったか？
→ Yes。確かに救った。
■重要なのは、要件からテストケースを導くこと。
・何を作るのかを考えなきゃいけない。それを要件から導かないといけない。
・外部設計が一番重要だったりする。
・TDDは要件とテストリストの橋渡しはしてくれない。
■外部設計の手法で、ユースケースを使うのが一番いいと個人的に考えている。
・アジャイルで言うとユーザーストーリー
■ユーザーストーリーからプログラムがいきなり作られるわけではない
・しっかりユースケースシナリオに落とし込むことが重要。
・見た目も重要。ユーザが実際に触るシステムは、中のプログラムでなく、外部インタフェースなので。
■「基本設計」という名前よりも「外部設計」という名前が好き。
→ 「外部」という単語から、システムの利用者視点、というニュアンスが出ているから。
■神崎さんの外部設計の書籍がおすすめ。
 | 顧客の要求を確実に仕様にできる要件定義マニュアル (2008/10/23) 神崎 善司 商品詳細を見る |
■ユースケース駆動開発実践ガイドという書籍が参考になる。
 | ユースケース駆動開発実践ガイド (OOP Foundations) (2007/10/17) ダグ・ローゼンバーグ、Doug Rosenberg 他 商品詳細を見る |
・まず前半半分を読めばよい。後半はユースケースで設計したものをSpringで実装する話。
・前半が重要。
■ユースケースは、システムの使用例。
・ユースケースシナリオは必ず箇条書き。１行で１アクション。
・お客さんにモックアップを見せながらユースケースシナリオを組み上げていくのが外部設計。
・ユースケースシナリオは実装チームじゃないと書けない。実装を意識しないと書けない。
・なのでSIerのマネージャ的な人がユースケースシナリオを作って開発チームに渡そうとすると、死ぬ。
■ユースケース図はただの目次。
・ユースケース図をいくら書いたって外部設計にはならない。それは要件定義でしかない。
■ユースケースには二つの流派がある。「システムユースケース」と「本質ユースケース」。
・本質ユースケースを要件定義でやるのは問題ない。
・ただし実装の際はシステムユースケースに落とし込む必要がある。
・両者は別物。
■ユースケースシナリオは、お客さんの合意が取れてないといけない。
・合意を取るためには、日本語でお客さんが理解できる言葉で書かれていることが重要。
■ロバストネス分析
・3要素がある。
①バウンダリ ： 境界。ユーザが操作するところ。
②エンティティ： DBに永続化するようなデータ。
③コントローラ： 操作。
・頭の中で分析を済ませて先に進めることもある。ガチガチにロバストネス分析すればいいわけじゃない。
・ユースケースシナリオに「管理者」という単語が何箇所か出てくるが、それってそれぞれ別じゃね？
・・・といったような分析とかをやる。「管理者」を更に細分化したりして、日本語の曖昧さを無くす。
■現実としては、ロバストネス分析をやる前提でユースケースシナリオを書くので、分析をしなくてもあまり乖離しない。
■ユースケースシナリオ
・コントローラがユースケースシナリオの動詞で、publicメソッドになる。
・ユースケースシナリオからクラス数とかメソッド数とかテストケース数とかがざっくり見積もれる。
■みなさん大好き「確認画面」を追加すると、ユースケースシナリオが3行ほど増える。
→ 「このくらいコスト増えますよ」とユースケースシナリオを見せてお客さんに言えるようになる。
→ 折衝の材料にできる。説明の際の武器になる。
→ そうやって説明をきちんとして、いらないものは作らない方が良い。
■ユースケースシナリオの量が多くなると、「レビューが辛い」とお客さんがなる。
・それで「じゃあ、いらないもの削りますか？」と持っていける。（折衝の材料になる）
■ユースケースシナリオの1行がユニットテストに対応する。
・受入テストは、ユースケースシナリオの全行が対応する。
■受入テストだけやってユニットテストをやらない、というのはアリ。
・不安なとこだけユニットテストをやる、というのが結論。
■ユースケースシナリオを作る段階は、受入テストを作っていることとほぼ同義。
・テストデータがないことだけが違う。
■「実践アジャイルテストという書籍に、アジャイルテストの4象限が紹介されている。
 | 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践) (2009/11/28) Janet Gregory、Lisa Crispin 他 商品詳細を見る |
・ユニットテストはプログラマが救われるためのテスト。基本的に自動化が前提。
・ユースケースをテストシナリオにできる。
・ユースケースを序盤できっちり作れば、テストシナリオを書いたことになる。
・自然言語でテストシナリオを書くことで、Cucumberのテストに繋がる。
■ユースケースシナリオにおける代替シナリオは、お客さんに価値を届けるというより、品質を上げるもの。
・主シナリオに分岐はない。１つの価値のみ書く。
・20ステップを超えるとデカ過ぎ。複数のシナリオに分割したほうがよい。
■アーキテクチャやフレームワークを理解している人なら、ユースケースシナリオは作成できる。
・個々のフレームワークの詳細よりも、抽象化された概念がわかればいける。
以上、午前は @irof 氏と @shuji_w6e 氏による講演でした。素晴らしいクオリティです。
■Cucumber＆Selenium ハンズオン
@shuji_w6e 氏が用意してくださった演習題材を使用し、Cucumber＆Selenimuのハンズオンです。
午後の演習の資料です。dl.dropboxusercontent.com/u/1393956/cucu…#junitbook
— SHUJI@BRM609出走予定さん (@shuji_w6e) 2013年5月12日実際にSpring Frameworkを使って構築された書籍管理Webアプリケーションに自動テストを仕掛けます。
しかもテストシナリオは日本語で書きます。
すんげー実践的でハイクオリティなハンズオンです。
私も、なんとか最後までテスト書いて、動作させるところまでできました！
なんとか一通り動いた！付いていくので精一杯でしたが、Webのテスト面白いですねー#junitbook
— makopi23さん (@makopi23) 2013年5月12日私、初めてSelenium使ったんですが、自動でリンクがクリックされて画面遷移する挙動を見たときはチョト感動した！
このハンズオンの内容は、ちょうど会社のサンプルWebアプリケーションのテストにも使えると思う。
これは復習するに値する内容と題材ですね。
もう一度、課題の材料を使って一からやってみようと思います。
私のスキルと頭では、なかなか目の前の課題を順にこなしていくので精一杯なところもあったので。。。
あと、ちょとメモ。
・MavenのProfile機能は強力。
・GradleなりMavenを覚えたほうが良い。
・テストシナリオをつくるところがイマイチだと、後ろをどんだけ頑張ってもうまくいかない。
・ユースケースシナリオを綺麗に書いているかがキモ。
・結論：ユースケース駆動開発もやろう！
■懇親会
ハンズオン終了後は、同じ会場で懇親会です。
@shuji_w6e 氏と @irof 氏と私の3人で、近くのスーパーに買出しに行ってきました。
@irof 氏と @shuji_w6e 氏と買い出しに行ってきました！ #junitbook
— makopi23さん (@makopi23) 2013年5月12日著名なお二人と会話する機会！光栄な役回り！
@enum 氏も飛び入り参加で、講師のお二人と参加者でソフトウェアテストに関する話で盛り上がりました。
■いろふの部屋＆LT
@irof 氏から参加者に質問を投げかける形で、ソフトウェアテストを題材にいろいろお話しました。
またTABOKをテーマとしたLTもありました。
#junitbook なんて買ってさらに読書会に参加してるんだからテスト自動化に興味が無いわけが無い。と言うことでTABOKの紹介をどっかのタイミングでしようと思うなど。
— iRoFさん (@irof) 2013年5月12日TABOKという単語、私は初めて聞きました。
Test Automation Body of Knowledgeの略称だそうです。（PMBOKとかBABOKとかと同じ類のネーミングですね）
テスト自動化の知識体系だそうな。この辺のサイトが参考になるかも。
テスト自動化研究会
https://sites.google.com/site/testautomationresearch/
★感想：
素晴らしいクオリティでした！充実な一日です。
今日のハンズオンで学んだ内容は実務にも使えると思うし、講演からも多くの気づきが得られました。
ホント主催者の @shinyaa31 氏、講師の @shuji_w6e 氏と @irof 氏に感謝！
このような特別会、またあるといいなぁ。長野で温泉ハンズオンみたいな話も出てたし、楽しみです。
皆様、ありがとうございました。
- 関連記事
-
- アジャイルサムライ読書会 横浜道場 「現場の状況を目に見えるようにする」に参加しました
- 『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加しました
- SQLアンチパターン読書会 「IDリクワイアド」に参加しました
