一匹残らず駆逐・・・

>>
JUnitは効率よくテストを行うためのツールであり、使うことが目的としてはならない
→1. テストが無いほうがいいということはないですね。どんなひどいテストでも、無いよりはずっといい。
<<
バグだらけのクソテストなんてないほうがいいと書いてあるだろ。
たぶんこういうことを言うやつは「ソフトウェアはすべて資産」と捉えて機能削減なんてもってのほか、と考えているに違いない。
だからモデルもコントローラーもなにもかもFATに肥大化していくプロダクトを抱えて残業ばかりすることを誇りと思っている。

>>
ユニットテストを行うにはプログラミングだけではなくソフトウェアテストのスキルも必要である
→2. 時間をかければだれでもできる。仕様で決まったとおりの挙動をするかどうか、リストアップして書いていけばいい。
<<
できねーんだよ。そんな幻想をいまだに信じているやつがいるとは。不勉強にもほどがある。
サリエリが5人集まってもモーツァルトのレクイエムは描けない。

>>
ユニットテストを行いながら、テスト対象を改善していく体制が必要である
→3. 悪い設計にしてしまったら、クラスをリファクタリングすることは受け入れなければならないが、なぜいい設計にできなかったのかをちゃんと反省しなければいけません。
<<
へぇ。こいつにとってはリファクタリングは受け入れなければならないものなのか・・・
で、いい設計にできなかったことを反省しなきゃならないわけだ。
まるで、プロジェクトがうまくいかなかったから仕様をしっかり予言して確実に的中させなければならないとかいってる連中みたいな言い分だな。
いい設計にできなかったんじゃなくてならないもんなんだっつの。最初から完璧な設計にできないからこのプラクティスがあるんだろうが。
教科書ちゃんと読んでる？

>>
ユニットテストのコストは非常に高い
→4. わずかなコードの変更でも、ほとんど常にテストを行わねばならない。そのたびにいちいちすべてのテストを人間がするなど、ありえない。手作業テストと比較したら、コストが低いと言い切ってしまってかまわない。
<<
そりゃー、おめーみてーに「誰でもできる」チェックリストを羅列したような「ひどいテスト」を描く人間の作るものはコストは低いわなｗ
つーかどんなテスト書いてんの？ちゃんと作ったことなくて教科書でちょっと勉強しただけで語ってるようにも思える。
たしかに教科書には手作業はコストがかかるから自動化してコスト削減、みたいなことを書いてあるけど、ここで論じているのはその一歩先である。

>>
優秀な開発者がユニットテストを行わなければ品質は高くならない
→5. 知能指数の低いプログラマこそ、ユニットテストをいっぱい書いて、品質を上げなければいけません。ただひとつの方法というほどじゃない。テストを書けばそれだけコードは信頼できるものなる。
<<
ならねーんだよｗｗ アホ中国人がどんだけアホテスト書いたところで品質は上がらないのｗ
「バグだらけのコードしか書けないプログラマが書いたテストコードはバグだらけ」って書いてあるだろうが。
ま、このへんの理屈は「どんなにひどいテストもあったほうがよい」という思考回路の人間にはわからないだろう。

>>
ユニットテストが適用しにくい部分も存在する
→6. 見た目のテストは難しい。何をもって正しく画面に映ってる、とするかは、悩ましい。しかし、モデルとビューの切り分けをしっかりして、できるだけビューのテストを少なくするとか、努力はできる。
<<
なんだこいつｗｗｗまったくわかってねぇｗｗｗ素人なのか？？
わからなすぎて抽象的な表現になってて真意がよく読み取れないけど、viewのテストもjsunitで1ページずつやろうとか言いそう。
とかく、そんな努力が無駄なんだよっていうエントリなんだけどこいつはまったくわかっていない。
「悩ましい」とかいっちゃってるけどこいつにはまともな顧客がいないんじゃなかろか。

>>
カバレッジはユニットテストを行う時の指標でしかない
→7. 数字あそびにかまけてはいけないが、ソフトウェアの進捗の指標としては、これ以上のものはないと考えます。
<<
おめーは数字遊びしすぎなんだよｗｗ実際に見てなくてもわかるわｗｗｗ
つーかおめーの進捗というものに"これ以上のもの"は存在しねーの！？
カバレッジを100％にしたらお仕事終了！？
そういうやつのことを「気がつかなかったことにして実装しない不届き者」って言ってんだよ気付けバカｗｗｗ
あーもう進捗会議で「カバレッジ100%になりました(ドヤァ)」とかやってるのが目に浮かぶわ・・・

>>
ユニットテストは繰り返し何度も実行することで効果がある
→8. テストを動かしてオールグリーンにすることは、快感なので、書いて満足という心配はしなくていいと思いますね。
<<
意味が全くわからん。こいつは技術者ですらなく、マネージャーもどきが本を読んでかじった程度の知識をひけらかしているだけじゃないだろうか。
ここで論じられているのは全てのテストが何度も実行されることが価値が高まるということ。
規模の小さいプロダクトや期間の短いプロダクトではそもそも何度もテストを実行することはない。
規模が大きいプロダクトで、全テストを実行するのは時間がかかる。そこでCIツールを使って全テストを定期的に実行できるようにすることが大切だ。
と書いてあるにも関わらず、なにが「オールグリーンにすることは快感だ」とか言っちゃってるのか。
こいつはグリーンになることがわかりきったテストを実行してグリーンになる度に快感を得ているのか？？
まぁたしかにそういうフェチはいるかもしれないが・・・
テストのサイクルってぇのはレッドであることが不快だからグリーンにする、という動機付けなわけだよ。
グリーンで満足を得るためじゃぁない。
こいつは「全てのテストコードを実行するのは面倒」になるほどテストを書いちゃいないしCIツールもロクに使えてない。
ひどいテストを並べてオールグリーンなのをドヤ顔で見せているだけである。

>>
ユニットテストだけでは不十分なので、インテグレーションテストも必要
→9. 結合テストとユニットテストの境界線は、よくわかりません。new Main().invoke(new File("macro")); みたいな一行のユニットテストだって、見ようによっては結合テストに見えるかもしれません。
<<
あー、わかんないだろうね。そもそもそういう発想がないだろ。
なにを作るべきか、なにをするべきかもわかってないから自分が単体テストをやっているのか、結合テストをやっているのかすらわからないんじゃないかな。
・・・つーかその境界線がわからないのって致命的だろｗｗｗ

>>
そのプロジェクトでユニットテストの効果が充分にあるかを検討すべき
→結局、私は、どんなプロジェクトにもユニットテストは有効と信じます！　自動テストが要らないソフトウェアなどソフトウェアと呼ぶに値せず、プロジェクトと呼ぶには小さすぎる！
<<
迷惑だ。
っていうかユニットテストの話をしてんのになに自動テストって。
結局こやつにとってユニットテストってのは自動テストであるという認識ってこと？
すなわちイエスマンと同じ自動化厨ってこと？
なんでもかんでも自動化させたがってめったに使わない余計なもんに時間とコストをかけたがる系？