テストの話 - miyatsu's blog

こんにちは。みやつです。

一ヶ月ほど更新をさぼっていましたが、ふとデスクトップをみたらSonicGardenStudyでテストの話をしたときのメモが残っていたのでこれはちょうどいいという事でブログにアップしておきます。

SonicGarden Study Test

ツールの使い方ではなくて概念的なお話盲目的にテスト書いてるだけになってない？テスト書く前にプログラマとして考えることあるんじゃないの？

テストの限界とは網羅率も限界の1つあまりにも条件分岐が多かった場合にもれたりする。テスト書いただけでバグがなくなるのかな。

ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことを証明できない。

仕様の検討をして、実装していない場合は拾えない。欠陥とは実装のバグではなくもっと広義のいみ間違った仕様を頑張って実装してテストしてもそれは欠陥

すべての欠陥を取り除くことは不可能バグの出ない期間を長くすればするほど、コストが天文学的に増えていく。

カバレッジ100％を目指すとシンプルに書いていたとしても大変

テストを行う目的が大事なんのためにかくの？盲目的に書くのではなく、何のために書くのか意識する必要がある。

テストを書くのはなんのため？ソフトウェアが落ちるようなバグを防ぐため。テストによって何を守りたいかは、プロジェクトや会社などコンテキストによって異なる。はやぶさとwebサービスでは違う

SonicGerdenの場合納品のない受託開発お客さんと一緒のチームになってひたすら作る

普通の納品型と違って絶えず機能拡張が発生する。いつでもサービスが動いている。そうなった時に何を守るべきか？

安定稼働＆継続的な改善

継続的な改善機能を追加機能の微調整終わりがないということはrailsもupdateしていく技術的負債を残さないようにリファクタリングも随時行う必要がある。

どう守るか？テストするのはコストが掛かる。どの程度コストをかけるのかを考える必要がある。

どれだけ頑張ってもバグは発生するテストのやり過ぎはコストがかさむ

テストをやりすぎて機能追加ができなければ本末転倒

そこで！不具合を許容するという考え方不具合０を目指すより、発生した際にどれだけ早く直せるか

早く直せないのであれば０を目指してもいいのでは？

コードがどれだけ綺麗に保たれているかがとても重要汚いコードだとバグの修正は大変

「何のために」を考えることで「どうするべきか」が見えてくる

そのプロジェクトにとってどこまでやるかを考えていかなきゃいけない。答えがないので考え続けなきゃいけない。

テストだけで大丈夫？バグには習性がある

発見されずに長い間残った欠陥は、修正にも長い時間がかかる。

どういう経緯でそのコードになっていたかをみんな忘れている。バグを前提に動くように組んでいた場合そのバグを直してしまうと他に影響がでてしまう。

欠陥を見つけるのが早いほど、欠陥の修正も安価になる。

バグを早く見つけるには

高価で遅いテストによって多くの欠陥が残る。頻繁なテストによって費用と欠陥が削減できる。

どう立ち向かう？バグを早く見つけて潰してしまう。定期的にチェックする。

リリース前のコードレビュー＆週次でリリースフィードバックがいっぱい貰える

自分で書いたコードは抜けてる自分以外の第三者が見ると早期に発見できる。

テストだけに頼らない！足りない部分は仕組み化してしまう。

テストに向いている分野でテストに頑張ってもらう。そうでない場所は組織の力で守っていく。

1.テストではバグがないことは証明できない。 2.テストの目的を掘り下げて考えることが大事 3.テストだけに頼らない

まとめ目的もなく盲目的にテスト書いてませんか？テストがなくとも品質を上げる努力が大事そこまで考えるのがプログラマーの仕事です

掛けるべきコストをちゃんとかんがえましょう。テストを書くってのはコストがかかる。

納品型のビジネスモデルであれば不具合０を目指すのはは正しい

テストの得意なところ railsのupdateとかgemのupdateとか

インテグレーションテストは正常系を、異常系はユニットテストでするって話してる。