はじめに
- 懇親会中は様々な所で特に決まりもなく話しています。
- その中で会話に参加した部分のみ載せています。
- あと、会の終了後に思い出しながら書いているので、自分が参加した中でも結構漏れがあります。
- 指摘、補足がある方は教えて下さい！
深谷さんとの会話
- Q．testingをした部分をどのように残していくのか？
- A．一緒に「この観点があるよね」と言いながら残していく。
感想
- テストの分析と設計が一緒になっているのかもしれない
- どうやって後世に残していくのかを考えることが必要かも
- 文章上だけだとどうしても把握しにくいことがある
- どうやって後世に残していくのかを考えることが必要かも
松尾さんとの会話
- 何かを変えることはストレス
- 発表スライド内にもありましたね
- 開発とテストエンジニアが完全に分かれている組織が一緒になろうとするのは無理が生じる
- そうならないためには、最初から完全に分かれないような文化が必要
- 開発者がある程度のcheckingまで責任を持って行う仕組みとか
- そうならないためには、最初から完全に分かれないような文化が必要
感想
- よく社風とか文化が大事という話がありますが、こういうところに響いてくるのかもしれませんね。
- 少なくとも大学生の就活していた頃は、その理解をできていなかったと今さらながら反省…。
関さんとの会話（あまりメモ取れてない＆書けない…）
- テストの自動化に対してはある程度割りきった方が良いのかも
- 組織的なことはあまり考えずに、責任がどうとか関係なく、自分でやっちゃえば良い
感想
- コンシューマや自社サービスが技術の先を行って、エンタープライズ系が後を追う形になっているのは、こういった面があるのかもしれないです。
和田さんとの会話
レガシーなコードをテスト可能な状態にするには
- 個々で事情が違う
- もしもコードが機能分割できている状態ならば、小さいところから始めても良いかもしれない
- もしも密結合な状態になっているならば、Request,Responseのレベルでテストを書いた方が良いと思う。
- まずは状態の再現性から保障する
- その後、リファクタリングしよう
- 逆に小さいところから始めてしまうと、簡単にテスト結果が変わってしまうため、再利用しにくいものになってしまう可能性がある
カバレッジなどのメトリクスの話
- カバレッジなどの数値は見える化するためのものであり、高みを目指すものではない。
- 仮に90%であっても、70%から増えていって90%になった場合と、100%から90%に減っていく場合で意味合いは大きく異なる。
- 体重計は今の体重を知るためにある訳で、体重計に乗ったから体重が軽くなる訳ではないのと一緒。
- 現状を知るのが大事
- 詳しくはJasst北海道の資料参照(p42あたり)
JaSSTソフトウェアテストシンポジウム-JaSST'14 Hokkaido レポート
直リンク→ http://jasst.jp/symposium/jasst14hokkaido/pdf/S1.pdf
感想
- レガシーコードの改善案はとても参考になりました！
- メトリクスやtestingの部分などは、開発者視点だとあまり捉えないことが多いですが、これからの開発にとって重要な部分だと思います。
- 開発も参加しつつ、テストのことを学べる場としては、JaSSTがちょうど良いと、改めて感じました。
