システム開発とテスト

なんか最近、テストっていう言葉をよく聞くので、僕なりのテストへのこだわりとかをひとつ記事にしてみます。

システム開発とテストについて

僕の考えるシステム開発やテストを、脳内垂れ流しで書き連ねてみようかと。

ここでの言葉の定義は、僕の認識なので、一般の定義とは少し違うかも。そこは勘弁を。

テストを語る前に、そもそもシステム開発とはなんぞや？というのと、システム開発の仕方についての説明をします。

まず、システム開発とは。

システム開発とは、顧客が開発者と仕様を決めてそのシステムを作り納品すること

ここで言う顧客は自分の場合ももちろんありますし、顧客と開発者が同じ人と言うこともよくありますね。マイアプリ開発とかそんな感じですよね。

まぁとにかく、仕様を決めてそれを作るというのがシステム開発の本質だと思っています。

作ったシステムが決めた通りの仕様どおりに動くかどうか、それを品質といいます。そして、仕様通り動くかどうかを確認することをテストといいます。

まぁ、品質にもいろいろあって、外部品質や内部品質といったものにわけられる・・・というウンチクはシステム工学を勉強してみてください。

ぶっちゃけた話、テストっていうのは作ったものが仕様通りに動くかどうかを確認することなので、テストが先でもプログラムが先でもどっちでもいいと思っています。

誤解されるといやなので、先に言いますが、僕はテストは先に書くほうが好きですよ、もちろん。

でも、プログラムを書いたあとにテストするから品質が悪いとか、テストを先に書かないなんてプログラマ失格だ！なんていうのは、僕はちょっと違うんじゃないかなって思います。

テストは作ったものが仕様通りに保証する手段ですので、システムの作り方によってテストのやり方は変えないとダメだと思っています。

プログラムを作ってからテストをする場合、作ったプログラムをいろんな角度からテストします。内部ロジックテスト、外部インターフェーステスト、etc… といった感じです。

プログラムはそこにあるのですから、どんな入力を与えればどんな出力が返ってこればよいかをテスト仕様としてとにかくテストします。そうじゃないと、正しく動いているのかどうかが保証できないですから。

いわゆるテストファーストの考え方です。テストとは、正しく動いていることを確認する手段ですので、当然、先に正しいテストが書ければ、それをパスするようにシステムをつくっていけばいいわけです。

テストファーストのいいところは、実はテストそのもののよりもそれ以外の副次的な効果だと思っています。

まず、プログラムを書くときに考えることとして、どんな機能を実現すればよいか？だと思います。オブジェクト指向でつくろうとか、アーキテクチャパターン、デザインパターンを使ったらいいかもなんてことも頭に浮かんできますよね？

テストファーストでプログラムを書いていくと、どういう手法を使って機能を実現しようかということよりも、どういうふうにプログラムを書いたらテストがしやすくなるだろうか？と考えるようになります。

そして、不思議なことなのですが、テストしやすいプログラムを書いていると、なぜかよい設計になっていることが多々あるのです。

世に出回っている〇〇設計とか〇〇テスト技法というのは、とにかく仕様通りに正しく動くシステムをいかにして作るかを試行錯誤しているにすぎないです。

決めた仕様どおりに動くプログラムが、テストという保証の元に作られる。これがシステム開発のあるべき姿だと思っています。

仕様通りに動くプログラムを作れる。それはそれですごいことですが、動けばいいやって言うのは僕は好きではありません。

「ここのメソッドの命名、すっげーわかりやすい！」とか、「ここの設計、神！」っていう褒め言葉を僕はもっと聞きたい。

だから今日も、テストしやすいプログラムってどんなだろうかということを考えながらプログラムを書いています。