gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

テストデータは原則として作らない

先日つぶやいたりニュースフィードったりした発言で、何カ所か質問がきたので、その辺の解説を。


https://twitter.com/gallu/status/311293551487094784

[開発のDB周りの話]そういえば「テストデータは原則として作らない」「trancate祭り」とか、知っている人は知っているんだけど、意外と知られていないことも多いような。…こんどどこかで書こうかしらん?


一言で片付けると、うちの愛弟子の発言で終了してしまうのですが。

テストデータ作らないのは、開発者にとって都合のいいデータになりがちだからかな? truncate祭り行うのは、create table文などの管理が継続して行われているかのチェックにもなるから かな?

もうちょいと、かみ砕いて(砕かないと、Blogにする意味が果てしなく薄くなるからw)。


ありがちなパターン…直近で似たのがあったので、それを例にとって(若干、事実と異なる部分があります。実際にはミスをさせない流れにしたのですが、会話の流れ上「ミスった」方向に嘘をつきます)。


ゲーム作ってまして。
キャラクタの初期登録があるのですが、まだいろいろとできあがっていないので「一端テストデータ」でキャラクタデータを作成して、それ以降のプログラムを続けていきました。
作成も一段落しまして。
いざ「αテストで、社内の開発外の人たちに遊んでもらおう」としたら、開発中には出てこないバグの連続 orz


上述、実際には食い止めたのですが。似たようなケースで「実際にこけた」状況は、山盛りで見てるんですね。
で、思うんですが。
「マスターデータ」で、それが「エンジニアによるSQL直接発行なSE作業」であればよいのですが、そうでない場合「とりあえず登録部分未作成だからSQLで一端テストデータを作成してぶち込んで」は、そこそこいい確率で「後々トラブルを生む」んですね。
まさに「開発者にとって都合のいいデータになりがちだから」。


根本的に間違ってるのは「とりあえず登録部分未作成だから」の部分。
開発順番がおかしい。
開発のタスクを分解したら、次にやるのは、上述のような「無駄な足止め」が発生しないように、タスクの順番を適切に整理する。
そうすると「とりあえず登録部分未作成だからSQLで一端(自分にとって都合のよい)テストデータを作成して」っていう作業が減ります。SQL作るのに無駄で、その後もう一度テストする必要がある二度手間で、ダブルの無駄が防げます。


なので。「テストデータを作らなきゃいけない」ような開発の流れからは、とっととおさらばしたほうが、いろいろと心地よいです。


これとあわせて。
「新規作成時」に極端に有効なのが、おいちゃん通称「trancate祭り」。
trancate祭りは、以下の手順で行われます。


・やる日付を宣言する
・当日。以下の手順でDBを整理する
 ->drop database;
 ->create database;
 ->create table 各種
 ->「きちんと管理されている」マスタ系insert文の発行


おいちゃん的に(鬼畜)ポイント。「あえて」drop database前のバックアップをとらない*1
これをやる目的は、これもやっぱりコメントの通りで「create table文などの管理が継続して行われているかのチェックにもなるから」。あと、プログラム作成中に「おかしなデータがDBに混入すること」が、特に開発初期では多いので。その手の「ゴミデータ」で「間違って動かなかったり」「間違って動いたり」って系統の誤謬を一通り抹殺する意味も含めて。
印象的には、週1〜2週に1回くらいの頻度でやると、いろいろときれいになります。所用時間は、トラブルのヘッジも込みで、だいたい半日未満、くらい。


手法としては比較的荒っぽいですが、効果は結構がっつりとありますので。
興味がある方は、是非お試しくださいませませ。

*1:実際のところは。1回目2回目の祭りの時はとっておいたほうがよい場合も多いです、が、でもそれ以降はとらない方がいいと思う B-p