ふとしたご縁で(ただただ押し掛けただけなんですが…w)
テスターちゃん作者Mさん、のご友人のYama Kenさん主催のワークショップに参加してきました。
(大分遅くなったけど…)以下、内容と感想です。
※主催者の方のこのワークショップのエントリ
欠陥プログラマーの整備手帳 — ワークショップ@博多
■開催概要
日時: 2018/02/04
参加人数: 3人
ワークの内容
ワークの流れ
- ワーク1
- お題のプログラムについて、テストを考えずに実装する
- ↑を参加者が持ち回りで探索的テストする
- それぞれがテストした結果を共有する
- ワーク2
- 1.2や1.3をもとにテストケース&テストデータを作成する
- 2.1のテストコードを作成した後、お題のプログラムを作成する
お題【マイヤーズの三角形】
■ワーク1について
お題のマイヤーズの三角形は、そもそも知ってたのと、
"テストを考えないで"っていうのがなかなか、難しいなぁ…と思いました。
なので、初めてマイヤーズの三角形に出会った時の感覚と、学部生時代のころを思い出して
プログラムすることにしました。出来上がったコードが以下です。
※私が選択したのはJavaScriptです。
<html> <head> <title>マイヤーズの三角形byモンキー!</title> <script type="text/javascript"> function Triangle( line1, line2, line3 ){ if( line1 == line2 & line2 == line3 ){ return "Equilateral triangle" ; } else if ( line1 == line2 | line2 == line3 | line3 == line1 ){ return "Isosceles triangle" ; } else { //Scalene triangle return "Scalene triangle" ; } } function disp(){ line1 = window.prompt( "三角形の1辺を入力してください①", "" ); line2 = window.prompt( "三角形の1辺を入力してください②", "" ); line3 = window.prompt( "三角形の1辺を入力してください③", "" ); alert( Triangle( line1, line2, line3 )); } </script> </head> <body> <p><input type="button" value="三角形識別!" onClick="disp()"></p> </body> </html>
ワーク1 感想
一応補足すると、もちろん、三角形が成り立たないことがあるとか、入力されるデータのチェックが必要とか…
そういうのはわかっておりますw(念のため)
プログラミング学びだしたころぐらいまで感覚を戻しまくって、
ただお題だけを読んで「よっしゃこんなん簡単やで!」っていう思考で、
特に調べることなどせず、辺が全部一緒なら正三角形、 2つ一緒なら二等辺三角形、全部違うなら不等辺三角形!
という考えを疑うことなくプログラムをした。
という感じでした。
その結果なんですが、とりあえずIF文で辺を比較したらそれでいいだろう、という思考になりました。
コードができた後に、「0が入力されたら」とか、「マイナスがにゅうりょくされたら」とかそういうのを考えました(時間がなかったので実装はしてないです)
そしてお二方に動かしてもらったんですが…まぁバグいっぱい出してくださいましたw
正常系以外バグしか出ないですしね…。これ。
だいぶ楽しんでくれてて、ある意味いいもの作った感でしたw
■ワーク2について
事前に作成したテストケースは以下です。
・テストケース(32ケース) 正三角形の確認(1パターン) 二等辺三角形の確認(3パターン) 不等辺三角形の確認(3パターン) 三角形が成り立たない(6パターン) 全角文字が入った時にエラーとなること(3パターン) 半角英字が入った時にエラーとなること(3パターン) 0以下が入ったときにエラーとなること(3パターン) 小数が入ったときにエラーとなること(3パターン) 入力が最大値を超えた時にエラーとなること(3パターン) 先頭に0がついた時、エラーになること(3パターン) 空白の時、エラーになること(3パターン)
ワーク2感想
プログラム書く前の、テストコードを手で書いていくのが大分辛かったですw
3人とも頑張ってテストコードをただただ手打って…苦行でした。。
だけど、テストコードを書き終えた後は、待ちに待ったプログラムができる!
ってかんじで、みんな楽しみながらプログラムしていて、良い感じでした。
一応ルールとして、テストケースが全部Passになったら完成、というのがあったのと、
あとどの機能を実装したら完成か?というのが目に見えて分かりやすかったので、
精神的な負担が少なかったです。
■全体の感想
ワーク1とワーク2で、状況や感じたことをざっと比較すると、以下になります。
- ワーク1
- 先に基本機能を実装する→あとから継ぎ足し継ぎ足ししていく
- 終わりがわからない不安感がある
- ワーク2
- 先にテストする項目を考える→仕様が細かく決まっている
- いつでも動作確認ができるので、精神的に楽。
- テストケースを終わらせていく感覚が、ゲームで実績解除していく感覚に近くて、楽しめた
最近はほとんどコード書かないですし(そもそも社会人になって開発したことないですし)
プログラムを書く!っていうワークが新鮮でしたw
ワーク1であんなコード書いてますが、長崎QDGで池田さんが言われていた、
設計時に思考が狭まっていく(仕様を定めていく)っていう感覚は一応あったんですよね。
なので、ワーク1でプログラム書き終わった後、探索的テストになったんですが、
テストの思考に切り替えるのがだいぶつらかったですね。
テストする視点を広げていく、というのがなんとも難しかった。
昨年出版されたTDD本の 「テスト駆動開発」を読んではいたんですが、実際に経験してこそわかることがありますね。
また読み返そうと思いました!
本の中に、開発が予測可能となる、プログラムを書いていて気持ちがいい、
ということが書かれていましたが、まさにその通りで、
ワーク2では、先にテスト考えれてて、いつでもテストが楽に行える、っていう安心感と、
ゴールが明確化されているという、すっきりとした感じが開発中にずっとありました。
そして、普段ブラックボックステスト(+グレーボックスっぽいこと)しかしていないので、
ホワイトボックステストを経験できたのも有益でした。
こういう実装しているから、このテストはいらない、とテスト項目を削るのが新鮮でした。
そして、事前にテストを考える=仕様を明確化しているんだなぁと実感できました。
普段の業務でも少しはあるんですが…テストと開発を一緒にやることになると、更に深まった感じでした。
やっぱり静的にテストするって大事ですね
突如押し掛けてしまったんですが…普段できない貴重な経験ができたワークでした!
Yama Kenさん、まつさん、ありがとうございました!
またやってみたいですし、自分の周りの人にも経験させてあげたいなぁ…と思えるワークでした(^^)
Reference
単なる仕様チェックから卒業するために ~最初に抑えたいキホンのキ~ https://www.slideshare.net/Ikedon/ss-81535911/33
- 作者: Kent Beck,和田卓人
- 出版社/メーカー: オーム社
- 発売日: 2017/10/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
その他
ワーク1のコードについての考察というかなんというか…
ワーク1で、あのコードを書いて満足する開発者の方ってほぼおられないと思ってます。
三角形が成立しないケースはもちろんながら、入力制限をつけたり、他の異常系についてなどを、
ドキュメントレビューで指摘してくれたり、すっといいかんじに実装してくださるんだろうなぁ…と。
ただ、そういうドキュメントの行間を読んだり、異常系について考えるのって、
開発者個人のスキルや経験に依存しているだろうから、そういう一切を省いてしまうと
私のようなコードになるんじゃないかなぁと思いました。
なので、ドキュメントに書いて有ることだけ、自分の知識の中だけで実装したらいい…って思ってたり、
開発経験が少ない場合は、ワーク1の私と同じような思考になる方もいるのでは…とは思いました。
(開発するものの規模が大きいかどうかが違うだけなんじゃないか…って思ってます。
そういうような思考の人もいるんじゃないかなぁ、とか、
普段自分が関わっている開発者の方は、いつも良い感じにやってくれてたんだなぁ…と改めて感じれたので
そういう点も気づけてありがたかったです。