【開発哲学3_22】〜『CODE COMPLETE第２版 第22章(下巻)』の感想〜デベロッパーテスト
感想
テストの重要性について、しっかり書かれてるし、読んだら、事前にテストケースを作らないorテストケースをイメージせずにいきなりコードを書く（＝設計を意識しない）エンジニア減るかな。
（最近は、テスト専門会社にテストを外注する企業も増えて、開発とテストが完全に分離されて、テストケースとかテストスイートを職場でやったことないってエンジニアさんもいるかもしれないけど。）
要は、
コードを書く前に、テストケースもちゃんと想定する（＝前処理。準備）
↓
コードを書く（＝本処理。メイン作業）
↓
ちゃんと想定どおりの結果になったか確認（＝後処理。確認／検証）
しようねってこと。
言われりゃ当たり前だけど、実際の作業で出来てない人が多いから、本になってるってこと🕺（＝哲学）
もちろん自分も一回もテストせずに完璧に動かせるなんて思ってません（エへへ）。
「テストなんかせずに、完璧なコードを書けるべき」
って
テスト ＝ コスト
と考えて、端折りたがる管理者もいるけど、テストせずに、リリースしてから発覚する不具合を改修するコストの方が断然高いって考えないのかな（＝足し算と引き算）。
詳細
見出しとしては、
ソフトウェアの品質におけるデベロッパーテストの役割
デベロッパーテストへの推奨アプローチ
テストの知恵袋
典型的なエラー
テストサポートツール
テストの改善
テスト記録の保管
参考資料
まとめ
って感じ。
特に、
テストとデバッグの違いとか、テスト駆動開発の入りとしてちょうどいい説明になってるから、テストとは何かを学ぶのに最適な印象。
テストケースを何個も作った経験があると、コードを書く前に、テストケースが頭に浮かぶし、肝になるメインの処理（＝エラーが一番発生する箇所）がどこかがわかるようになる。
自動化の波で、、、
テストケースがコードで用意されてる言語（Javaとか）では、テスト自体をコード化してテスト自動化することも増えてきてる。
（今や当たり前なのか、、、💦）
ただし、テスト自動化は
テストコードが書ける、動かせることが前提。
その分、コードを書く量も増えて時間と作業量が増える。
トライアンドアローな開発だと、顧客の要求が流動性が高い。
からか、
⒈テストケースをエクセル表に人間がわかる言葉でまとめる
↓
⒉テスターさんにハックさせる
↓
⒊スクリーンショットを採取させる
👉エビデンス（証拠）として管理
するところがまだ主流じゃないかな（詳しくは知らんけど）。
結局、コード単位のテストでは、
ブレークポイント作って、consoleやdebug.printで表示させる
が最強かも、、、笑
以前、テスターで働いていた職場で
プログラミング自体が未経験で開発者で入った男の子がいて、テスト作業工程がわからないまま、テストケースをエクセル表にまとめはしてたんだけど、テスト結果が画面採取できないものをテストケースに盛り込んでいた人いたなあ、、、。
どんなテストをする必要があるかを把握することは大事
世の中で起きるシステムの不具合は殆どは、
①コードを打つ前の考慮不足（カバレッジ漏れ）
②単純なコードのミス（単体ミス）
③ルーチンの順番のミス（結合ミス）
④コピペしたコード修正後のチェックミス（レビュー漏れ）
のいずれかだったな。
CS（カスタマーサポート）対応の経験だと、
結局、元を辿ると、①のカバレッジ漏れが半分以上を占めてたくらい。
「自分は運転が上手いから事故を起こさない」
て人に限って、いつも事故を起こしているように、
「自分のコードにミスはないから、エラーを起こさない」
とかが口癖で、自分の書いたコードはテストしないで、
べき論を振りかざして、他人の書いたコードに目くじらばかり立てるんだけど、
いざその人のコードを実行してみると、エラーや不具合だらけどころかまず処理が繋がってないから最後まで動かないってこともよくあったなあ。
そーゆー人ほど
最初は基板や間に使ったツールなんかの不具合、他の人がコードを書き換えたと疑って、ミスを認めようとしないし、そもそも、
基板やサーバーはいつも安定し、開発する人間は完璧なコードを書き、お客さんは開発者の想定する操作をする
って前提で動くんだよねー！
だったら、運用保守やネットワークやサーバーのエンジニア、インストラクターや資料作成担当者なんて不要でしょ。
前提解を間違えると最適解には結びつかない（エリヤフ・ゴールドラット）
まとめ
テストのやり方は、現場次第だけど、テストの重要性は変わらない
（所詮、人間が作る以上、どんなシステムでもエラーは発生する！）
↓
💃質の良い開発は、開発者のテスト経験から生まれる🕺
👉テストしないと自分のコードが不安くらいがちょうどいい。
参考文献
テスト自動化
については、こちら。（Swift開発の本だけど💦）
テストまで含めた開発プロセスを知りたい人向け
日本だとSDEMが主流かな（ここ数年で変わっているかもしれないけど）💦
エリヤフ・ゴールドラット
色々なシリーズが出てるし、前述の格言は、確か数学の本で出てたから、関係ないけど、ITやデジタル化を進めたいマネージャ向けの本だと、こちら。
なぜ、最新のシステムやツールを導入してるのに、日本の企業では、最適化が進まないのかが、小説の筋立ててよくわかる。
結局、
自分達のやり方に合わせて、導入したシステムを変える
ではなく、
導入したシステムに合わせて、自分達の今までのやり方を変える
じゃないとダメ ＝ チェンジ・ルール
って話