Gauche > Archives > 2011/07/21

2011/07/21 02:47:04 UTComasanori@twitter
#
@bleis shiroはインターフェースのデザインのやり方を知らない時はテストが試行錯誤の重りになると考えているのではないかと解釈しましたが、ラッパーで一層増やせば問題ないというのも確かにそのようです。Gauche部屋 に振ると良いかも
2011/07/21 03:43:11 UTCshiro
#
型の話もそうなんですが、Test firstでも、「何が欲しいのか皆目わからない」時には使い辛いですよね @omasanori @bleis
#
何が欲しいのか皆目わからないのにコードが書き始めてはいけない、という教えもありますが。でも、楽器で遊んでいるうちに曲の骨格が出来たりとか、インプロビゼーションとか、ゴールがはっきりしないけれど先に手を動かし始めちゃう、っていう作りかたって、広くみればそう珍しいものでもないと思う。
#
s/コードが/コードを/
2011/07/21 04:07:04 UTCshiro
#
いや、型に関してはそうでもないかな… 型レベルでの操作をいじってるうちに何かのインスピレーション、何か同型な構造だとか、そういったものを見つけて、それを満たす実装を後から書くってことはありそうだな。
2011/07/21 04:10:46 UTCbleis@twitter
#
何が欲しいのかわからない時に、実装を書くか、テストを書く(書こうとして何が欲しいか考える)かの違いだと思います。昔は前者だったのですが、今は意識して後者を選んでます。そうした方が後々楽なので。
2011/07/21 04:16:18 UTCshiro
#
@bleis そういうこともあるかなあ。出来るケースも考えられます。でもある程度実装というか感触が見えてる状態じゃないと、その欲しいものが本当に得られるものなのかってわからないですよね。感触が見えるところまで分解して作るのかな。
2011/07/21 04:23:21 UTCshiro
#
よくわからない問題を考える時に、具体例を挙げてみる、っていう方法はある。それがテストファーストに相当するんだと思う。一方で、新しい素材が手に入った時に、それでどういうものが作れるのか、どういうものを作るのがふさわしいのかっていうのは、素材の性質をある程度知らないことには何とも言えない。
#
まあでも、そういう場合であっても「仮の問題」を設定してそれを解いてみる、ってことはできるか。それならテストファーストが使えるなあ。そのテストは多分捨てることになるだろうけど。
2011/07/21 04:28:51 UTCbleis@twitter
#
NUnitの話になってしまって申し訳ないんですが、感触が見えるまではExplicitでテストを書いて行って、分解していくというのはよくやりますね。まぁ、作るものによってはTDDしにくいものはありますが、とりあえずはTDDでやってみてます。
2011/07/21 04:54:04 UTCshiro
#
入出力が具体的に例示できるようなのだといいんだけど。例えば数MBくらいのXMLファイル(でも何でもいいんだけど)がどかどかっとあって、そっから色々取り出したいんだけどどういう構造になってるかとかどういう取り出し方をすれば意味があるのかまだよくわからない、って時に、適当に色々フィルタかけたり変換かけたりしてどんな具合か見るんだけど、
#
そういうのはTDDでどうするかな。具体的なアウトプットを列挙するのは非現実的だから、何らかの不変条件をチェックする関数を書いてそれでassertするってことになると思うんだけど。でもその不変条件の具合を見るのに、一度変換かけてアウトプットを目視した方がわかりやすいなあとか思っちゃう。
2011/07/21 05:10:30 UTCbleis@twitter
#
そういう場合、どちらかと言うと仕様化テスト的に「まずはこの変換をやった時にどういう風にredになるか」を見る感じですかね。アウトプットを目視で確認するのはこの段階では同じですね。
2011/07/21 05:12:09 UTCshiro
#
ダミーのテスト結果を入れといて、実際の出力を見るって感じですか?
#
ダミーのexpected、と言った方がいいか。
2011/07/21 05:16:53 UTCshiro
#
そのへん、REPLで試行錯誤してる場合は経緯がバッファに残ってるから、それなりに固まってきたところでそっからコピーすればテストになるんで、最初にダミーテストを書く気が起きないって事情はあるかも。まあいずれテストは書くのだから最初から雛形のつもりで書き溜めとく、ってのもありだと思いますが。REPLがデフォでない言語では事情が全然違いそうだ。
2011/07/21 05:28:54 UTCbleis@twitter
#
そうです、ダミーのexpectedを置きます。REPLの有り無しは確かに影響ありそうです。
2011/07/21 20:17:19 UTCshiro
#
テストについて。ごりごりテストを書きながら思ったんだけど、自分的には最後に残るテストってのは例示の列挙よりももう少しシステマティックであって欲しいという傾向があるからかもしれない。仕様を探る段階で具体的な入力と出力のサンプルで考えれば、それを並べてテストにしておける、っていうのはわかる。
#
けれどいずれそういうテストはスクラップして、境界条件を突くようなデータセットを用意して不変条件をチェックするテストルーチンをばさっとmapする、っていうテストにしたくて、そしたら最初の段階での例示テストって別に財産にもならないよなあ、と思っちゃうのかも。
#
不変条件のチェックとか網羅的な組み合わせとか、そのへんは仕様が見えないと書きづらいし。