- テスト駆動開発はなぜ流行らなかったのか？2
824 ：デフォルトの名無しさん[sage]：2014/09/13(土) 00:00:52.79 ID:FW2AVG6W - （>>821の続き）
もちろんテスト駆動によって設計の改善を図ることはできる
ただし、それをするには(テスト手法の改善で終わらせず)発生したバグという問題に対して、
バグが生まれた原因を直接原因/間接原因/背景要因/根本原因へと深く追求することによって
再発防止策を考え、それを設計へ反映(フィードバック)させるという姿勢が重要になる
これをQA(品質保証)では「(設計による)品質の作り込み」と言う
残念ながら、この記事は問題追求と反映という考察のレベルがあまりにも浅はかすぎる
この記事を書いた和田氏がQAの基本すら知らずに記事を書いたのなら哀れではあるがしかたがない
しかし、もしQAの基本を知った上で記事を書いたのなら、悪意があると言わざるをえない
この記事で和田氏は設計について以下のように解説している：
設計は終わりのない世界です。そして、設計について考えすぎると、終わりがない世界に
踏み込んでいることに気づきにくくなります。このようなとき、テストの結果/ゴール/具体例から
考えることで「あれもできる、これもできるかも、ああいうやりかたもあるな」という
フワフワとした状態から、ピントのあった状態に戻ることができます。
つまり和田氏は「どうせおまえらには無理なんだから設計について深く追求するな、思考停止しろ、
それよりテストを動かしたほうが楽になれる、頭よりも手と目を動かせ、汗水流して働け」と
語りかけている（いくらか誇張が含まれているかも....）
まあ、もし本人がこんな誘いに喜んで乗りたいのなら、他人がとやかく言うべくじゃ無いだろな
でも、もしオマイラが学部卒以上であれば、知性とは真理の探求であることを学んできたんじゃないの？
（更に続くが、次で終わる）
|
- テスト駆動開発はなぜ流行らなかったのか？2
826 ：デフォルトの名無しさん[sage]：2014/09/13(土) 00:23:32.04 ID:FW2AVG6W - （>>824 の続き）
最後に、>>819 の三番目の記事「TDDとテスト容易性(試験性)の関係」だけど、
これは良いマトメになっているね
この記事ではソフトウェアの品質確保について「設計のブレークダウン」と
「インサイドアウトのTDD」という二通りのアプローチがあると定義している
自分の考え方は、前者になる
特に、TDDのデメリットとして挙げられた：
「テストコードと上流仕様とのトレーサビリティを保証するプロセスが通常考慮されない。」
ことが大きな問題だと捉える
つまり、TDDによるモジュール開発(=単体テスト工程)が終わったとしても、
次の結合テストでも品質が安定するのかそれともバグが多発するのか「予測できない」ことが問題だ
つまりモジュールの設計品質を保証できないというリスクを抱えてしまう
|
- プログラミング言語 Scala 10冊目
518 ：デフォルトの名無しさん[sage]：2014/09/13(土) 00:36:47.68 ID:FW2AVG6W - $ sml
Standard ML of New Jersey v110.76 [built: Fri Jul 12 16:57:10 2013]
- val a = 1;
val a = 1 : int
- val 1 = 2;
uncaught exception Bind [nonexhaustive binding failure]
raised at: stdIn:2.5-2.10
-
|
- 推薦図書/必読書のためのスレッド 74
89 ：デフォルトの名無しさん[sage]：2014/09/13(土) 00:39:57.01 ID:FW2AVG6W - >>84
たしかにまずいなw
>>80 は、GDP(国内総生産) に訂正だ
|