第12章 より効果的なアジャイル:テスト
チームは自動テストをサポートするオンデマンドのテスト環境を維持すべきである
ここに明確に「オンデマンド」って入っているのが2020年の書籍だなーっていう感じがする。クラウドでのCIサービスが普通になって、コンテナ上での開発が普通になったことで、オンデマンドにテスト環境を立ち上げるのが普通になったなー。っておもう。コンテナが普通になる前はいろいろVMでがんばっていたなーなつかしいなってなった。VMだと毎回セットアップが遅くて立ち上げっぱなしにしたくなったものです。。。
完全なテストパスは1日に数回実行すべきである
いや、ほんとうにこれおもうわ。これができていないと複数人での開発に自信持てないです。
できてないので、テストの範囲が広くなるか、修正したところをテストしましょうみたいになってくのでそういう環境を目指したい…
レガシー環境でのテストの自動化
理想的なテストスイートを作成できないからといって、自動テストを作成しない理由にはならない
自動テストの効果をチーム内で理解してもらえつつはあるけど、実際作ってもらえるかというとまだまだ難しい。(データベースと蜜結合している+単体テスト環境と結合テスト環境が同じになっているため)自分がかかわっている場合は、DBに関連しないメソッドやクラスを切り出して、その部分に対して自動テストを作るの取り組みを少しづつ進めています。
ユニットテストのコードカバレッジが70%であることは、新しいコードで目標とすべき有益かつ現実的な数字である。ユニットテストのコードカバレッジが100%であることは滅多になく、通常は収穫逓減点をはるかに超えている(もちろん、安全性を重視するシステムは例外である)。
なんとなくわかる。まぁだいたいこんなかんじだな。C0 80%あたりをまずは目指す感じ。できればC1ではあるが。この後ろにもあるけど静的コード解析と合わせてやるべきっていうのほんとうにそれなってかんじ。Lint系、SonarQubeは商用製品ではある程度かけているなー。
静的コードメトリクスを監視する
SonarQubeを使えるように働きかけをしていかねば。
テストコードを慎重に記述する
テストコードはプロダクションコードと同じコード品質基準にしたがうべきである
これも考えないと…以前に書き方を説明したときに結構マジックナンバーとか文字列べた書きのテストが出来上がってきたので…
推奨リーダーシップアクション
■検査
自動テストに対するチームのアプローチを調べ、テストカバレッジに対する基準や、受入テストの最低限のカバレッジに対する基準が含めれているかどうかを確認する
自動テストができるようにはしたいという目標はあり、テストのある状態に持っていくための見通しを立てている段階。カバレッジは高すぎるとメンテがつらくなるとかんがえているのでほどほどを目指せるように意見していく予定(進め方を検討するメンバーには入れてもらっているので)
カバレッジ70%を一つの目標としている。
チームが手動で実行しているテストを割り出す。こうした手動テストのうち自動化できるものに対する計画がチームに必要だろうか
ごく一部のユニットテストを除きほぼ手動でやってます…自動化できるところをやっていかないとつらいので計画は必要です。
商用製品ではユニットテストは基本は自動化して、インフラ部分はMockかカオスエンジニアリング。インテグレーションテストも基本は自動化しているけど、システムテストやデモ作成は結構手動になっている。最新のツールへのキャッチアップが最近はできていないのでもう少しROI高く自動化の領域を増やせそうだなーっていう感触がある。mablみたいなものをつかうとか、Cypressをつかいこなしたり、自動テスト自体を自動生成したり、OASからテストコードを自動生成したり。
■適応
テストの自動化に対する目標レベルをプロジェクトごとに定義する。次の3~12か月でそうしたレベルを達成する計画を立てる。
改修時に作るクラス・メソッドをDBと関連しないように独立させてテストで保護していけるようにする。リプレイスに向けた活動の中で自動テストを意識していくための設計や修正方針を決めていく
今まさに自動化の目標レベルを検討していた。
目の前で開発案件がないけど、やるならユニットテストC1 80%, WebAPIテストのクエリ組み合わせをあるかたまり毎に3ケース以上、WebAPIテストの異常系、スモークテスト5件程度、パフォーマンステスト ハッピーパスで要件の3倍のボリューム、OWASP ZAPをつかった動的セキュリティテスト全件、SonarQubeで静的コード検査、GitHub Dependabot Alert、くらいはやるかな。。。
2022-05-30
スモークテストからはじめて徐々に自動化していくのめっちゃわかる。
全体的にいまのaki.mさんの状況で気をつけることみたいなのが書いてあって、この辺がある種大変だからっていうのもジレンマとしてあるんだろうなーって思ったりした。
本当にそんな感じの章でした。。!
>理想てきなテストができないからと言って
耳が痛い…
静的なコードメトリクスが一定にないとそもそもスケールしないっていうか、技術的負債の貯まるスピードを左右するっていうのめっちゃわかる。
コーディングタスクがDoDを満たしていない状態で開発者が他のタスクに移る
手動 QA の待ちの間に他タスク着手とかあるなーと。他のチームはテストの自動化どの辺まで実装してるんだろう。
機運は高まってはいつつ、まだフロント側のユニットテストはできてない泣
テスト何もわからなくてすっごく表層しか読めてないですがスモークテストって簡易的な満遍なくやるテストって認識で合ってますか…?
アプリケーションのシステム構成的にEnd2Endを試せるようなテストのことをいいます。システム全体を軽く動かしてとりあえず煙がでないことを確認するという意味のスモークテストです。
最も効果的なのは、レガシーなコードベースのテスト作業を、最も活発に取り組んでいるコードの部分に集中させることである(p149上部)
いきなり活発なとこでやるとウッってなりそうだから、まずは安定したとこでとかいいのかなと思ったけどどうなんだろう。スモールステップ的には良いように感じもする
活発なところをカバーするテストを実装することを目標にして、過程としてキャッチアップで安定した箇所にテストを書いてみよう!とか自分ならやると思いました。
自分もやるかなと思いました
テストとQAがコーディングと同じくらい重要(p150中部)
テストとQAを分けて考えるというのがあまりしっくりこない。何が違うんだろう…?
テストスイートのメンテナンスを優先する
テストスイートのメンテナンスを DoD に盛り込むべきはやってないけど共感した。(やってこ
全体としてTDDをモブでやれば良さそうと思いながら読んでいた
カナリアリリース(後略)(p152中部)
一気に知らない単語が沢山でてきた、調べつつだけどどなたかこっそり教えて欲しいです
新しいバージョンのソフトウェアを一部のユーザーのみに配信してエラーがないことを確認してから、全てのユーザーに配信するリリースの手法のことです。
なるほど!さえずりとかけあわせてそう
炭鉱に入っている時に一番危険なのが毒ガスだが、カナリアを連れていくといち早く危機を察知できる。それ由来で、カナリアをユーザーの一部に務めてもらっている。
カオスモンキー
意図的に本番環境に障害を引き起こす…?
本番環境じゃなくても良い
「インフラを壊して動くか」
シミアンアーミー
ツール群
その中でAWSのクラスターを落としたりするのが「カオスモンキー」
推奨リーダーシップアクション
■検査
自動テストに対するチームのアプローチを調べ、テストカバレッジに対する基準や、受入テストの最低限のカバレッジに対する基準が含めれているかどうかを確認する
ユーザーストーリー毎に受け入れテストを記述していると、カバレッジを判断するために全体としての整合性をあわせるようなディレクトリ構造をつくるのに毎回苦労している気がする。(つまりいつも曖昧な気がする。)
だいたいおおきな目的ごとに1階層目のディレクトリを切っておくことが多い。いわゆる業務フローみたいな感じというか。そうしないと、他のユーザーの操作をエミュレートするようなテストコードを使いまわせないので。。。
システムのリプレース対応で自動テストの導入を目標にはしているので、基準についても検討しないと…
自動テストをしていないし、しているチームに参加したことことがない…
チームが手動で実行しているテストを割り出す。こうした手動テストのうち自動化できるものに対する計画がチームに必要だろうか
機能性とか有用性に関する手動テストは1日以内で終わるようにしているかなぁ。性能とかセキュリティの一部はさらに時間がかかってしまうことを許容しがちだなー。
テスト…なのか…?チーム月面着陸の自分たちがしているのは今となっては結合テストだけ(デプロイ先で、あるいはローカルで、使ってみて適当にポチポチする)で、自動化は検討できそう、ただそこに裂ける人員がいないので、自分が先導すれば…?
■適応
テストの自動化に対する目標レベルをプロジェクトごとに定義する。次の3~12か月でそうしたレベルを達成する計画を立てる。
ユニットテストでC1 80%くらい、静的テストを常にグリーンに保てるようにするのが最初の半年くらいの目標かなー。次でセキュリティ系のテストの自動化をしておきたい。GitHubがなげてくる提案系のPRは2週間以内に取り込むか却下するかできるようになるといいなー。
むしろ今だからチャレンジしてみるいい機会かも、チームに話しつつ、自分主導しつつ計画してやっていきたい