SQLiteのテストコードの量が凄すぎ

最後のソフトウェアは机上の理論というのは、同じソースでも動作させるハードやOSが異なれば違う結果をもたらす事を注意されての事でした。

因みにハードウェアの業界は完全に分業されていて回路設計をやっていましたが、そこに「製造」と「テスト」の工程はもっと下流の担当になるので、設計工程でのテストとは仕様の範囲内で設計が行われたか、人的ミスは無いか、シミュレーションの結果は正しいかに絞られました。完全なウォーターフォールですが、最近ソフトウェアの開発工程ではV字モデルが取り上げられてウォータフォールより進化しているように書かれていますが、正直あの時系列で実行したら手遅れだろと個人的に思ってたりします。

あともう少しツッコミ入れると、他業界から来た技術者から見れば「製造」と「実装」の使い方が不適当な気がする。ソフトウェア開発では会社によってコーディングの事を「製造」や「実装」とよびますがハードウェア業界ではコーディングは「設計」フェーズであり、納品するソースコードは設計書である。わざわざソースコードの設計書をエクセル等で書くような無駄はしない。（仕様書は書くけど）

では「製造」はどれに当たる？って言われればROM焼きやCD/DVDのプレス辺り、広く見てもコンパイルされたバイナリやインストーラーを付けたパッケージじゃないかな。で「実装」の方はROMならハードウェアにハンダ付けすることで、プログラムそのものなら製品にプリインストールすることを示すと思う。ウェブ業界でサーバー納品って言われている作業も「実装」にあたる。だからコーディングを実装なんて呼ぶと、そんなまともに動く保証が無いのにいきなり実装するわけ？って思うのです。ウェブだと稼働中のプログラムを直接コーディングする行為なら「実装」と呼べるがハイリスクな作業なのはわかりますよね？新品のサーバーの場合は直接サーバー上でコーディングする場合は「設計」と「実装」が行われているように思えますがコーディング終了までが「設計」なら途中段階の導入は「実装」と呼んではいけないかな？

元々ソフトウェアはコンピュータ業界の一部分を切り取って専門・汎用化したのであって他の業界と同じようにフェーズ作りなんてやってるから無駄なドキュメント作成が増えていると思っています。「ソースが仕様だ！」は単なる暴言ですが「ソースが設計だ！」は正しい。「設計書とソースの結果が異なります。どちらが正しいのでしょうか！＞＜」なんて質問が出るのは二重開発している証拠でこれこそ無駄作業。システムとして動かないドキュメント書く代わりにテストコードを書けという事です。

ソフトウェアの設計書というのはソース非公開のプログラムに対しての公開用ドキュメントだったり、ソースが読めない人向けの翻訳書としての価値しかないので自動生成で済ますか、ソースにコメントとしてしっかり書くようにするように進めたいものです。難読ソースを生産しないようにコーディング規約でしっかり管理する必要はありますね。

そんな事言っても既にソフトウェア業界の常識で決まってんだからそれに合わせろよ！という考えもありますが、気になるのは本来「設計」フェーズのものをさらに分解して「実装」や「テスト」と呼んでいて、本来の「テスト」工程はどこにいったのやら。。。

見積もりには「設計」「実装」「テスト」と書くので顧客はテストされたものが納品されると信じます。でも本来の「テスト」を顧客に丸投げしてたりしませんか？そして本来の「テスト」をされることなく本稼動して初めてトラブルに気付き瑕疵対応に追われていたりしませんか？

実際、下請けとかだと本来の「テスト」が行えないことは多々あります。その場合は顧客にテストしてもらう必要があるので認識のすり合わせが必要ですが、「納品物にチェックシート付けます」ってのは結構乱暴かなっと思いました。（現在進行形でやっているので反省です）

こういうときの為に自動テストコードもしっかり作って納品に含め、テストしてもらう事が大事だなと思います。負荷テストやシステムテストに関しては最低限の事は出来ている所が多いとは思います。

特にPHPの場合はサーバーが違うとモジュールや仕様の違うPHPが動作している可能性は非常に高く、また開発側もどのモジュールを使用しているか？それが納品先のサーバーでも問題なく動作するのか完全に把握できない事も度々あります。つまり納品後にもユニットテストは必須になるため「開発側でユニットテストとジョインテストを行うのでお客様はシステムテスト以降でお願いします。」というのは大きな間違い。そんなことだから「PDOでエラー停止した！」「PEARの警告が画面に出てる！バグじゃね？」ってクレームが来たりします。左記のは実装段階でセルフチェックするテストコードがあればそこで発見できるものですが、細かいもので言語仕様や関数挙動の変更に伴うチェックはやはりユニットテストからやり直しが必要かなっと思います。

ウェブシステムだとバグ出したからって死亡事故が起きたり、開発のやり直しそのものに数十億円掛かるなんて事はまれなのでゆるくなりがちかも知れません。最もその原因が安請け合いだったりしますが。。。