テスト駆動開発はなぜ流行らなかったのか？
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2013/12/22(日) 16:04:07.02みんなやらなくなりますよね。
0002デフォルトの名無しさん
2013/12/22(日) 17:24:49.21そこを省いたりミスしたりすると意味がなくなる
0003デフォルトの名無しさん
2013/12/22(日) 23:08:52.060004デフォルトの名無しさん
2013/12/22(日) 23:34:32.48クラス毎とかでテスト作ってるプロジェクトって馬鹿でしょ
0005デフォルトの名無しさん
2013/12/22(日) 23:42:29.06挙動の隅々まで外から見えにくいとか
そういうのはテストつけとくと安心
0006デフォルトの名無しさん
2013/12/23(月) 00:33:43.02それは別に後からテストつければいいでしょ？
システムってのは、画面周りのような単純だけど数が多い部分と、
画面に配置するようなパーツみたいに複雑だけど作るのは一回の部分とに分かれる。
単純で数が多い部分は、こう書いたんだからこう動くに決まってるやん？って言うぐらい単純になる。
例えば言えばSQLでorder by書いたんだからその順に並ぶの当たり前じゃんみたいな。
そんなものに対して、データ用意してこの順番に出力される。みたいなテストを書くのは意味が無い。
だいたいなんのテストしてるのかわからんし。
複雑だけど作るのは一回みたいな部分は、複雑だから試行錯誤しないといけない。
それなのにテストを書いたら、テストを何度も書き直さないといけなくなる。
テスト駆動ではなく、作りながらテストを書くほうが効率がいい。
0007デフォルトの名無しさん
2013/12/23(月) 00:47:14.92責任も現場に丸投げ。
0008デフォルトの名無しさん
2013/12/23(月) 01:52:33.36特徴的なテストデータを用意して動くかどうか確認しながら作るなんて、演習の大学生でもやってる
スケルトン用意してユニットテストのコード埋めたりするような大げさなやり方が流行ってないからといって、テスト駆動開発が流行ってないと言うのはいかがなものか
正確には、「テスト駆動開発は、巨大なシステムも大学の演習の10行コードも、なぜ同じようなやり方が流行っているのか」ではなかろうか
0009デフォルトの名無しさん
2013/12/23(月) 01:55:43.59そう思ってたら、javaのバージョンアップでやられた
0010デフォルトの名無しさん
2013/12/23(月) 02:09:17.21演習に大学生ぐらいしかやらないの間違いだろ？
そりゃ演習なら、準備して何度も同じものを多くの人にやらせるわけだから
最初に出題と答えを用意できるだろうさ。
0011デフォルトの名無しさん
2013/12/23(月) 02:11:01.01回り道してでも時間をかけてやるってのが違う所だな。
0012デフォルトの名無しさん
2013/12/23(月) 03:09:27.98お前らみたいなスーパープログラマには無用の長物
0013デフォルトの名無しさん
2013/12/23(月) 03:12:31.870014デフォルトの名無しさん
2013/12/23(月) 03:12:45.26スーパープログラマ←無職
0015デフォルトの名無しさん
2013/12/23(月) 03:31:40.30だけど、テスト駆動ではテストを書かないとプログラムが作れない。
必要がないようなテストを省くとテスト駆動にはならなくなる。
0016デフォルトの名無しさん
2013/12/23(月) 04:00:59.07一体何をテストするのか？ Hello Worldと書いたのだから
Hello Worldと表示するのは当たり前だろ？と。
極端な例と思うかもしれないが、--helpってやったらヘルプが
表示されるテストとかさ、なんのテストを先に書けばいいのかわからない。
テストにヘルプ内容書いて、それをまたコードに同じこと書くのか？
年月を入力して2月の末日が何日かを求めるコードのテスト駆動は書く意味があるだろう。
でも2月以外の末日はどうなんだ？ テストコードに2月以外の末日を月と日付の
ハッシュテーブルで書いておいてそれをコードにコピペするのか？
すべての場合においてテストが必要とは限らないのに、
テストがなければコードが書けないというのが無理あるんだよ。
0017デフォルトの名無しさん
2013/12/23(月) 05:34:50.22アホみたいなプログラムもテストがあるとありがたいというのは、既存コードを携帯に移植するときに思い知らされたわ
ユニットテストは、コードのテストだけではなく、環境と基本ライブラリとコンパイラのテストでもある
0018デフォルトの名無しさん
2013/12/23(月) 05:37:16.250019デフォルトの名無しさん
2013/12/23(月) 07:06:10.70仕様書がうんこでテストデータ作成すら無理ゲーとか
いろいろあるよね…
0020デフォルトの名無しさん
2013/12/23(月) 07:55:59.52TDDのやり方分かってねえだろ
0021デフォルトの名無しさん
2013/12/23(月) 12:43:34.50組み込みだとメモリ足りなくてスタックオーバーフローとかあるわ
0022デフォルトの名無しさん
2013/12/23(月) 13:25:55.23YAGNIである。
0023デフォルトの名無しさん
2013/12/23(月) 13:44:00.29最初から組み込み向けの話だろ
YAGNIって何だよ、カスが
0024デフォルトの名無しさん
2013/12/23(月) 13:59:39.54携帯に移植って書いてるのが読めないの？
0025デフォルトの名無しさん
2013/12/23(月) 14:58:11.02へえ
0026デフォルトの名無しさん
2013/12/23(月) 17:47:42.00仕様が変わるとテストも変わる
次々と変わる仕様に対応してテストも次々と変更していくのは工数の無駄でしかないと思うの
0027デフォルトの名無しさん
2013/12/23(月) 17:59:41.440028デフォルトの名無しさん
2013/12/23(月) 19:02:24.23首根っこを押さえれば被害は少ない
0029デフォルトの名無しさん
2013/12/23(月) 20:49:42.25テストを変更仕様へ・失敗→ソース変更・成功みたいな順で
0030デフォルトの名無しさん
2013/12/23(月) 21:01:15.80テスト"駆動"がだめという話。
テストはアプリを正しく作る上で必須のものではない。
省略しても正しく動くアプリは作れる。
だけどテスト駆動開発だと、テストを最初に書かないといけない。
これが大きなネックになる。
テスト駆動はコードの書き方の一つ
一つの開発の中で、この関数（クラス）はテスト駆動で作ったが
こっちはテストそのものがないみたいに、バランスよく使うもの
0031デフォルトの名無しさん
2013/12/23(月) 21:12:35.30> テストを変更仕様へ・失敗→ソース変更・成功みたいな順で
それ、意味があるのか？ってことになるか、
大変すぎるかのどちらかになることが多い。
意味があるのか？っていうのは簡単な修正の場合。
色が赤から青になりました。みたいな場合、
テストで色を青に変えて、コードでも青に変える。
単に変更する箇所が二つになっただけにしか思えない。
大変すぎる例は、変更の影響範囲が広い場合。
ある関数を変更するとして、その関数に依存している部分がたくさんある時、
そのすべてのテストを正しくを変えるのは難しい。どうしてもコードを変えた後に
通らなくなったテストを修正することになる。
0032デフォルトの名無しさん
2013/12/23(月) 22:02:16.80逆に中国人はテストさえすり抜ければ何でもいいという風になるんだよ
0033デフォルトの名無しさん
2013/12/23(月) 22:10:15.70そのテスト用のデータを再利用できるように保存するかどうかの話だと思うのだが
かたくなにテスト書かないって言ってる人はプログラムのコード書いて使わないの？
0034デフォルトの名無しさん
2013/12/24(火) 00:47:50.31ユニットテストと受け入れテストの混同
0035デフォルトの名無しさん
2013/12/24(火) 00:58:19.58コンパイル通ったらコーディング完了で、
テストフェーズになるまで一切動かさないという人はよくいる。
0036デフォルトの名無しさん
2013/12/24(火) 01:08:47.480037デフォルトの名無しさん
2013/12/24(火) 01:24:01.21言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0038デフォルトの名無しさん
2013/12/24(火) 01:26:21.27少し書き足すごとにアプリを起動して動作確認できるような規模の話じゃないんだよ
0039デフォルトの名無しさん
2013/12/24(火) 06:07:50.17というか、その少し書き足した分がそれなりに正しいかをその場で確認しないの？
どんな規模の開発でも、それくらい確認するでしょう
0040デフォルトの名無しさん
2013/12/24(火) 13:35:36.75テストフェーズで検出ゼロになるとマズイと止められた
あの夏の記憶
0041デフォルトの名無しさん
2013/12/24(火) 14:53:58.83そこそこ規模の大きい開発だとコーディングしたプログラマがコンパイルやテストをする事はないよ
0042デフォルトの名無しさん
2013/12/24(火) 15:01:02.18> そこそこ規模の大きい開発だとコーディングしたプログラマがコンパイルやテストをする事はないよ
相当特殊な環境ならそういうこともあるかもしれないが、普通はどんなに大規模なプロジェクトでも開発者テストは行われる。
また、今時VCSを使わない大規模プロジェクトは考えにくいが、VCSを使うなら、コンパイル不可なコードをコミットするのは
犯罪行為とも言える。すなわち、少なくとも開発者自身がコンパイルOKなのを確認する。
そして大抵は、開発者テスト済みでなければコミット不可というルールを付けているはずだ。
0043デフォルトの名無しさん
2013/12/24(火) 16:19:59.63なかったら悪夢
それでも作成者本人が動作を見れば一瞬で気づくレベルのミスまで
毎回別担当者が再現手順をしぼりこんで〜とかやってられん
0044デフォルトの名無しさん
2013/12/24(火) 16:44:56.07> ある関数を変更するとして、その関数に依存している部分がたくさんある時、
それは設計が悪いのではないだろうか。
0045デフォルトの名無しさん
2013/12/24(火) 19:36:06.47ビルド通るまで気合でスタブ書くしか
0046デフォルトの名無しさん
2013/12/24(火) 22:19:47.79ちゃんとしたプロジェクトならPC上でモジュールの動作確認できるような仕組みを作るけど、
世の中にはちゃんとしてないプロジェクトの方が多いからね。
0047デフォルトの名無しさん
2013/12/25(水) 00:13:17.77多くの場合、"関数"は"使いまわす"ものなので、
仕様変更で関数を変更したら、修正しなければ
いけないところは複数ありますよ。
※「仕様変更したという前提の話です(>>29)」って
書いておかないと的はずれなレスしてきそうなので書いときます。
0048デフォルトの名無しさん
2013/12/25(水) 00:15:27.88100歩ゆずってリンクはしないとしても、コンパイルくらいはするでしょ
0049デフォルトの名無しさん
2013/12/25(水) 00:22:50.40そもそも仕様変更するのが前提なのがソフトウェアだから、断り書きは必要ないですよ
0050デフォルトの名無しさん
2013/12/25(水) 00:35:25.98コンパイルってなんですかぁ？ by Ruby使い
0051デフォルトの名無しさん
2013/12/25(水) 00:46:42.900052デフォルトの名無しさん
2013/12/25(水) 00:54:07.22Rubyならなおさら、書いた直後になにかしらの確認をしないという状況が思い付かないのだが
0053デフォルトの名無しさん
2013/12/25(水) 01:48:57.09設計が悪いような気がしてならない。
> ある関数を変更するとして、その関数に依存している部分がたくさんある時
ある関数を変更しても、その関数に依存している部分の仕様は変わらない
→機械的にリグレッションテストが実行できる
のが普通ではなかろうか。
0054デフォルトの名無しさん
2013/12/25(水) 01:57:59.97○ある関数を変更しても、その関数に依存している部分の仕様は変わらないように修正しないといけない
そのため>>31で書いたように
> そのすべてのテストを正しくを変えるのは難しい。どうしてもコードを変えた後に
> 通らなくなったテストを修正することになる。
0055デフォルトの名無しさん
2013/12/25(水) 01:59:40.410056デフォルトの名無しさん
2013/12/25(水) 02:12:24.81その要求を自動で検証できる形で明示的に残さなくてもテスト駆動です
0057デフォルトの名無しさん
2013/12/25(水) 02:30:12.03関数aをモジュールA,B,Cで参照している場合、関数aを変更してもモジュールA,B,Cの仕様は変わらない(ように調整する)
ならば、モジュールA,B,CのテストTA, TB, TCは変更しなくても済むのではないか？
0058デフォルトの名無しさん
2013/12/25(水) 02:39:04.70変更するのはテストじゃないよ。
関数aを変更した時、モジュールABCの仕様を変わらないようにするために
モジュールABCに含まれる関数aの呼び出し部分を修正する必要がある。
テスト駆動というのであれば、先にモジュールABCの関数a呼び出し部分を
修正しなければいけないが、関数aを使用しているモジュールABCの存在が、
特に動的言語の場合はテストを実行するまでわかりづらいから
関数aを修正した後にテストコードを実行して失敗したテストを修正することになる。
>>29が言っているような、仕様変更の際に
「テストを変更仕様へ・失敗→ソース変更・成功」という
流れは現実的ではない。
0059デフォルトの名無しさん
2013/12/25(水) 08:16:10.930060デフォルトの名無しさん
2013/12/25(水) 10:27:21.95答えわかってるしイテレーティブの気持ちいい流れを害される気分
他の人が仕様の代わりにテストを作ってくれてその正解コードを書くっていうなら気持ちよくできるけど
0061デフォルトの名無しさん
2013/12/25(水) 10:40:28.97> 関数aを変更した時、モジュールABCの仕様を変わらないようにするために
> モジュールABCに含まれる関数aの呼び出し部分を修正する必要がある。
関数aが変更された時に、関数aの呼び出し部分を修正する必要があるような設計が
駄目なんじゃないのって言われてるのわかってる？
> 関数aを修正した後にテストコードを実行して失敗したテストを修正することになる。
考え方が逆だよ。
関数aの変更が、モジュールABCのテストに影響を及ぼすとしたら、まずテストをリファクタリングする
必要があるかを考慮する。
どうしても関数aの変更の影響をモジュールABCのテストから断ち切れない場合は、まずそのテストが
そのままで良いかどうかをチェックする。
そうしないと、「本来は期待値が変わるはずだったのに変わっていない」というバグを検知できない。
まずテストを実行してみて、失敗したテストを修正するというのは下の下の策。
0062デフォルトの名無しさん
2013/12/25(水) 10:47:06.00関数の仕様が変更されたら云々ってのは全く意味を持たない議論。
0063デフォルトの名無しさん
2013/12/25(水) 11:20:39.09> テストは関数の仕様が決まった後の「内部実装」の品質を保証するための手段だから。
ここTDDスレなんですが。
0064デフォルトの名無しさん
2013/12/25(水) 11:26:18.74> テストは関数の仕様が決まった後の「内部実装」の品質を保証するための手段だから。
> 関数の仕様が変更されたら云々ってのは全く意味を持たない議論。
意味がわからん。
変更後の仕様が決まったら、その「「内部実装」の品質を保証するための手段」じゃないの？
0065デフォルトの名無しさん
2013/12/25(水) 21:16:34.62> 関数aが変更された時に、関数aの呼び出し部分を修正する必要があるような設計が
> 駄目なんじゃないのって言われてるのわかってる？
ほらな。
> ※「仕様変更したという前提の話です(>>29)」って
> 書いておかないと的はずれなレスしてきそうなので書いときます。
って書いたのにこんなこと言い出す。
仕様変更でモジュール内部で使用している定数が、ファイルからの読み込みだったのが
データベースからの読み込みに変わったがそのモジュールはデータベース
コネクションオブジェクトを持っていなかったから渡さないといけない。
このモジュールを使っている全てのコードを修正する必要がある
とかあんだろ。
006665
2013/12/25(水) 21:18:58.16コードを修正してから落ちたテストを直すほうが正確で速い。
0067デフォルトの名無しさん
2013/12/25(水) 21:39:20.67でも、テストは書き換えなくてもいいよね？
あるモジュールがファイルを使うかDBを使うかで、
そのモジュールを使ってるコードの仕様が変わるのはおかしいわけだし。
0068デフォルトの名無しさん
2013/12/25(水) 22:00:06.34先を見通してコードがかけないから修正がいるわけだしテストも同様にそうなるよ。
0069デフォルトの名無しさん
2013/12/26(木) 00:39:09.52テストではなくコードを中心にすえるのは内包表記
内包で数学が大コケしたのを知ってれば、テストを先に書く大切さが分かる
0070デフォルトの名無しさん
2013/12/26(木) 12:50:25.07> このモジュールを使っている全てのコードを修正する必要がある
という設計が駄目だって言われてるのがまだわからんのか
0071デフォルトの名無しさん
2013/12/26(木) 13:58:40.19ストレージだかテーブルだかを介するように直しておくのが手順だべ
0072デフォルトの名無しさん
2013/12/26(木) 15:42:56.89直交性とか凝集度と結合度についてググれ
0073デフォルトの名無しさん
2013/12/26(木) 18:52:41.98テストがぶっこわれる動的言語でTDDは無茶です。
0074デフォルトの名無しさん
2013/12/26(木) 19:22:19.98壊れる場所をきちん検出できることは利点じゃないのか…
逆に言うと、メソッド名の変更で不具合が出る場所を何で検出するの？
0075デフォルトの名無しさん
2013/12/26(木) 20:32:31.28まともな仕様が書けないのに、テスト方法が決められるわけはないわな。(w
0076デフォルトの名無しさん
2013/12/26(木) 20:41:12.43書くべきモノは分からなくても、書いてるつもりのモノは分かるから、仕様は書けなくてもテストは書ける
0077デフォルトの名無しさん
2013/12/26(木) 21:52:20.20動的言語ではそれができないからTDDが必要なんじゃないの？
0078デフォルトの名無しさん
2013/12/26(木) 22:00:12.92コンパイラが見つけることができるエラーは限られている
0079デフォルトの名無しさん
2013/12/27(金) 02:01:41.93１．プログラマが製造
２．テスターがテスト
３．プログラマが修正（２へ戻る）
これのうち１と３は同じ人間がやってもいいけど、２が同じ人間じゃまずいだろ
それにプログラマがコンパイルまでやってたら生産性落ちる
0080デフォルトの名無しさん
2013/12/27(金) 02:05:09.190081デフォルトの名無しさん
2013/12/27(金) 02:22:01.03テストをする義務があるのは、そのコードを書いたプログラマ
理由は、書いた直後が一番バグを見つけるのが簡単だから
バグのないコードを作るのが目的なら、プログラマは、時間がゆるす限り、できるテストは書いたその場ですべてやる義務がある
テスターがやることができるのは、ブラックボックスをつついて奇跡的にたまたま出るエラーを待つだけだから、そもそも能力的に義務をおう立場にない
すべてを知ってる人間とは違う視点から確認するだけ
だから、
１．プログラマが製造
２．プログラマがありとあらゆるテスト
３．プログラマが修正（２へ戻る）
４．テスターがブラックボックステスト（プログラマが盲点にしていた視点を指摘して３へ戻る）
５．納品
0082デフォルトの名無しさん
2013/12/27(金) 08:00:46.03正常条件で動くテストと実装を優先するテスト駆動は特にそうなる
だからこそコードレビューが重要なんだから
0083デフォルトの名無しさん
2013/12/27(金) 08:05:02.82× 仕様は書けなくてもテストは書ける
○ 仕様は書けなくてもテストのつもりのコードは書ける
0084デフォルトの名無しさん
2013/12/27(金) 16:11:30.27> 自分のコードのバグを見つけられるなんて幻想だよ
> 正常条件で動くテストと実装を優先するテスト駆動は特にそうなる
お前だけだよ
0085デフォルトの名無しさん
2013/12/27(金) 17:46:22.29「俺が作って俺がテストしたから大丈夫」とか言うわけ？
0086デフォルトの名無しさん
2013/12/27(金) 17:49:25.72話が飛躍しすぎ。
最後まで開発者テストだけしかしないなんて誰も言ってない。
0087デフォルトの名無しさん
2013/12/27(金) 17:51:01.590088デフォルトの名無しさん
2013/12/27(金) 17:53:46.47コンパイルして修正してそれで行数増えるのか？
0089デフォルトの名無しさん
2013/12/27(金) 17:59:55.110090デフォルトの名無しさん
2013/12/27(金) 22:45:02.96増えるよ？
0091デフォルトの名無しさん
2013/12/27(金) 22:50:08.89> でも、テストは書き換えなくてもいいよね？
> あるモジュールがファイルを使うかDBを使うかで、
> そのモジュールを使ってるコードの仕様が変わるのはおかしいわけだし。
書き換える必要あるぞ。
あるモジュールがファイルを使っていたが、
それがデータベースを使うようになったら
コネクションオブジェクトが必要になる。
そのコネクションオブジェクトは内部で作るわけではなく外部から渡される。
（当たり前。一つのアプリでいくつもコネクション接続するな）
そしてモジュールは外部から渡されるコネクションに依存したコードになるから
テストコードは、そのモジュールにコネクション（のモック）を渡すように修正しないといけない。
0092デフォルトの名無しさん
2013/12/27(金) 22:52:28.35> という設計が駄目だって言われてるのがまだわからんのか
じゃあ、
(質問1) >>91の例をどうすればいいのか？
(質問2) 問題があるコードを修正するのがリファクタリングの目的の一つだが、
問題のあるコードがすでにある場合はどうするのか？
最初から間違いをしなければいいという回答は
ありえないので間違った回答だる。
0093デフォルトの名無しさん
2013/12/27(金) 23:08:05.890094デフォルトの名無しさん
2013/12/27(金) 23:09:23.76> 自分のコードのバグを見つけられるなんて幻想だよ
自分のコードのバグを他人が見つけられるってのも幻想だよ。
そもそもバグが入り込む原因の一つはコードが不必要に複雑ってのがある。
複雑なコードを他人がコードレビューした所で、時間がかかるだけで実りがない。
優れたレビューアなら、コードが複雑だからという理由で、読まずに突き返すことが出来るだろうが、
それは、コードを書く人の技術力 ＜ レビューする人の技術力 というのが前提になる
これは、ホワイトボックスなやりかただが、ブラックボックスだとさらに問題が大きい
ブラックボックスだと、コードのクラス・関数レベルの詳細仕様は存在しないのが普通
現実として正常系程度しか書かれていない仕様がほとんどでアプリの仕様には詳細な動作は記述されない。
そうすると何をテストすればいいのかわからない。
例えば、項目A(3パターン)、項目B(3パターン)、項目C(3パターン)、があるとき、
9パターンをテストすればいいのか27パターンテストすればいいのかわからない。
仕様からは9パターンと読めても、コードがコピペされ27パターン相当になってるかもしれない。
こういうのは実際にコードを書いた人が指示をだすしかないが、そうするとコードを書いた人が
テストすべきと思ったことしか書かないので、結局自分でテストしているのと同じになる。
だから理想としては、ホワイトボックスできる力を持ったテスターがブラックボックステストをするのがいいが、
テスターの技術力は、コードを書くよりも高い技術力が必要だねってことになる。
これは正しい事実であるが、現実としてはなぜかテスターは簡単な単純作業ということになり優秀な人はアサインされない。
0095デフォルトの名無しさん
2013/12/27(金) 23:19:03.560096デフォルトの名無しさん
2013/12/27(金) 23:29:56.71俺は１日に１度すらビルドされないような大規模なの想定してたんだけど
0097デフォルトの名無しさん
2013/12/27(金) 23:32:00.90都合のいい例しか想定しないｗ
0098デフォルトの名無しさん
2013/12/27(金) 23:34:09.33そのコードを書いた直後でそういう類のコードでどういうミスをしやすいか熟知している自分と、コーディングの仕様書以外一切しらされずにある日いきなりコードだけつきつけられる赤の他人と、コードのバグを「見つけやすい」のはどっちでしょうかね
0099デフォルトの名無しさん
2013/12/27(金) 23:36:37.56それは大規模だからではない。
ビルドが困難だから一日に一度すらビルドしないんだ。
テスト駆動の話とは無関係に
少ない修正を重ねて開発するという方向に
世の中はシフトしている。
ビルドもテストも自動化され
修正をマージするたびにコードはビルドされる。
それは一日になんども行われる。
ビルドとテストの回数を増やすことが品質の向上につながる。
訂正
× 俺は１日に１度すらビルドされないような大規模なの想定してたんだけど
○ 俺は１日に１度すらビルドされないような古臭い未熟な開発を想定してたんだけど
といってるようにしか見えません。
0100デフォルトの名無しさん
2013/12/27(金) 23:37:18.19「俺が作って俺がテストしたから俺がこの時間内と技術で見つけられるバグはすべて見つけた。嘘だと思ったらそのテストコードがあるからあんたもそのテストを再現できます」と言えばいい
0101デフォルトの名無しさん
2013/12/27(金) 23:39:38.83学生の頃プログラマのバイトをして最初の仕事がそれだったわ。
（当時趣味でプログラム書いていて、プログラミングはできて）
仕様も何もわかっていない。
いきなりテストしてと言われて
「一体何をテストすればいいの？」ってなった。
当然まともな仕様書もなかった。
キーボードバンバン叩いてテストしましたよ。
それだけで落ちたりしたのでテストになりましたけど:P
0102デフォルトの名無しさん
2013/12/27(金) 23:39:58.53例えば、ビルドを年に1回しかしなくて、そのビルドを失敗したら1年間の給料ゼロだと言われても、あなたはコード片ごとにテストしませんか？
0103デフォルトの名無しさん
2013/12/27(金) 23:41:13.35上司「俺がプログラムなんか読めるわけがないだろ！エビデンス（キャプチャ画像）持ってこい！」
0104デフォルトの名無しさん
2013/12/27(金) 23:47:26.19上司の目の前でテストのスクリプト実行すればいい
0105デフォルトの名無しさん
2013/12/27(金) 23:49:42.84そんな条件で仕事を引き受ける奴はいない
バカじゃないの
0106デフォルトの名無しさん
2013/12/27(金) 23:56:41.32実機がまだ完成してないとか、保守でシステム止められる日が年に1日しかないとか、インフラ系は普通にそういう仕事がありますよ
0107デフォルトの名無しさん
2013/12/27(金) 23:57:00.65大規模だったら何がどう変わるんだ？
0108デフォルトの名無しさん
2013/12/28(土) 00:12:35.81大規模だったら、全体を把握しにくくなって、バグが混入したときに見つけるのが不可能になるから、細かくて執拗なテストが必須になると思うのは俺だけか…
0109デフォルトの名無しさん
2013/12/28(土) 00:25:37.590110デフォルトの名無しさん
2013/12/28(土) 00:30:11.40バグを防ぐのが目的なら、極端な例でも普通の例でもテストがあった方がよいのは変わらないと思うが
0111デフォルトの名無しさん
2013/12/28(土) 01:03:28.22ビルドできなくて〜というのは本筋ではない
0112デフォルトの名無しさん
2013/12/28(土) 01:08:27.89テスト駆動の実態は60年前からある
言語の構文そのものや標準APIｂﾉテストのバッャ`をしやすい仕荘gみを入れたのｂｪ最近で、それｂﾉ「テスト駆動＝vという名前を封tけたのが最近ｂﾆいうだけの話
0113デフォルトの名無しさん
2013/12/28(土) 01:09:27.58> 言語の構文そのものや標準APIにテストのバッチをしやすい仕組みを入れたのが最近で
それはテスト（ユニットテスト？）であって
テスト駆動ではない
0114デフォルトの名無しさん
2013/12/28(土) 01:17:20.86XPが流行った時に、スケルトン作ってテストしながらコード埋めてくスタイルが悪くないスタイルだと明文化されて、
それと時を同じくして、コードの真横に特別な環境を用意することなくテストコードを付ける仕組みが出てきた
ということなので、最近のテストしやすい言語仕様とテスト駆動とセットだよ
0115デフォルトの名無しさん
2013/12/28(土) 01:18:15.820116デフォルトの名無しさん
2013/12/28(土) 01:23:55.96「テストコードを書いてからコードを書く」で定義してる人もいる
「書いたコードの正しさをすぐにテストによって確認する」という定義でも問題ないかと
0117デフォルトの名無しさん
2013/12/28(土) 01:29:24.17それなんのことだよ？
言語名と、その仕組の名前を言ってみ。
そうすりゃ時代がわかるからさ。
0118デフォルトの名無しさん
2013/12/28(土) 01:40:54.73smalltalk以外の普通の言語が、QuickCheckとかxUnitを仕様や標準APIに取り入れたことだよ
javaのassertTrueとかアノテーションまで入れるなら、Cのassertも入れたくなるので、この場合はC言語よりもっと前の60年前までさかのぼることになる
0119デフォルトの名無しさん
2013/12/28(土) 01:52:42.99> それと時を同じくして、コードの真横に特別な環境を用意することなくテストコードを付ける仕組みが出てきた
> smalltalk以外の普通の言語が、QuickCheckとかxUnitを仕様や標準APIに取り入れたことだよ
はっきりさせよう。
jUnitが 1998年のはじめにリリースされて
そのあとの1999年にXPが発表された
テスト駆動の発表はその3年後、jUnitの登場からは5年後の2002年である。
0120デフォルトの名無しさん
2013/12/28(土) 03:16:55.65テスト駆動の発表が2002年というのには異和感がある
1946年説を支持する
ちなみにJUnitはいまだにjavaの仕様や標準APIじゃないでしょう
0121デフォルトの名無しさん
2013/12/28(土) 03:27:24.370122デフォルトの名無しさん
2013/12/28(土) 03:28:02.71全部同じ時期じゃん。
0123デフォルトの名無しさん
2013/12/28(土) 03:33:23.17まずアサート書いてコードを埋めていくという発想が1946年 by チューリング
0124デフォルトの名無しさん
2013/12/28(土) 03:43:42.82それはどの資料の話ですか？
無理矢理なこじつけは要りません。
0125デフォルトの名無しさん
2013/12/28(土) 03:53:57.18まずアサート書いてコードを埋めていくのはテスト駆動開発じゃないという方がこじつけのような気が…
0126デフォルトの名無しさん
2013/12/28(土) 04:49:45.43一体どこから出てきたんですか？
その考えが普及したのは、テスト駆動ということが生まれたつい最近の話。
0127デフォルトの名無しさん
2013/12/28(土) 06:47:50.52つい最近までは、アサートはいつコードの中に書いていたのだろうか…
0128デフォルトの名無しさん
2013/12/28(土) 09:22:37.07この書き方だとQuickCheckがSmalltalkで生まれたかのように見えるけど
実際はHaskell由来
こういう数理的アプローチはダサイSmalltalkからは出てこない
0129デフォルトの名無しさん
2013/12/28(土) 09:52:28.06アサートは実行コードの中に
エラーだったら止まるものとして
書く物のはずだが？
0130デフォルトの名無しさん
2013/12/28(土) 10:15:06.910131デフォルトの名無しさん
2013/12/28(土) 13:59:40.03softwareより前の時代の話はいらんよ
0132デフォルトの名無しさん
2013/12/28(土) 14:35:43.97まず大前提として、アサートは納品時には無視されてコンパイルされるので、例外処理のようなエラー検出装置ではない
開発してる最中に、あり得ないエラーのときにそれを検出するモノ
つまりテスト
0133デフォルトの名無しさん
2013/12/28(土) 16:16:59.440134デフォルトの名無しさん
2013/12/28(土) 16:26:52.69そういう場合は、他に作ったテストコードも納品するよね
0135デフォルトの名無しさん
2013/12/28(土) 17:32:29.55どんなミスするかわかってるならテストなんて必要なくて最初から完璧なコード書けばいいじゃん
仕様もしらず読み解けないほどの分量のコードをいきなりテスターに任せる事自体間違ってるわ
バグをいれたままテストを通り抜けさせようとしてるようなもんだ
0136デフォルトの名無しさん
2013/12/28(土) 17:44:53.90もしかしたら実務経験がない学生かもしれないから言っておくけど、
実は、自分がどんなミスするか分かっていてもそのミスをしてしまうのがプログラマなんだ…
仮に、ミスするのが1000に1回だとしても、10000作ればミスが10個散らばるわけです
0137デフォルトの名無しさん
2013/12/28(土) 17:47:40.71個々が満足いくまで品質をあげてから次の人へ渡す
現実
時間がないから書いたらすぐコミットしろ
暇な時
一応、正常終了と異常終了はテストしといた
0138デフォルトの名無しさん
2013/12/28(土) 18:01:57.63ようするに、「テストを書いてから」ってのは、時間とコストの見積もりするときにテストを書く時間を入れろってことなんだよ
その意味で「まずテストを全部書き終わってからコーディング」を業界標準にするように圧力かけてほしいと思う
0139デフォルトの名無しさん
2013/12/28(土) 18:22:06.610140デフォルトの名無しさん
2013/12/28(土) 18:24:55.43仕様書を書かない現場にテストを書けといっても不可能
そもそも、設計書・仕様書を書く文化すら根付かなかったのに
テストなんて書くわけがない
ほとんどの現場で行われているテストはエクセルシートに書かれた
「値：1234を入力して実行、結果:5678が出力される＝○」みたいなレベルでしょ
後追いですらテストコード書かないのに最初に書くなんてありえない
0141デフォルトの名無しさん
2013/12/28(土) 18:27:46.93自動で弾けるところは弾く
どうしても人の手でテストしなきゃいけない所もあるけど
そういう部分をなるべく減らす為の手法
テストを書く暇があれば人の手でテストしたほうが早いと勘違いしてる奴は
それこそコードが修正されない前提でものを言ってる
0142デフォルトの名無しさん
2013/12/28(土) 18:42:04.57そもそもあるレベルより上のプログラマじゃないと自動テストしないから
職場によっては、テストコード書いてるの見つかったら「余計なことで時間潰すな」だから
0143デフォルトの名無しさん
2013/12/28(土) 18:52:56.46設計書・仕様書を書く文化すら根付かなかった理由は、原理的にコーディングする前に仕様書を定義できないから
まず前提として、仕様書を書いて上流から下流まで一直線に建築みたいにコーディングする手法が提唱されていて、それを学校でも教えてた
しかし、それが破たんして、XPとかプロトタイプ開発とか「仕様書すらも」同時に開発していくスタイルが提唱された
(提唱された の意味は、過去に成功したプロジェクトはそうやってたということね)
コーディングする人は、開発途中は常にテストをしている
なので、「プログラマは常にテスをしているが、それが再利用できる形のテストではない」が現状
0144デフォルトの名無しさん
2013/12/29(日) 01:40:50.94いや、それはそうだけど、
そのテストはxUnitともテスト駆動とも
なんの関係もないよね？
何いってんのお前って感じなんだけど。
0145デフォルトの名無しさん
2013/12/29(日) 01:42:25.53> どうしても人の手でテストしなきゃいけない所もあるけど
それが問題でしょ。
どうしても人の手でテストしなきゃならないところは
テスト駆動開発できない。
テストがなければ開発できない手法で、
人の手でテストしなきゃいけないなら、
開発ができないことになる。
0146デフォルトの名無しさん
2013/12/29(日) 01:49:36.01> その意味で「まずテストを全部書き終わってからコーディング」を業界標準にするように圧力かけてほしいと思う
テストを全部書き終わるということが事実用不可能。
まず、全部のテストというのは、すべての条件の組み合わせになる。
当然組み合わせ爆発になるから、テストにかかる時間は何万年にもなりうる。
そこでこの条件でテストしていれば大丈夫だろ？という数のテストに減らす。
だが大丈夫だろ？という判断が正しい保証はない。
つまり、どんなに頑張ってもテストを全部書き終わったつもりで抜けが
ある状態（＝バグ）でコーディングすることにしかならない。
それにな、テストがあってもシステムは動かないが
システムのコードがあれば、システムは動くんだよ。
0147デフォルトの名無しさん
2013/12/29(日) 11:38:22.540148デフォルトの名無しさん
2013/12/29(日) 14:46:41.76それをするための道具が使いづらい。
RUnitでよかったのに、RSpecとかでてきて、わけわからん文法をようやく覚えたと思ったら、
RSpec2でまた命令が新旧入れ替わったとか。
0149デフォルトの名無しさん
2013/12/29(日) 16:56:18.61アサートの思想は、テストを先に(少なくとも同時に)作るってことでしょう
0150デフォルトの名無しさん
2013/12/29(日) 17:01:29.51全部のテストをやれとは言っていない
限られた時間で、可能な限りのテストをやれと言っている
コストを見積もるときには、そのテストを見積もりに入れろってこと (つまり、できないテストも明らかにするってこと)
というか、テストなしにシステム組もうとするってどこの会社？
関わりたくないんだけど
0151デフォルトの名無しさん
2013/12/29(日) 17:04:18.74分かりにくいなら、納品コードにassert() 入れたコードを、納品コードとは別に作ったテスト用コードとみなせばどうか
0152デフォルトの名無しさん
2013/12/29(日) 21:12:49.36> アサートの思想は、テストを先に(少なくとも同時に)作るってことでしょう
そんな思想無いよ。
テストをするのに使うのにアサートがあるだけ。
”先に作る” 思想とはアサートの機能のどの部分のことかね？
テスト自体には先に作るという思想はないよ。
0153デフォルトの名無しさん
2013/12/29(日) 21:38:32.30いや、assertは設計の一部だから、書き込むのはコードを書きだす最初のときでしょ
0154デフォルトの名無しさん
2013/12/29(日) 22:12:41.66assertが設計の一部なのはなぜ？
設計の一部だったら書き出す最初なのはなぜ？
今度は二つの質問に答えないといけなくなったね。
今度は説得力がある答えを言えるかな？
0155デフォルトの名無しさん
2013/12/29(日) 22:21:13.87昔からあるassertは全くの別物だけどね。
0156デフォルトの名無しさん
2013/12/29(日) 23:07:37.540157デフォルトの名無しさん
2013/12/30(月) 00:47:44.790158デフォルトの名無しさん
2013/12/30(月) 04:25:43.40assertが設計の一部なのは、assertが仕様の宣言的表現だから
設計の一部だったら書き出すのが最初なのは、書いてる途中も書き終わった後も実行中も修正作業中も満すべき表明が記述してあるから
0159デフォルトの名無しさん
2013/12/30(月) 04:28:55.35ドメインの要素の部分集合を網羅したコードがxUnitで、ドメインの補集合の部分集合を内包表記したコードがassert
同じモノですよ
0160デフォルトの名無しさん
2013/12/30(月) 04:35:09.73使っているだけみたいだなｗ
用語だけ言ってて具体的な説明が何もない。
0161デフォルトの名無しさん
2013/12/30(月) 09:08:04.41ところが使うには別のツールや知識がいる
テスト駆動ありか、なしか、も、どっちもテストがいることは認めてても、
どうしても最初にテストかかせたいやつと、あとでかきたいやつといるってこと
0162デフォルトの名無しさん
2013/12/30(月) 11:12:22.50テスト駆動（最初にテストを書く）という理由を何一つ言わないで
アサートはテストと同じと繰り返しているだけにしか見えないな。
テストと同じかどうかではなく、最初に書くかどうかって話をしてるのに。
0163デフォルトの名無しさん
2013/12/30(月) 11:38:55.64そもそも「テスト」と称する内容にコモンセンスが存在しないので、
テスト駆動開発ですっ(ｷﾘｯ と言ったところで、成果物の品質の保証
にはなりえない。 馬鹿に仕様やコードを書かせてはいけないように、
馬鹿にテストをやらせてはいけない。
0164デフォルトの名無しさん
2013/12/30(月) 12:15:18.80テストは高い技術力が必要なんだよ。
単純作業でやっていたらいくら時間が
あっても終わらないから。
0165デフォルトの名無しさん
2013/12/30(月) 13:53:07.51assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ
例えば、整数kの階乗の計算でkと計算結果が整数以外でないことを内包的表現でチェックするのがassert
環境が提供できる整数1000個でチェックするのがxUnit
xUnitでエラーが出た場合、バグがあるコードを書いていたことになる
一方、assertがコケた場合、何を計算していたのか不明なので、何もコーディングしてなかったことになる
0166デフォルトの名無しさん
2013/12/30(月) 14:30:22.600167デフォルトの名無しさん
2013/12/30(月) 14:33:44.10> assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ
どの言語のassertの話をしてるの？
それをはっきりしないと、
具体的なものがないということで、
わーわー喚いているように聞こえないよ？
複数の言語があるのなら、
その言語を言えばいい。
0168デフォルトの名無しさん
2013/12/30(月) 14:35:15.83> assertは最初に書かないと、assertを書いて不具合が出たら、コードの修正が環境を含む全域に及ぶからだよ
なんで？
0169デフォルトの名無しさん
2013/12/30(月) 14:36:22.81どの言語もassertは一緒
1946年のチューリングが主張するセマンティクスでOK
自分が使ってる言語にassertがなければ作ればいいだけかと
0170デフォルトの名無しさん
2013/12/30(月) 14:36:50.03最初に書くという理由にはならないし、
assertを書いて不具合が出なければいいだけだし
やっぱり最初に書くという理由がないんだよな。
後から書いていいじゃん。（なぜかしらんけど）修正範囲が大きくなるだけでしょ？
0171デフォルトの名無しさん
2013/12/30(月) 14:37:26.38どの言語でも一緒といったね？
じゃあC言語でも一緒なわけだ。
じゃあ、C言語で書いてみてよ。
0172デフォルトの名無しさん
2013/12/30(月) 14:38:05.79どこを直すべきかの特定につながらないと言いたいんだろう たぶん
0173デフォルトの名無しさん
2013/12/30(月) 14:38:49.52最初に書くという根拠にはならないんだよな。
0174デフォルトの名無しさん
2013/12/30(月) 14:41:05.78例えば、c言語でintのつもりでコード書いてたら、intじゃなかったってことだから
0175デフォルトの名無しさん
2013/12/30(月) 14:49:09.43#define assert(t) ((t) ? (void)0 : printf("%s, %d %d %d\n", __func__, __FILE__, __LINE__, #t))
かな?
0176デフォルトの名無しさん
2013/12/30(月) 14:53:00.40assertを書いて不具合が出なければいいだけのコードを書く方法は、少なくとも最初にコンパイルする前にassertを書き込むことだと思うけど
1+1をaに代入するだけのコードを書く方法は、まず a:=1+1 を書くことだと思うけど
0177デフォルトの名無しさん
2013/12/30(月) 14:57:23.00やっぱり、”最初” である理由はないみたいね。
ただのテストの話してただけじゃん。
最初に指摘したとおりだった。
0178デフォルトの名無しさん
2013/12/30(月) 14:58:25.05> assertを書いて不具合が出なければいいだけのコードを書く方法は、少なくとも最初にコンパイルする前にassertを書き込むことだと思うけど
それなら後からassert書けばいいだけだよ。
0179デフォルトの名無しさん
2013/12/30(月) 15:16:19.950180デフォルトの名無しさん
2013/12/30(月) 15:34:39.860181デフォルトの名無しさん
2013/12/30(月) 16:05:51.76それで、優秀な人がまず最初にテストを書いて、優秀じゃない人に
テストを通るコードを書かせるんでしょ？
じゃあなんで最初から優秀な人にコード書かせないの？
優秀だからテストしなくてもいいっしょ。
0182デフォルトの名無しさん
2013/12/30(月) 16:08:30.80どっちにしろまともに動かなくて納品後も修正に来るんでしょ？
こっちがあきらめて検収するまで直すふりするんでしょ？
なんだか意味ないような気がするよ。
0183デフォルトの名無しさん
2013/12/30(月) 16:19:35.91自分で書けば？
0184デフォルトの名無しさん
2013/12/30(月) 16:20:50.87つまるところプログラマは自分のプログラムをデバッグするほど賢くない。
となれば、プログラマ１人に対してテスターが３人ぐらい必要になるから
0185デフォルトの名無しさん
2013/12/30(月) 16:24:25.300186デフォルトの名無しさん
2013/12/30(月) 16:24:31.56assertが入ったコードと、assertが抜けたコードがある場合、前者はテストコードですよ
0187デフォルトの名無しさん
2013/12/30(月) 16:27:02.87まさにそれ。
自分たちで書いたのを今運用してんの。
ちなみに単体テストすらしてません。
0188デフォルトの名無しさん
2013/12/30(月) 16:27:49.27正しくは、assertに書くべきモノが最初に「ある」ってことかな
例えば、実機そのものや実機の設計書もコードを書く前に「ある」はずけど、コードを書いた後に作っても問題ないし
0189デフォルトの名無しさん
2013/12/30(月) 16:29:07.89テスト駆動は防衛的プログラミングですよ
0190デフォルトの名無しさん
2013/12/30(月) 16:32:13.64目にいっぱい涙をためても手を緩めたらダメ。
あれはそうしろって上から言われてるんだよ。
泣きまねも絶対教育されてる。
0191デフォルトの名無しさん
2013/12/30(月) 16:34:18.57それには、その一切のミスをしない優秀な人が、実機やOSやコンパイルや補助ライブラリも全部作るという前提が必要
ちなみに、実際の現場での優秀な人のイメージは、ミスをしない人ではなく、ミスが少ない人
0192デフォルトの名無しさん
2013/12/30(月) 16:37:07.20相手側に予算と時間があれば、修正せずに別会社で最初からで、おつきあい終わり
0193デフォルトの名無しさん
2013/12/30(月) 18:33:40.58そうでもなんだね
基本設計(UseCaseシナリオ相当)で、運用テストシナリオを作る。
概要設計(Activiti図相当)で、結合テストシナリオを作る。
詳細設計(Sequence図相当)で、単体テストのバリエーションを作る。
それからプログラミングをする。
とやっておけば、まず、テスト作成を通じて、仕様が妥当かのチェック
ができる。(プロジェクト (Iteration/Sprint/...) の前半で!!)
また、プログラミングの目標が具体化される。(仕様を満たす
"完璧" なものを作る必要はなく、妥当な網羅性のあるテストに
合格すればOK)
テスト設計も順を追って詳細化されるので、設計上は、
単体テストに合格していれば、結合テストに合格し、
結合テストが合格なら、運用テストにも合格するはず。
裏を返せば、結合・運用テストでは、本来出てくるべき
不具合 (ちゃんと動くもの同士をつなげても、ちゃんと動かない)
の対処に注力できる。
しかも理論上は、かかる工数は同じ。(どうせテスト仕様は
どこかで作るんでしょ)
テスト駆動にしない理由のほうが見当たらないくらい。
0194デフォルトの名無しさん
2013/12/30(月) 18:36:51.50あとは日本の零細経営者はテスト工数を客に見積もれんとか言い出すしな。
ビル建築でも安全率の負担増加分やエレベータや施設のテストもろもろは
ちゃんと請求してんのにな。
0195デフォルトの名無しさん
2013/12/30(月) 18:37:15.600196デフォルトの名無しさん
2013/12/30(月) 18:38:16.91日曜さん?
テストケースは(日本で言う)プログラマが考えるんじゃないんだが。
0197デフォルトの名無しさん
2013/12/30(月) 18:39:22.51それまではサンドバッグです
0198デフォルトの名無しさん
2013/12/30(月) 18:44:08.150199デフォルトの名無しさん
2013/12/30(月) 18:54:54.45プログラマは、釘に金槌を叩きつけるだけ
0200デフォルトの名無しさん
2013/12/30(月) 18:58:40.61ただ単純に、1万行を超えるコードや人月が3ヶ月人を超えるコードを書いたことがないだけだと思う
趣味の日曜プログラミングでも、次の週までかかると思ったらまずテストコード書くよ
0201デフォルトの名無しさん
2013/12/30(月) 19:13:29.280202デフォルトの名無しさん
2013/12/30(月) 19:31:06.80インターフェイス共通でレベルの低いディストリをわざとばらまかないと金儲けできないからな…
0203デフォルトの名無しさん
2013/12/30(月) 19:41:58.210204デフォルトの名無しさん
2013/12/30(月) 19:51:55.710205デフォルトの名無しさん
2013/12/30(月) 19:56:23.72残念だが、コードが完璧でも、実機やOSやコンパイラや言語仕様やユーザの要求は完璧じゃないんだ…
0206デフォルトの名無しさん
2013/12/30(月) 20:14:12.620207デフォルトの名無しさん
2013/12/30(月) 20:18:50.02いまどきはどこも、そんなきれいなV字ウォーターフローやってる暇はないでしょ。
0208デフォルトの名無しさん
2013/12/30(月) 20:19:54.07正確には「人という生物の特性のせい」
0209デフォルトの名無しさん
2013/12/30(月) 20:20:24.690210デフォルトの名無しさん
2013/12/30(月) 20:24:27.17> 趣味の日曜プログラミングでも、次の週までかかると思ったらまずテストコード書くよ
お前がどうするかなんかしらんがなｗ
日曜プログラマの大半はテストコード書かないだろうってのは
大体想像できる。
0211デフォルトの名無しさん
2013/12/30(月) 20:27:09.10土下座の練習が欠かせない。
0212デフォルトの名無しさん
2013/12/30(月) 20:28:19.300213デフォルトの名無しさん
2013/12/30(月) 20:29:49.660214デフォルトの名無しさん
2013/12/30(月) 20:30:20.150215デフォルトの名無しさん
2013/12/30(月) 20:30:30.39テストファーストはしないけど。
0216デフォルトの名無しさん
2013/12/30(月) 20:31:24.44プログラミングのタイピングを途中で打ち切ることになって、これまでにどこまで進んだかを覚える必要が出てくるんだけど、次の週までどうやって覚えておくの？
0217デフォルトの名無しさん
2013/12/30(月) 20:33:20.52体に教え込まないと無理
10年かかってやっとわかった
プログラマは言って聞かせても無駄
体で覚えさせれば素直に言うこと聞くようになる
0218デフォルトの名無しさん
2013/12/30(月) 20:33:32.240219デフォルトの名無しさん
2013/12/30(月) 20:33:36.07コード見て思い出せばいいだろ？
なんなら何をやっていたかを
日本語で書いてもいいし。
0220デフォルトの名無しさん
2013/12/30(月) 20:34:15.51チケット。
0221デフォルトの名無しさん
2013/12/30(月) 20:35:23.51先週何をやっていたか
泉のように思い出すのです。
それが愛です。わかりましたか？
0222デフォルトの名無しさん
2013/12/30(月) 20:35:55.410223デフォルトの名無しさん
2013/12/30(月) 20:35:55.94テストの方が簡単じゃね？
0224デフォルトの名無しさん
2013/12/30(月) 20:36:38.48なんで質問するんだよｗ
テストの方が先週何をやっていたか
思い出すのに簡単である理由を説明しろよ。
0225デフォルトの名無しさん
2013/12/30(月) 20:37:28.20テストを先に書く習慣の人が自分のテストコードを見れば、何をやろうとしてコード書いてて、何ができてないなかったかが分かる
0226デフォルトの名無しさん
2013/12/30(月) 20:38:24.95それくらい覚えてる。一年後でも。
>>223
テストが簡単なコードだけとは限らないしねー
0227デフォルトの名無しさん
2013/12/30(月) 20:38:44.19テストが全部通った場合はどうなるのさ？
お前が言ってるのは、コンパイルが通らなかったら、
今ここをつくろうとしていたとわかるって
言ってるのと同じだよ。
0228デフォルトの名無しさん
2013/12/30(月) 20:39:31.76すごいね
0229デフォルトの名無しさん
2013/12/30(月) 20:40:47.180230デフォルトの名無しさん
2013/12/30(月) 20:41:03.90動的言語でもわざとエラーが起こるようにしておけばいいだけの話だし、
コメントではなくコードの中に日本語を書いておけば、
当然エラーも起きるだろうし、わかりやすい。
0231デフォルトの名無しさん
2013/12/30(月) 20:43:09.270232デフォルトの名無しさん
2013/12/30(月) 20:43:17.171. コーディングの目的が「目の前にあるテストを成功させる」に還元されるから (頭空っぽでもテストを通せば先週やろうとしてたことが終わったことになるので思い出す必要すらない)
2. ドメインを網羅するテストのコードは仕様そのものだから (とくにQuickCheck系)
3. 一般に、ソースに書いてあるコメントすらも信用できないのが業界の常識
0233デフォルトの名無しさん
2013/12/30(月) 20:46:26.66あほかｗ
お前の言ってるのは、テストが完璧に書いてあることが前提になってるだろ。
テストに漏れがない。テストに間違いがない。
> 1. コーディングの目的が「目の前にあるテストを成功させる」に還元されるから (頭空っぽでもテストを通せば先週やろうとしてたことが終わったことになるので思い出す必要すらない)
そのテストに漏れがあったら？
テストを書いている途中だったら？
> 2. ドメインを網羅するテストのコードは仕様そのものだから (とくにQuickCheck系)
テストが書いていなかったら？ テストがなかったら仕様がわからないよ。
> 3. 一般に、ソースに書いてあるコメントすらも信用できないのが業界の常識
テストが間違っていることもある。
0234デフォルトの名無しさん
2013/12/30(月) 20:46:39.27コーディングの前にテストを書く習慣の人が書いたテストが全部通ったら、コーディングの前にやろうとしてたことは終わった
コンパイルが通らなかったら、 今ここをつくろうとしていたとわかる
コンパイルが通ってテストが通らなかったら、今ここをつくろうとしていてスケルトン作って試行錯誤していたことがわかる
0235デフォルトの名無しさん
2013/12/30(月) 20:48:38.782を入れたら4が返るべきとなっている。
さて3を入れたらなんになるのだろうか？
テストが足りないから何がしたいのかわからん！
0236デフォルトの名無しさん
2013/12/30(月) 20:49:05.15コンパイルが通るコードを書いて実行結果を見て試行錯誤しながらコーディングしてた場合は？
0237デフォルトの名無しさん
2013/12/30(月) 20:50:14.19とは限らない。
なぜならバグを修正しようと思った時、
バグが見つかる前は、”テストが全て通った状態”なのだ。
テストが全て通っていても、
やるべきことが残っていることはよくある話。
0238デフォルトの名無しさん
2013/12/30(月) 20:52:19.110239デフォルトの名無しさん
2013/12/30(月) 20:52:29.71１．失敗するテストコードを書く
２．テストコードを通る”最低限の”実装を書く
とある
http://www.slideshare.net/KyonMm/jasst
> 30. Definition TDD
> 1. 失敗するテストコードを実装する
> 2. テストが通る最低限の実装をする
> 3. 1と2を繰り返す中で、テストの変更につよ くするための実装をする
> 1 - 3を30secから1minで繰り返す。
つまり、テストコードが通ったとしても、
それは最低限の実装であり、
すべてが終わったとは限らない。
0240デフォルトの名無しさん
2013/12/30(月) 20:53:05.60テスト書かなければ、コーディング終わってたのでは？
あと、テストコード書きは絶対に中断されない前提なのね。
0241デフォルトの名無しさん
2013/12/30(月) 20:53:20.85じゃなきゃちゃんと動くはず
0242デフォルトの名無しさん
2013/12/30(月) 20:54:30.20TDDに詳しいのかな？ｗ
0243デフォルトの名無しさん
2013/12/30(月) 20:55:52.10やっちまった奴はボーナスなし！
このくらいやってもらわないと。
0244デフォルトの名無しさん
2013/12/30(月) 20:56:11.97テストは間違っててもいい
テストかコードのどっちかが間違ってるということが分かるから
大前提として、基本的にテストには漏れがある (＝ つまり仕様に漏れがある)
0245デフォルトの名無しさん
2013/12/30(月) 20:56:55.17つまり、ソースコード管理ツールのことである！
0246デフォルトの名無しさん
2013/12/30(月) 20:57:14.620247デフォルトの名無しさん
2013/12/30(月) 20:57:22.20それは、次の人に渡すまでに、プログラマ本人が「自分の責任で」テストをするのが前提ですよね？
0248デフォルトの名無しさん
2013/12/30(月) 20:58:51.76> テストは間違っててもいい
話、ちゃんと理解している？
テストコードが間違ってる状態で、
どっちが正しいかをどう判断するのさ？
先週、何やっているかわからなくなっても
テストコードが失敗したら、そこから作業開始するんだろ？
テストコードしか、何をやっているか手がかりがない。
そのテストコードが間違っているのに、
どちらが正しいかどうやって思い出すのさ？
0249デフォルトの名無しさん
2013/12/30(月) 21:00:09.98テストコードがあれば思い出せるって言ったのだれさ？
自分の言葉に責任持てよ。
0250デフォルトの名無しさん
2013/12/30(月) 21:01:28.850251デフォルトの名無しさん
2013/12/30(月) 21:02:20.54テストは万能ではない
テストコード先に書いた方が、より「バグが少ないコードを書ける」ってだけ
テストコードもソースコードも間違うことがある
テストが間違っててコードが正しい場合と、コードが間違っててテストが正しい場合と、テストとコードが同時に間違ってて答えが異なる間違い方をしてる場合を検出できるってだけ
テストは「時間が許す限り可能な限りバグを減らす努力」のひとつに過ぎない
0252デフォルトの名無しさん
2013/12/30(月) 21:02:52.75責任は責任ある立場の人がとります。
0253デフォルトの名無しさん
2013/12/30(月) 21:03:07.36何をしようとしていたかなんて分かるわけがないよね。
gitとか使っていれば、コミットした分は終わっているとわかるだろうし
作業履歴もコミット履歴としてわかるだろうけど。
こんなのあたりまえだと思う。
テストコードに何を求めているのかと。
0254デフォルトの名無しさん
2013/12/30(月) 21:04:33.27あー、ちみちみ、
今はテストコードがあれば先週何をやっていたか
思い出せると主張している
おバカさんをこてんぱんにしている最中だから。
テストコードの批判なんて
誰もしとらんのだよ？
0255デフォルトの名無しさん
2013/12/30(月) 21:04:58.41プログラマ卒業したら何になるんですか？
0256デフォルトの名無しさん
2013/12/30(月) 21:06:18.48> プログラマ卒業したら何になるんですか？
経営者になります。
どの道も全部同じです。
スポーツ選手も
アーティストも
海賊王も
全部最後には経営者になるのです。
0257デフォルトの名無しさん
2013/12/30(月) 21:07:32.34先週、何やっているかわからなくなっても
テストコードが失敗したら、「そこから」作業開始する
他はテストが通ってるから無視してOK
そのときの作業の内容は、
・テストに記述された仕様の宣言的表現を確認する
・テストの間違い方を見る
・「その後で」コードを見る
だから、実は作業内容を思い出す必要もない
0258デフォルトの名無しさん
2013/12/30(月) 21:09:20.89テストコードに求めるモノは、仕様の宣言的表現
0259デフォルトの名無しさん
2013/12/30(月) 21:09:26.01なれねーよ、ばーか！
社会人の方よろしくおねがいします。
0260デフォルトの名無しさん
2013/12/30(月) 21:09:42.75↓
俺には無理だ。だから最高のギタリストを育てることにした
これって勝ち組なのか負け組なのか悩むよね。
0261デフォルトの名無しさん
2013/12/30(月) 21:13:36.93> 先週、何やっているかわからなくなっても
> テストコードが失敗したら、「そこから」作業開始する
じゃあテストが成功したらどうするんだよ。
全てが完成したのか
ある所まで完成したのか
テストを今から書こうとしたのか
テストに通る最低限の実装したのか
どうやって区別するんだよ。
あるところまで完成したとして、
じゃあ次は、どこから作業開始するんだよ。
だいたいテストコードが失敗してる状態で
やめたりしねーよ。
すこしはさ、冷静に考えてみたら？
0262デフォルトの名無しさん
2013/12/30(月) 21:16:11.95次どこからやるって、一言書いておけば済む話だよね。
git使っていれば、今まで何やったかすぐわかるし。
○○というものを知った人は、
なんでも○○でやろうとする。
テストコードというものを知った人は、
なんでもテストコードでやろうとする。
まあ、これは初心者にありがちな行動。
0263デフォルトの名無しさん
2013/12/30(月) 21:16:23.27まず前提として、紙に書いた文書やエディタで打っている最中のコードは「プログラマが作りたかった機能」じゃないよね？
「プログラマが作りたかった機能」を「プログラマが通したかったテスト」として書く
つまり、やろうとしたかったことを思い出すためには、テスト見れば終わりじゃん
0264デフォルトの名無しさん
2013/12/30(月) 21:17:42.39世の中には、テストコードがあるプロジェクトはたくさんあるけど、
そのテストコード見ても、これからやろうとしていることなんかわからんよ。
0265デフォルトの名無しさん
2013/12/30(月) 21:18:53.00まず、次の人に渡す前までに自分でテストする派なのか、テストせずに次の人に渡す派なのかはっきりしてくさい
0266デフォルトの名無しさん
2013/12/30(月) 21:20:01.12それは、テストコードが失敗している時に中断した場合に限った話だろ。
テストコードが成功した状態でやめたら、
次何をしようとしていたかなんてわからんだろ
0267デフォルトの名無しさん
2013/12/30(月) 21:20:53.43その「一言」が日本語の場合は、前後の文脈を忘れると嘘になる
0268266
2013/12/30(月) 21:21:14.840269デフォルトの名無しさん
2013/12/30(月) 21:21:32.49一文字一文字気持ちを込めて書けばバグなんか出ないはずです。
0270デフォルトの名無しさん
2013/12/30(月) 21:21:36.910271デフォルトの名無しさん
2013/12/30(月) 21:22:50.40テストが全部通ったら終わりじゃん
そのプロジェクトは忘れて、安心して放置するなり、次の人に回すなりすればいいよ
0272デフォルトの名無しさん
2013/12/30(月) 21:23:20.70それで？
もしかして「一言」って
本当に、一言（一ワード、一単語）だと
思った？
0273デフォルトの名無しさん
2013/12/30(月) 21:24:01.03プロジェクト全ての
テストコードを先に書いてしまうのが
テスト駆動と思ってるんじゃないか？
0274デフォルトの名無しさん
2013/12/30(月) 21:24:48.24あー、なるほどｗ
だったら今までの意味不明な発言も
なんとなくわかるような気がするなｗ
0275デフォルトの名無しさん
2013/12/30(月) 21:26:09.61え？違うの？
0276デフォルトの名無しさん
2013/12/30(月) 21:26:32.250277デフォルトの名無しさん
2013/12/30(月) 21:27:17.01もしくは、ごく小さいプログラムしか作っていないか。
0278デフォルトの名無しさん
2013/12/30(月) 21:27:18.090279デフォルトの名無しさん
2013/12/30(月) 21:30:02.80それはテストコードを通る最低限の実装なわけで
そこから最低限ではない、ちゃんとした実装をしたり
リファクタリングをするから
それで終わりじゃ無いんだけど？
やっぱり俺のほうがTDDに詳しいｗ
0280デフォルトの名無しさん
2013/12/30(月) 21:31:26.20まず、「これが通ればプロジェクトは全部終わり」というテストを一つ書いておく
その次に、それよりも多少粒度が細かくてキーとなり機能のテストをいくつか書いておく
それとは別に「今から書こうとするコードのテスト」を書いて、個々の機能のコーディングを進める
最初に全部のテストを書く必要はないよ
0281デフォルトの名無しさん
2013/12/30(月) 21:31:39.14テストコードに通ればプログラム完成。
そのコードが汚くても関係ない。
0282デフォルトの名無しさん
2013/12/30(月) 21:31:40.04テストコードがなければ、次の週の作業が思い出せないと言っている以上、
土日の間にすべてのテストコードを揃えてしまわないといけないだろう。
0283266
2013/12/30(月) 21:32:50.41このたった一つのテストの内容は、
たとえば、ウェブサーバーだと、
・・・・長い長い物語の始まりですｗ
0284デフォルトの名無しさん
2013/12/30(月) 21:33:29.84ずいぶんと平坦なプロジェクトだねぇ。
プロジェクトの途中で仕様が変わることなんて考慮しないんだ。
0285デフォルトの名無しさん
2013/12/30(月) 21:33:59.02証明するテストか。
どんなのに鳴るんだろうなｗ
0286デフォルトの名無しさん
2013/12/30(月) 21:39:09.22TDDはまず仕様のうちコーディングして実現できる宣言的命題をテストコードで表現する
コードを進めるとコードが失敗することによって、テストのバグも発覚して、仕様のミスや未定義な部分が明らかになる
テストコードを通るコードは、最低限の実装ではなく、コーディングする前に考えた宣言的命題を満たす実装
ちなみに、リファクタリングするなら、少なくともそのリファクタリングの前には、そのコードが通るテストがそろってる必要がある
0287デフォルトの名無しさん
2013/12/30(月) 21:41:11.51終わりだと証明するテストか
哲学（笑）だなｗ
0288デフォルトの名無しさん
2013/12/30(月) 21:41:28.12すべて書かなくても、土日で書ける量の粒度ごとについて一つずつテストを書いておけばいい
0289デフォルトの名無しさん
2013/12/30(月) 21:44:27.17> テストコードを通るコードは、最低限の実装ではなく、コーディングする前に考えた宣言的命題を満たす実装
違うぞ。
http://moguranosenshi.hatenablog.com/entry/2013/12/20/TDD%E3%81%AB%E3%81%84%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%9F
> テストの失敗を確認したら、実装に移ります。
> テストを通すための最低限の実装であるのがポイントです。
> ３が入力されたときのテストのみなので、Fizzを返すだけでOK.
こういうのがTDDのやり方
こんなことも時点で、こいつはTDDを知らんなってわかるよ。
0290デフォルトの名無しさん
2013/12/30(月) 21:44:32.10Webサーバは単純なバッチテストは無理
事前に、シナリオを用意して、そのシナリオ通りにアクセスするテスト用のクライアントプログラムを用意するのが吉
0291デフォルトの名無しさん
2013/12/30(月) 21:45:31.28テスト書かなくても作業を覚えておけるのならね。
0292デフォルトの名無しさん
2013/12/30(月) 21:45:55.891万行？ 10万行じゃなくて？ コード量が多ければいいという話でも
ないと思うが、たった1万行くらいを大規模と勘違いしちゃってる時点で
既にアレな気が。
0293デフォルトの名無しさん
2013/12/30(月) 21:46:50.25「あなたが」「これが通ったら終わりでいいや」と思えるテストを書けばいいよ
0294デフォルトの名無しさん
2013/12/30(月) 21:48:40.64そのWebの方が間違ってる
理由は、そのWebを書いた人は、事前に考えた仕様に未定義部分がないことを前提にしているが、そんなプロジェクトはないから
0295デフォルトの名無しさん
2013/12/30(月) 21:51:58.990296デフォルトの名無しさん
2013/12/30(月) 21:57:06.39そろそろ、この世に完璧などないと認めたらいかがですか？
イチローに向かって、毎回ホームラン打てば走る練習しなくていいじゃん って言ってるようなもんですよ
0297デフォルトの名無しさん
2013/12/30(月) 22:04:22.91じゃあ正しいの持ってこいよｗ
https://www.google.co.jp/search?q=TDD+最低限の実装
このリンクの中からな。
0298デフォルトの名無しさん
2013/12/30(月) 22:06:11.51https://www.google.co.jp/search?q=テスト駆動 最低限の実装
をテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った ...
れを成功させる最低限のコードを書く、というステップを繰り返す ... というのも、テ
功する最低限の実装コードを書く4. 実行して成功することを確認する5. テストが通る状
とを確認する（ レッド ） ステップ2：ステップ1のテストを通す最低限のコードを実装
0299デフォルトの名無しさん
2013/12/30(月) 22:45:06.381. 最終的に正しいコード(バグがないコード)を作成することを目的に
2. プログラマがコーディングする前に考えた宣言的命題を「暫定的に」正しい仕様として採用し
3. それをテストコードとしてまず作成し
4. コーディングの目的をそのテストをパスすることに還元し
5. そのテストを通るように本体のコードを作成し
6. テストの結果によってコードのみならずテストの修正も行い
7. テストの修正がある場合は仕様の修正として上流にフィードバックし
8. テストが通るまでコーディングするスタイル
リファクタリングの場合は、
1. 最終的に正しいコード(バグがないコード)である状態を変更しないことを目的に
2. すでに作成されたテストコードを再利用し
3. コーディングの目的をそのテストをパスしつつ、リファクタリングの目的を達成することに還元し
4. そのテストを通るように本体のコードを作成し
5. テストが通り、リファクタリングの目的を達成するようにまでコーディングするスタイル
上記のことが記述してある(2〜3日以内にググれば出てくる)参考URL
http://toro.2ch.net/test/read.cgi/tech/1387695847/l50
0300デフォルトの名無しさん
2013/12/30(月) 23:05:49.790301デフォルトの名無しさん
2013/12/30(月) 23:11:05.180302デフォルトの名無しさん
2013/12/30(月) 23:16:53.97> 例えば、整数kの階乗の計算でkと計算結果が整数以外でないことを内包的表現でチェックするのがassert
> 環境が提供できる整数1000個でチェックするのがxUnit
オマエとオマエの会社を除いて、どこの世界に整数演算で済むのに、わざわざ
浮動小数点にして計算するバカがいるんだよ。
「整数」とは16bitなのか、32bitなのか、64bitなのか、ちゃんと仕様に
明記されているんだよな？
階乗を計算する関数は、結果を値で返すのか、それとも結果を返す変数の
ポインタか参照渡しなのか？ 前者の結果を値で返す場合、桁あふれしたら
戻り値は0なのか、それとも例外を投げるのか？ 例外に関する規定は仕様に
明記されているんだよな？
NULLポインタが渡された場合の関数の挙動は？ それと、引数や戻り値の型が
よもや符号付きだったりしないよな？
0303デフォルトの名無しさん
2013/12/30(月) 23:19:11.390304デフォルトの名無しさん
2013/12/30(月) 23:23:04.64仕様書の関数のドメインが 「整数の集合」 のつもりでも、実際のドメインが 「整数の集合 ∪ {null}」 のことは普通のあるけど
特にC言語
0305デフォルトの名無しさん
2013/12/30(月) 23:27:44.030306デフォルトの名無しさん
2013/12/30(月) 23:28:59.810307デフォルトの名無しさん
2013/12/30(月) 23:29:15.65あるから、テストする
0308デフォルトの名無しさん
2013/12/30(月) 23:29:47.31事前に考えた仕様に未定義部分がないことを前提にしているから
0309デフォルトの名無しさん
2013/12/30(月) 23:32:23.25テストが通らない部分はどうするの
int x = getStatus();
if (x < 0) { ... } else if (x >= 0) { ... } else { throw unstableMemoryException("unstable memory error"); }
例がよくないけど、途中returnみたいなものでもいいけど、通常では Exceptionは、起きるはずがないしテストのしようもない
最低限とか、テストを宣言的命題にして、それをパスするコードを書くとかの意味では、最後んとこは書くべきでない
でも出荷する製品レベルなら、これは、いれとくべき仕様だと思うけど、テスト駆動からは逸脱してる
0310デフォルトの名無しさん
2013/12/30(月) 23:32:36.16いくつかの種類のテストは
テスト困難か、テスト不可能だから
0311デフォルトの名無しさん
2013/12/30(月) 23:35:12.87コードがない状態では
そのコードに対するやらなくてはいけない
完全なテスト内容が予測不可能だから。
0312デフォルトの名無しさん
2013/12/30(月) 23:36:23.62実際にコードを書いて検証しなければ
見えてこないものがあるから
0313デフォルトの名無しさん
2013/12/30(月) 23:42:28.16テスト駆動をするには、
テスト駆動可能なコードを書く技術力が必要だから。
テスト駆動がない所は、テスト駆動可能なコードを書いていない。
その状態でテスト駆動のみを取り入れようとしても
できるわけがない。
0314デフォルトの名無しさん
2013/12/30(月) 23:43:06.08まず、一般的にjavaのExceptionはバグではない
だから、仕様にあるものとして考えるべきだし、テストのときにあえてExceptionを与えることもできるし、テストケースで受けることもできる
テストは、「限られた時間内で可能な限りバグを減らす努力」のひとつだから、時間がないなら例外についてのテストはやらなくていいけど、納期とコストの見積もりのときにはやらないということを共通の認識にすべき
0315デフォルトの名無しさん
2013/12/30(月) 23:45:38.53プログラミングは基本的にすべてテスト駆動
テストすべきモノはすでに頭の中かコンピュータに存在する
それを再利用できる形でコード化するかどうかの違いしかない
0316デフォルトの名無しさん
2013/12/30(月) 23:45:55.89納期とコストの都合上
やらない方がいいテストが存在するから
0317デフォルトの名無しさん
2013/12/30(月) 23:47:43.37だからなんなんだよ？
俺のレスに関係ない話すんなって。
0318デフォルトの名無しさん
2013/12/30(月) 23:49:05.46いやExceptionに限定しないでさ
テストが通らないコード部分ってあってそういう部分のコードを書くのは重要なコードだとしてもテスト駆動から逸脱してるよねって話
時間ないからテストやらなくていいとかそういう話はもうテスト駆動じゃないと思うんだけど
0319デフォルトの名無しさん
2013/12/30(月) 23:49:40.25「テスト駆動を取り入れてない」という認識が間違っている
0320デフォルトの名無しさん
2013/12/30(月) 23:50:37.19仕様には具体的に明記されていない条件下で発生するのだな。
例外を投げること自体はエラーでなくとも、エラー時に正しく例外が投げ
られるかどうか検証しないテストなんぞは、実質的には無意味に近い。
0321デフォルトの名無しさん
2013/12/30(月) 23:53:09.91ただ単に、テスト駆動だけど、自動で再利用できるテストではないだけだと思うが
テストが通らないがテストのしようがないという意味なら、なにをもって正しいと言って納品してるの？
0322デフォルトの名無しさん
2013/12/30(月) 23:54:48.95function pow(x, y) {}
テスト駆動でやるとしたら、実装よりも前にテストコードを
書かないといけないわけだけど、
正常系はかけるだろう。
だけど異常系、たとえばxやyに数字以外を入れた場合のエラーは
実装よりも先に書くのか？という問題がある。
実装を書いてしまえば、当然エラーで落ちるだろう。
その後にテストコードを書いたらテスト駆動にはならないから
先に書くしか無いはずなんだが。
0323デフォルトの名無しさん
2013/12/30(月) 23:56:53.66> テストが通らないがテストのしようがないという意味なら、なにをもって正しいと言って納品してるの？
テストコードが正しいという根拠は？
何を持って正しいのか？なんて話をすると
結局こういうことになるんだけど。
0324デフォルトの名無しさん
2013/12/30(月) 23:58:32.43実行したテストはわかるが、
実行してないテストがあるかどうか
まではわからないんだよね。
わかり易い例を上げると
失敗したテストを削除してしまえば、
テストは全て通ったことにできる。
0325デフォルトの名無しさん
2013/12/30(月) 23:59:16.32テストは命題が偽であることもチェックできますよ
0326デフォルトの名無しさん
2013/12/30(月) 23:59:53.51だからなんなんだよ？
0327デフォルトの名無しさん
2013/12/31(火) 00:00:39.47限り実際には問題にならないような例ではなく、MD5やSHA1といったハッシュ
値を計算のような、処理中にテーブルを参照して計算するプログラムで、
テーブルの値がどこか1bitだけ反転しているケースとか、具体的にどう
やってテストだけで検出するつもりなんだろう？
0328デフォルトの名無しさん
2013/12/31(火) 00:01:49.96「このテストで正しいことを確認しました」 「テストコードは仕様の宣言的命題の羅列だから漏れがあるか確認してください」 「環境も含めてテストしたい場合はこのテストをあなたのマシンで動かしてください」 でいいじゃん
0329デフォルトの名無しさん
2013/12/31(火) 00:03:18.90細かく関数に分解し、すべてテストを書く。
0330デフォルトの名無しさん
2013/12/31(火) 00:04:42.82苦笑ｗ
いや、だからそういうことだろ？
> なにをもって正しいと言って納品してるの？
の答えは、
「漏れがあるか（あんたが）確認してください」
ってことでしょ？
0331デフォルトの名無しさん
2013/12/31(火) 00:05:43.23正しいことを証明しなさい
↓
いやです。あんたが確認しなさい。
0332デフォルトの名無しさん
2013/12/31(火) 00:05:52.22というか、テスト以外でどうやって検出するの？
念力？
0333デフォルトの名無しさん
2013/12/31(火) 00:08:43.54テストで検出しないとダメ。
0334デフォルトの名無しさん
2013/12/31(火) 00:11:00.08「『私の確認を』 あんたが確認してください」 ね
ざっくり言うと
正しいことを証明しなさい
↓
ドメインの部分集合をテストで確認し暫定的な証明とする
↓
「私がやった正しいことの証明」をあんたも確認してください
ね
0335デフォルトの名無しさん
2013/12/31(火) 00:11:20.30たとえば、二乗する関数が合ったとして、
2なら4、3なら9、4なら16、16なら256というテストコードに通っても、
if (n == 2) return 4;
if (n == 3) return 9;
if (n == 4) return 16;
if (n == 16) return 256;
という明らかに間違った実装でも、テストコードは通るんだよ。
0336デフォルトの名無しさん
2013/12/31(火) 00:12:16.47テストのテストを書けばいい。
0337デフォルトの名無しさん
2013/12/31(火) 00:14:18.82テスト駆動とは、仕様を宣言的命題としてテストを書いて、それに従うコードを書くことなんでしょう？
テストに書かれていない、つまりテストできないコードを書く
それも実際には重要になるだろうコードを書くのは、テスト駆動から逸脱じゃないの？
309の例はよくないけど、
言語仕様の取り得る全ての値をチェックして、さらに、どれにも当てはまらない、ありえない場合に
ロジックではないエラーとして例外を投げるとき、テストできるのは、前半の取り得る全ての値のテストだけで
それが通れば正しいコードとして納品できるよね
後半は、ありえないようなハードエラーが起きたときにも、救うべく用意されるコードで、
正しい以上の配慮のコードで、テスト駆動を逸脱しないと書けないと思うんだよね
0338デフォルトの名無しさん
2013/12/31(火) 00:15:42.40そんな実装をする低能を検出して除外するために
採用面接などのテストが存在する
0339デフォルトの名無しさん
2013/12/31(火) 00:16:47.49卵が先です。
常識で考えればわかるはず。
なぜなら、最初の鶏の親は鶏ではなかったのだから。
0340デフォルトの名無しさん
2013/12/31(火) 00:17:28.61ドメインが {2,3,4,16} なら正しいコードですけど
0341デフォルトの名無しさん
2013/12/31(火) 00:18:27.06たとえば、読み込んだ設定値を使うべき所を
面倒だから、とりあえず固定値つかって開発しましたみたいなの。
・テストは書いた（でも不足している）
・テストは通った（ただし固定値を使ってしまってる）
こういうのはテストコードがあって、それを実行して
テストコードが通っても正しく動かないコードなんだよね。
人間ミスはだれでもするもので、テストコードを漏れなく書いたつもりでも
漏れてしまうことがある。
テストコードがあっても、正しく動くという証明はできないんだよ。
テストコードで証明できるのは、テストしたことだけ。
コードが正しいこともテストが正しいことも、漏れがないことも証明できない。
0342デフォルトの名無しさん
2013/12/31(火) 00:19:31.63> function pow(x, y) {}
> だけど異常系、たとえばxやyに数字以外を入れた場合のエラーは
記述はC言語の型宣言っぽいけど、C#か何か？ VBで書くと
Public Function pow(x As Variant, y As Variant) As Variant
...
Dim X As Variant
Dim Y As Variant
Dim Z As Variant
X = "abc"
Y = "def"
Z = pow(X, Y)
とかってことで桶かな？
0343デフォルトの名無しさん
2013/12/31(火) 00:20:26.69非常にわかりやすく納得しました。
確かにその通りです。
テストする奴はアホです。
これからはデバッガの時代です。
改心しました。
0344デフォルトの名無しさん
2013/12/31(火) 00:21:28.29その「テストのためのテスト」のテストコードは、いつ誰が書くの？
0345デフォルトの名無しさん
2013/12/31(火) 00:21:38.820346デフォルトの名無しさん
2013/12/31(火) 00:22:07.36というか、テストできないコードって具体的にどんなのでしょうか
GUIなら自動で再利用できるテストが存在しないというのは分かるけど
0347デフォルトの名無しさん
2013/12/31(火) 00:23:02.370348デフォルトの名無しさん
2013/12/31(火) 00:23:24.53都合が悪くなると、禅問答のような回答をしてｗ
テスト駆動開発に疑問を持ってる人は、テスト駆動だからといって、今までの仕事が減らないと思ってるからだと思うな。
0349デフォルトの名無しさん
2013/12/31(火) 00:24:05.98ドメインが「すべての整数」であるようなコード
時間は無限ではないのだから
すべての整数でテストは出来ない。
0350デフォルトの名無しさん
2013/12/31(火) 00:24:14.58クレームが来たら何かが間違ってたんですよ。
0351デフォルトの名無しさん
2013/12/31(火) 00:25:07.49だから、よくない例ではあるけど >>309 みたなコード
0352デフォルトの名無しさん
2013/12/31(火) 00:26:09.98命題を外延的表現じゃなくて内包表記で書けばいいんじゃ？
0353デフォルトの名無しさん
2013/12/31(火) 00:26:56.38>>309 はテストできるけど
0354デフォルトの名無しさん
2013/12/31(火) 00:29:00.53話が理解できないなら、SSL関係あたりで、オープンソースのハッシュ計算
プログラムのソースが公開されているから見てみな。
入力する値によってテーブルの参照される場所は変わるし、すべてのテー
ブルは使われないから、参照されないテーブルの場所は検証されない。
0355デフォルトの名無しさん
2013/12/31(火) 00:29:13.13ほぽすべてのプログラマはテスト駆動開発をすでにやっている
テストが自動で再利用できる形でないだけ
0356デフォルトの名無しさん
2013/12/31(火) 00:29:23.03> テストツールがバグってないことは誰が証明するのか？
それも「何を持って正しいと言って納品するか」って話と
同じ話なんだよね。
俺はこれこれという道具を使って、これこれのテストコードで示される
テストしたという証明しか出来ない。
テストしたという証明であって、正しいかどうかの証明は
どうやってもできない。
正しいかどうかは、お前が判断してくれって言うしか無いわけ。
それが、納品先が行う「検収」という作業なわけ。
0357デフォルトの名無しさん
2013/12/31(火) 00:30:12.97それがテストできないという理屈が分からないのだが
0358デフォルトの名無しさん
2013/12/31(火) 00:30:28.56全ての値が使われるまでテストし続けるテストを書く。
0359デフォルトの名無しさん
2013/12/31(火) 00:32:29.41> ほぽすべてのプログラマはテスト駆動開発をすでにやっている
お前が言ってるのは、先にテストを考えるってことだろ？
テスト駆動開発っていうのはちゃんとした手順に従った開発のことで、
・テストコードを書く
・実装がないのでテストコードは失敗する
・テストに通る最低限の実装を書く
・これを繰り返す
という開発方法のことで、単にテストを最初に考えるということではないんだよ。
疑うのなら、テスト駆動開発のやり方を調べてみ。
0360デフォルトの名無しさん
2013/12/31(火) 00:32:43.11のらりくらりかわし続ければ検収するから大丈夫です。
担当者もそんなに暇じゃないですから。
ここは完全にダメだなと思わせれば泥をかぶってくれます。
0361デフォルトの名無しさん
2013/12/31(火) 00:32:57.55最初と次の if で取り得る値全部拾ってるんだから、最後の else には、ふつうのテストでは、到達しないでしょ
309がテストできたとしても、そういうケースのコードがあって、それはテスト駆動の通りには書けないよね
0362デフォルトの名無しさん
2013/12/31(火) 00:33:16.83a. 俺がこのテストコードを xUnit のVer.x でテストして、納品先もそのテストを確認して、検収した
b. 俺はテストせずに、納品先が検収した
バグがより少ないコードはどっちでしょうか？
0363デフォルトの名無しさん
2013/12/31(火) 00:33:37.75だからなんなんだよ？
0364デフォルトの名無しさん
2013/12/31(火) 00:35:28.43「バグがより少ない」と言ってることからもわかるように
テストコードが合っても、バグがないことを証明することは
出来ないってわかってるんだよね。
0365デフォルトの名無しさん
2013/12/31(火) 00:35:56.55担当もそこまで期待していないってこと。
ソフトウェアの製造に携わっている人達、つまり自分より質の劣る人たちです。
こいつらじゃ仕方ないかと思ってくれます。
簡単にあきらめてくれます。
0366デフォルトの名無しさん
2013/12/31(火) 00:36:11.68その定義は間違ってる
理由は、その定義は、事前に考えた仕様に未定義部分がないことを前提にしているが、そんなプロジェクトはないから
0367デフォルトの名無しさん
2013/12/31(火) 00:37:00.75口先だけの馬鹿コンサルは黙ってろ。 MD5でもSHA1でも、実際に全ての
テーブル値が参照されることを保証できるテストコードを書いてから出直し
てこい。
0368デフォルトの名無しさん
2013/12/31(火) 00:37:39.89GitHub眺めてても testはずっと更新されないで src ばかり日付新しくなるの山ほどあるよ。
0369デフォルトの名無しさん
2013/12/31(火) 00:38:11.13俺は「テスト駆動開発」の定義を言っただけで、
そんなプロジェクト無いからとか
明後日のレスをしてる時点で
お前が不利だぞｗ
0370デフォルトの名無しさん
2013/12/31(火) 00:38:53.44完全にテストを行うとかカバレッジがどうのとか事前にしつこく売り込んできたときは
必ず質が悪いから。
経験的にわかってる。
テストをしたらバグが増える。
0371デフォルトの名無しさん
2013/12/31(火) 00:40:30.49悪あがきするから品質が落ちるんだと思ってるけどね。
0372デフォルトの名無しさん
2013/12/31(火) 00:41:44.84TDDはともかくテスト自体に対する認識がこれか
0373デフォルトの名無しさん
2013/12/31(火) 00:42:13.00自動で再利用できないだけで、テストはあるでしょう？
0374デフォルトの名無しさん
2013/12/31(火) 00:44:10.65その「テスト駆動開発」の定義が間違ってる
0375デフォルトの名無しさん
2013/12/31(火) 00:45:18.23だからなんなんだよ。
テストコードはバグがないことの証明にはならないって話。
>>374
そうか。じゃあお前のテスト駆動開発の定義ではなく
一般的なテスト駆動開発の定義を引用してくれ。
書かなくていいぞ。引用すれば良い。
0376デフォルトの名無しさん
2013/12/31(火) 00:46:04.191. 最終的に正しいコード(バグがないコード)を作成することを目的に
2. プログラマがコーディングする前に考えた宣言的命題を「暫定的に」正しい仕様として採用し
3. それをテストコードとしてまず作成し
4. コーディングの目的をそのテストをパスすることに還元し
5. そのテストを通るように本体のコードを作成し
6. テストの結果によってコードのみならずテストの修正も行い
7. テストの修正がある場合は仕様の修正として上流にフィードバックし
8. テストが通るまでコーディングするスタイル
リファクタリングの場合は、
1. 最終的に正しいコード(バグがないコード)である状態を変更しないことを目的に
2. すでに作成されたテストコードを再利用し
3. コーディングの目的をそのテストをパスしつつ、リファクタリングの目的を達成することに還元し
4. そのテストを通るように本体のコードを作成し
5. テストが通り、リファクタリングの目的を達成するようにまでコーディングするスタイル
上記のことが記述してある(2〜3日以内にググれば出てくる)参考URL
http://toro.2ch.net/test/read.cgi/tech/1387695847/l50
0377デフォルトの名無しさん
2013/12/31(火) 00:46:04.97もしかして説得力でるんじゃないだろうか？って考えてる。
0378デフォルトの名無しさん
2013/12/31(火) 00:46:39.77さすがだ。正解>>377ｗ
0379デフォルトの名無しさん
2013/12/31(火) 00:47:26.58２ちゃんねるの自分の書き込みを
引用かよ。
038018
2013/12/31(火) 00:47:36.95> if (x < 0) { ... } else if (x >= 0) { ... } else { throw unstableMemoryException("unstable memory error"); }
こんなコード書く奴いたら、即刻プロジェクトから退場いただくわ
> でも出荷する製品レベルなら、これは、いれとくべき仕様だと思う
あほか。
if (x < 0) { ... } else { ... }
にしない理由がないだろ。
0381デフォルトの名無しさん
2013/12/31(火) 00:48:32.66一文字一文字心を込めて打ち込めばバグなんてなくせるだろ？
テストなんて書いてる暇あったら明鏡止水の心で誠心誠意コードを
打ち込んだほうが良い。
0382デフォルトの名無しさん
2013/12/31(火) 00:48:49.07テストは、目的がバグをなくすことであって、バグがないことを証明するプロセスの一部ではあるが、バグがないことを証明するモノではないしな…
0383デフォルトの名無しさん
2013/12/31(火) 00:49:30.38なわけなんだが、中身からっぽのテスト駆動馬鹿は、ツールのブランド
だけが頼り。
食品の産地と鮮度、料理の見栄えが頼りの和食と同じだな。
どんなテストツールを使おうが、馬鹿にやらせた仕事は馬鹿なりの出来
にしかならない。これは間違いない。
馬鹿の書いたクラスは部品として再利用できないシロモノである可能性が
高いが、printfデバッグだって、自動で再利用できる。
0384デフォルトの名無しさん
2013/12/31(火) 00:49:50.73イチローに向かって「なんで10割打たないの？」て感じだろうか
0385デフォルトの名無しさん
2013/12/31(火) 00:50:23.80これが武士道。
0386デフォルトの名無しさん
2013/12/31(火) 00:50:29.55JavaScriptでxがNaNの場合は、
x < 0 ・・・ false
x >= 0 ・・・ false
だよ。
0387デフォルトの名無しさん
2013/12/31(火) 00:50:53.90納期までによりバグの少ないコードを納品できるテスト駆動開発の定義はどちらでしょうか？
0388デフォルトの名無しさん
2013/12/31(火) 00:51:50.77あほですか？
野球のような肉体の芸術とプログラミングのような今日日小学生でもやるような
雑用と一緒にするんですか？
0389デフォルトの名無しさん
2013/12/31(火) 00:52:31.77それを言うのなら、
納期までによりバグの少ないコードを納品できるのどちらでしょうか？
だろｗ
テスト駆動開発の定義はググレカス
0390デフォルトの名無しさん
2013/12/31(火) 00:55:06.19> 野球のような肉体の芸術とプログラミングのような今日日小学生でもやるような
磯野ー（小学生）野球やろうぜー（By 小学生）
0391デフォルトの名無しさん
2013/12/31(火) 00:55:35.09プログラミングで重要なのは、人間の生物学的な認知のミスをいかに削減するかという活動だから、肉体の芸術ですよ
0393デフォルトの名無しさん
2013/12/31(火) 00:55:57.77テスト駆動にすると 380の言う通りになるよ
でも、>>309の例はよくないけど
最初のif と次のifの間に、xのMSBにメモリエラーが起きて、誤判定したら困るようなときにはこういうコードを書く
そしてふつうには、テストできないんだよ
0394デフォルトの名無しさん
2013/12/31(火) 00:56:21.59クズもいいところだなあ。
自分の出来ることは難易度が高いと主張する人はたいてい何もできない
雑用係です。
一生雑用係なんだろなって感じの人。
逆に、自分のできることは難易度が低く簡単なことと考える人は、たいてい
向上していく人です。
10年後には大きな差が生まれます。
0395デフォルトの名無しさん
2013/12/31(火) 00:58:14.87イチローよりは、松井の方が好かれているよね。
将来のIT奴隷として育成するより、テスト駆動を書ける小学生を即戦力
としてスカウトしてくれば解決だね。
0396デフォルトの名無しさん
2013/12/31(火) 00:58:17.67仕様でドメインが整数集合だと思ってたら、実際は整数集合∪{NaN}ってことだよね？
それこそテストの出番だと思うが
0397デフォルトの名無しさん
2013/12/31(火) 00:58:37.86>>380
テスト駆動にすると 380の言う通りになるよ
393 ：デフォルトの名無しさん：2013/12/31(火) 00:55:57.77
>>380
テスト駆動にすると 380の言う通りになるよ
393 ：デフォルトの名無しさん：2013/12/31(火) 00:55:57.77
>>380
テスト駆動にすると 380の言う通りになるよ
0398デフォルトの名無しさん
2013/12/31(火) 00:58:42.03>>309 は言語仕様として x に非整数の値を取らないとしてね
0399デフォルトの名無しさん
2013/12/31(火) 00:59:35.73テストの出番なのはわかるが、
テスト駆動じゃなくてもいいだろ？
0400デフォルトの名無しさん
2013/12/31(火) 01:00:22.26一文字一文字に心を入れるんだ。
そうすればバグは無くなる。
0401デフォルトの名無しさん
2013/12/31(火) 01:00:58.42NaNのテストコードを書かないだろう。
そして実装してみて、バグに気づいて
あとからテストコードを書くだろう。
テスト駆動ではない。
0402デフォルトの名無しさん
2013/12/31(火) 01:01:26.78仮にテストできないとして、そのテストできない事象の対処コードを書いたとする
もしかして、その対処コードを一度も動かさずに納品するってこと？
0403デフォルトの名無しさん
2013/12/31(火) 01:02:38.36>>376の定義では仕様の未定義部分を修正するからテスト駆動ですよ
0404デフォルトの名無しさん
2013/12/31(火) 01:02:53.65ハードエラー(メモリの不良)が起こるような状況なら、そもそもRAM上で走る
プログラムコード自身や、スタック上の一時変数や関数の戻り先が、再現性
なく破壊される可能性があるんだが？
0405デフォルトの名無しさん
2013/12/31(火) 01:03:20.74プログラマの質の低さを物語っているわけだけど、
この質の悪いプログラマというものをどう扱うか、そういった学問があれば、
製品の品質は上がることでしょう。
俺は体罰の導入が効果的だと思う。
実際、効果あるし。
0406デフォルトの名無しさん
2013/12/31(火) 01:03:48.00そうではなくて、テスト駆動では書けないよねって話
テスト駆動は、仕様を宣言的命題としてのテストからコードを導出するんだから、>>380 のいうコードになってしまう
0407デフォルトの名無しさん
2013/12/31(火) 01:05:25.17だから>>309 はよくない例といっているんだけど
それでもテストできないけど、防衛しておきたい場所やケースがあるよね
0408デフォルトの名無しさん
2013/12/31(火) 01:06:22.75>>394が単なる自己都合の思い込みではなく、真理であるというテストコード
を書いてみてはくれないかね？(w
0409デフォルトの名無しさん
2013/12/31(火) 01:06:31.54きちんとドメインを 整数集合∪{NaN} として命題を書けばいいのでは？
0410デフォルトの名無しさん
2013/12/31(火) 01:08:05.400411デフォルトの名無しさん
2013/12/31(火) 01:10:39.97数学者が書くなら一週間でバグが取れただろうね。
残念ながらプログラムはプログラマが書くんだ。
041218
2013/12/31(火) 01:12:13.29ハード障害を考慮すると言う仕様になるだろ
当然そのテストもするし
まあ現実に変数の値がコロコロ変わるなんて環境でまともなソフトが動くとは思えないけど｡
そんな環境なら ECC つけろよと言うべき。
0413デフォルトの名無しさん
2013/12/31(火) 01:12:56.42例えば、 >>309 の変数 x が volatile 宣言された大域変数で、関数処理
実行中に外部スレッドや割り込み処理で値が変わる場合があるとかなら
わからなくもない。
こういう組み込みではありがちなケースで、関数単位の静的なテストしか
想定していないテストツールはまず役に立たない。
0414デフォルトの名無しさん
2013/12/31(火) 01:14:28.90しかし、大切なのは武士の心得、そして一球入魂。。
0415デフォルトの名無しさん
2013/12/31(火) 01:14:35.48>>309 は NaNを取らない言語の例なんだよ
命題としてとっても、そのテストは、ふつうには書けないから、いや環境まで作ればテストできるけどさ
どんなものもドメインにとれば、テスト駆動できるっていうのは、机上の空論ていうかさ
限度を超えたテストファーストになるようなコードは、テスト駆動では、できないよね
0417デフォルトの名無しさん
2013/12/31(火) 01:23:40.49排他処理が不完全とか、あちこちでreturnするようなコードを書く馬鹿
だと、ある条件の時だけロックしたまま関数抜けるとか、ありがち。
結局のところ、安易なツールに頼るより、関わる人間を絞って、コード
レビューを徹底した方が確実なのだよ。
0418デフォルトの名無しさん
2013/12/31(火) 01:30:40.23効率的。
ポイント制にするのもいいかも。
あと5ポイントでクビとか。
0419デフォルトの名無しさん
2013/12/31(火) 01:40:28.13られない無能な採用者も、連座制で一緒にクビにした方がいいと思うよ。(w
0420デフォルトの名無しさん
2013/12/31(火) 01:45:54.32プログラマと違って取り換えがきかないから。
0421デフォルトの名無しさん
2013/12/31(火) 01:46:54.21いいね。お前をすぐ首にできそうｗ
0423デフォルトの名無しさん
2013/12/31(火) 02:01:14.53ありきたりの一般論を言っただけだが、自分の組織の愚痴だと思うなら、
あなたの組織が実際にそうなのでは？
0424デフォルトの名無しさん
2013/12/31(火) 02:24:14.15> プログラマと違って取り換えがきかないから。
実証されていないその仕様のテストはとても簡単だな。
一旦採用者をクビにするなり、交換して開発が滞りなく進んだり、むしろ
以前より捗るようなら、採用者が最大のバグだったということになる。
経験上、実務経験に乏しい大抵のなんちゃってプロマネは、納期1ヶ月前
くらいになると、ソワソワし始めるんだよなぁ。
0425デフォルトの名無しさん
2013/12/31(火) 02:35:16.97限度を超えてなくてもテストは時間とのトレードオフですよ
少なくとも今の技術では、ランダムにドメインから有限個の値を取り出してそれを関数に通して比較してるだけだから
0426デフォルトの名無しさん
2013/12/31(火) 02:48:05.35タイミングでシビアな動作をするコードでxUnitみたいな自動で再利用可能なテストが困難なのはそのとおりだけど、
天才逹によるコードレビューの徹底の方が確実というのには同意しかねる
理由は、コードレビューがやるのは、コードが仕様に沿ってることのチェックで、仕様の未定義部分を検出しないから
仕様が漏らしてるフローの検出のためにも、レビューしてもいいけど、それに加えていくつかテストを実行すべき
ちなみに排他処理用のテストツールはある
0427デフォルトの名無しさん
2013/12/31(火) 02:57:44.18確認するテストってやるの？
やるとしたら、データベースに保存する値すべてに
SQLインジェクションが発生しないことを確認する
テストを書かないといけないってことだよね？
0428デフォルトの名無しさん
2013/12/31(火) 03:06:48.29ある意味正しいよ。
バグがでるのは、多くの場合コードが複雑だから。
仕様を満たしていないバグよりも、
コードが複雑なため特定の場合においてバグに
なっているという事例のほうが多い。
テストがあってもコードの複雑さまでは判断できない。
0429デフォルトの名無しさん
2013/12/31(火) 03:07:34.27全体像を見極めるためにプロトタイプ作るからその時点で挫折する
環境が整った状態が前提になるんじゃないの？
0430デフォルトの名無しさん
2013/12/31(火) 03:11:34.46RDBMS作ってるなら、自動テストやらざるをえないだろうね
RDBMS使う側なら、自動テストが困難だから、予算との戦いになるだろうね
0431デフォルトの名無しさん
2013/12/31(火) 03:13:50.00RDBMSの話じゃないんだけど
SQL発行するコードが合った場合、
いちいちSQLインジェクションが起きるかどうかの
テストコードを書かないといけないのってことなんだけど。
0432デフォルトの名無しさん
2013/12/31(火) 03:16:32.560433デフォルトの名無しさん
2013/12/31(火) 03:18:29.580434デフォルトの名無しさん
2013/12/31(火) 03:20:16.04条件式の構造そのものを動的に弄る場合でもなければそれ使うことを仕様として丸投げが普通だと思ってる
0435デフォルトの名無しさん
2013/12/31(火) 03:21:18.88もらったコードがメチャクチャで複雑でも、見た範囲でコードが正しくてコードが動くなら、レビュー側からプログラマにコードを書きなおせとは言えない
とりあえず正しい以上、コードの変更はただ単純にバグを生産するだけだから
仮に書き直せと言う場合も、コーディングの最中に変更前から意味が変更されてないことを「プログラマが」確認する何かが必要
(プログラマにとってはメチャクチャなモノが通常状態で、訂正指示の方がメチャクチャだから)
それは元のコードがパスしたテストコードしかないでしょう
0436デフォルトの名無しさん
2013/12/31(火) 03:23:33.56> 大抵の言語のプリペア機能がプレースホルダをサポートするからそれ使うんじゃね
普通は使うだろうね。
だけど使ってない可能性がある。
普通は使うけど使っていない可能性のために、
テストコードを書くの？って話をしてるんだけど。
コードレビューをすればば明らかにわかることなんだけど、
コードレビューをしないなら、
（普通はプレースホルダ使ってるよな？）
（だからテストコードなくても問題ないよな？）
でも実際は、SQLインジェクションの問題がありました！
ってならない？って話をしているんだよ。
0437デフォルトの名無しさん
2013/12/31(火) 03:24:41.70> とりあえず正しい以上、コードの変更はただ単純にバグを生産するだけだから
なんのためのテストコードだよｗ
コードをあるべき形にリファクタリングするための
テストコードだろうが。
0438デフォルトの名無しさん
2013/12/31(火) 03:28:08.64ちゃんと使ってるかどうかわからないって状況がちょっとイメージ掴めない
とりあえずチームを信頼できない状況下なら何駆動開発だろうとコードレビューするのが正じゃね？
0439デフォルトの名無しさん
2013/12/31(火) 03:31:26.18例えば、時間が十分にあって、その不都合が起きたら罰金1000万円の場合に、「テストコードを書かないといけないの？」と問われたら、答えは「はい。可能な限りデータを突っ込んで検証するテストを書きましょう」
0440デフォルトの名無しさん
2013/12/31(火) 03:31:41.780441デフォルトの名無しさん
2013/12/31(火) 03:34:27.791. 最終的に正しいコード(バグがないコード)を作成することを目的に
0442デフォルトの名無しさん
2013/12/31(火) 03:36:11.89底辺は大きく見られたいという願望がある
0443デフォルトの名無しさん
2013/12/31(火) 03:38:23.080444デフォルトの名無しさん
2013/12/31(火) 03:39:44.71コードをすっきりさせてバグが発生しづらい状況にするのは当然のこと
テスト済み＝問題なしとするような底辺仕事と一緒にすんなよ
0445デフォルトの名無しさん
2013/12/31(火) 03:40:29.08バグがなければ
汚いコードでもいいと言いたいわけ？
汚いコードというのは、
メンテナンス性が悪くて
コードの見通しが悪くて
コピペが多くて
無駄なコードが有るコードのこと。
テストコードがあっても
解決できないもんだよだ。
コードレビューじゃないと解決できない。
0446デフォルトの名無しさん
2013/12/31(火) 03:41:06.60ミスばっかりする底辺でも動くシステムと、天才でしか回せないシステム
どちらが良いでしょうか？
0447デフォルトの名無しさん
2013/12/31(火) 03:43:00.12入力側ではじくのが一般的じゃね
SQLインジェクション対策で、DBに想定しない値が入ってしまったらなんていうテストはしたことないぞ
0448デフォルトの名無しさん
2013/12/31(火) 03:45:06.20ほぼ機械的にはじけるでしょ
0449デフォルトの名無しさん
2013/12/31(火) 03:45:20.47馬鹿の入り込む余地が無いので
0450デフォルトの名無しさん
2013/12/31(火) 03:45:51.760451デフォルトの名無しさん
2013/12/31(火) 03:47:31.44どんな開発手法でいかに綺麗なコードで書いていても、「問題なし」を宣言するのは何かしらのテストが終わったときだと思うが…
0452デフォルトの名無しさん
2013/12/31(火) 03:48:10.48たとえば、安全な日本と言っても基地外が一匹暴れるだけで多くの人が死ぬこともあるわけです
すなわち馬鹿に扱えないのは、一つの美点となるでしょう
0453デフォルトの名無しさん
2013/12/31(火) 03:50:38.76助けになることは万に一つもありません
ここら辺の原理原則がわからないのは社会経験が浅いからでしょうね
早く就職しなさいと言っておきます
0454デフォルトの名無しさん
2013/12/31(火) 03:51:44.95かっこわる
0455デフォルトの名無しさん
2013/12/31(火) 03:54:00.29> ミスばっかりする底辺でも動くシステムと、天才でしか回せないシステム
なんでその二つを比べるの？
都合良すぎるよね。お前。
0456デフォルトの名無しさん
2013/12/31(火) 03:55:14.23テストコードというのは、
メンテナンスのすべての時点における一貫性のレベルを担保して
コードの各粒度を仕様の宣言的表現で見通して
コピペの意味の同一性を適当なレベルで担保して
無駄なコードを削除したときに本当に無駄だったことを適当なレベルで担保するコードのこと
コードレビューをしても
解決できないもんだよだ。
テストコードじゃないと解決できない。
0457デフォルトの名無しさん
2013/12/31(火) 03:55:20.140458デフォルトの名無しさん
2013/12/31(火) 03:56:39.510459デフォルトの名無しさん
2013/12/31(火) 03:59:17.82テストコードじゃ解決しない問題だな。
0460デフォルトの名無しさん
2013/12/31(火) 04:00:44.92それが事実
ミスしたバカを見つけて、お前が悪いと言っても解決しない
あなたがいる環境は、そんなバカが集まるべくして集まる環境だから
0461デフォルトの名無しさん
2013/12/31(火) 04:01:50.20書いてないってことがありえるからな。
コードレビューしていればわかるが。
0462デフォルトの名無しさん
2013/12/31(火) 04:02:36.78ミスばっかりする底辺でも動くシステムと、半分がバカで半分が天才で回すシステムと、天才でしか回せないシステム
どれが良いでしょうか？
0463デフォルトの名無しさん
2013/12/31(火) 04:03:13.47天才しか扱えないことで、環境が浄化されます
そこには天才しかいられません
0464デフォルトの名無しさん
2013/12/31(火) 04:03:18.050465デフォルトの名無しさん
2013/12/31(火) 04:03:21.98バカを排除しなきゃ直らない
0466デフォルトの名無しさん
2013/12/31(火) 04:03:51.700467デフォルトの名無しさん
2013/12/31(火) 04:04:38.18そこらのわけのわからない派遣プログラマの兄ちゃんにやらせるわけじゃない
0468デフォルトの名無しさん
2013/12/31(火) 04:05:08.99コードレビューの質というか、そもそも「仕事しました」は、客観的にどうやって確認するのでしょうか？
0469デフォルトの名無しさん
2013/12/31(火) 04:05:27.27どれがいいシステムかって？
バグがなくて、
コードがシンプルで
無駄がなくて
見通しがいいコードじゃないの？
0470デフォルトの名無しさん
2013/12/31(火) 04:06:36.190471デフォルトの名無しさん
2013/12/31(火) 04:07:25.07コードはメンテナンス性を高くして
シンプルにしましょうね。
どうせあとで修正することになる。
0472デフォルトの名無しさん
2013/12/31(火) 04:07:58.620473デフォルトの名無しさん
2013/12/31(火) 04:09:22.92半分がバカで半分が天才が、バグがなくて、コードがシンプルで無駄がなくて見通しがいいコードを書くシステムと、
天才だけが、バグがなくて、コードがシンプルで無駄がなくて見通しがいいコードを書けるシステム
どれが良いでしょうか？
0474デフォルトの名無しさん
2013/12/31(火) 04:10:38.22リテラル返してるバカを見たことあるわｗ
0475デフォルトの名無しさん
2013/12/31(火) 04:11:56.640476デフォルトの名無しさん
2013/12/31(火) 04:12:15.56いいコードを書けるシステムがいいですね
何度も言いますが、馬鹿が一匹混ざるだけで綺麗な世界は瓦解します
馬鹿のやることをチェックするために天才を配置するなら、最初から天才に
やらせればいいのです
0477デフォルトの名無しさん
2013/12/31(火) 04:15:17.64馬鹿には指一本触れさせるべきではないのです
0478デフォルトの名無しさん
2013/12/31(火) 04:15:37.18> やっぱ、コーディングとテストは別人がやるべきなんだよ
それはテスト駆動においてもですか？
0479デフォルトの名無しさん
2013/12/31(火) 04:15:51.04そもそもコードがシンプルならメンテナンス性が高いというのは間違い
理由は、一般に、コードをシンプルにするほど隠れたフローが増大し、演算の例外を出力するドメインが増大するから
後者の典型例が二分探索
直交性が高くメンテナンス性が高いコードはシンプルだが、逆は真ではない
0480デフォルトの名無しさん
2013/12/31(火) 04:17:07.080481デフォルトの名無しさん
2013/12/31(火) 04:18:25.01コードが正しいとは限らないし、
コードの質が悪いこともある。
結局のところ、コードレビューを行わないと
意味が無い。
0482デフォルトの名無しさん
2013/12/31(火) 04:19:49.50少なくとも禁固100年は下らないでしょう
0483デフォルトの名無しさん
2013/12/31(火) 04:20:26.23コーディングとテストは別人がやるべきだけど、テストの人に回す前に、コーディングした人が時間が許す限りテストするべき
そして、バグのないコードを書く義務を持つのはコーディングした人であるべき
0484デフォルトの名無しさん
2013/12/31(火) 04:21:03.68>>461みたいな事をされない為にも
プログラマがテスト内容を知るべきじゃない
0485デフォルトの名無しさん
2013/12/31(火) 04:21:56.52テストの人に回す前にコーディングした人がテストをするのはいいとして
テストの人は、どんなテストをするのですか？
テストコードを書くのですか？
0486デフォルトの名無しさん
2013/12/31(火) 04:22:25.04コードが正しいとは限らないし、
コードの質が悪いこともある。
結局のところ、テストコードを通さないと
客観的に示せるモノが何も無い。
0487デフォルトの名無しさん
2013/12/31(火) 04:22:51.640488デフォルトの名無しさん
2013/12/31(火) 04:23:13.470489デフォルトの名無しさん
2013/12/31(火) 04:24:40.47内容を知っていいのはCHECKです
0490デフォルトの名無しさん
2013/12/31(火) 04:25:01.38テスターって何か仕事あるの？
そもそもテスト駆動だったら、テストの内容なんて誰がやっても一緒じゃないの？
0491デフォルトの名無しさん
2013/12/31(火) 04:26:27.060492デフォルトの名無しさん
2013/12/31(火) 04:26:34.09コーダーのテストをテスター1がします
テスター1のテストをテスト2がします
テスト2のテストをコーダーがします
0493デフォルトの名無しさん
2013/12/31(火) 04:27:18.56ブラックボックステスト
コーディングした人が盲点にしてる事項を指摘すること
プログラマのテストの手続きを確認すること
例えば、xUnitのようなテストコードを書いてテストするのは、テスターではなくプログラマの仕事
0494デフォルトの名無しさん
2013/12/31(火) 04:28:30.53だったらテストなんて誰がやっても同じじゃないのか？
0495デフォルトの名無しさん
2013/12/31(火) 04:29:07.05え？ テストって仕様だぞ。
仕様を知らないでどうやってコード書くんだ？
0496デフォルトの名無しさん
2013/12/31(火) 04:30:29.370497デフォルトの名無しさん
2013/12/31(火) 04:30:39.79そもそもテストが必要になるのはミスをするからです
ミスを前提に作業するのはプロとしてあるまじき行為
テストに頼るからミスがなくならないのです
テストをしないのが正解です
一球入魂です
0498デフォルトの名無しさん
2013/12/31(火) 04:31:09.74仕様をどのように確認するかは知らなくても書けるだろ
例えばテストが
入力 1, 2 出力 3
だった場合に
return 3なんてコードかかれないようにする為にはテスト内容は非公開にするべき
0499デフォルトの名無しさん
2013/12/31(火) 04:31:10.21テストコードはプログラマが書くか否か
↓
テストコードはコードを書いた人と違う人が書くべき
↓
テスターは何をするの？ ブラックボックステストをする
↓
じゃあテストコードは誰が書くの？
↓
コードを書いた人が書く
↓
ようするに？
↓
コードを書いた人と同じ人がテストコードを書く
0500デフォルトの名無しさん
2013/12/31(火) 04:31:48.73プログラマは猿だと書いたはずです
0501デフォルトの名無しさん
2013/12/31(火) 04:32:13.21プログラマは、「プログラマ本人が」「時間の許す限り」十分にテストする
テスターは、プログラマ本人では(ソースを見つづけた先入観や経験や環境やツール的に)できないテストや、プログラマが時間の都合でできないテストをする
0502デフォルトの名無しさん
2013/12/31(火) 04:34:04.33自分の主義主張で仕事するなよ。
社の方針を変えたいなら社内で議論を尽くせばいい。
0503デフォルトの名無しさん
2013/12/31(火) 04:35:57.85そういうこと。
0504デフォルトの名無しさん
2013/12/31(火) 04:37:41.64ここって、出社して1時間で他の人が5時までかかる仕事が終了する人たちのスレでしょ？
社の方針がどうであっても、テストくらい書けばいいんじゃね？
バグが少なくなる分には文句言わないだろうし
0505デフォルトの名無しさん
2013/12/31(火) 04:37:52.60自分で納得していれば良い。
0506デフォルトの名無しさん
2013/12/31(火) 04:38:20.56時間の許す限りってのがうさんくさい
やるならとことんやるべきで、適当なことをするぐらいならはやく次のコードにとりかかって欲しい
ここがうさんくさいから、プログラマ本人ではできないテストってのがさらにうさんくさく見える
>>502
いま社の方針を決めてるからパートナーさんは黙ってて
0507デフォルトの名無しさん
2013/12/31(火) 04:43:58.51俺は趣味でプログラムしてるからいいんだよ。
そもそも自分の職種関連の板なんていかないよ。
覗いたことはあるよ。
でも仕事でやってる人は一人もいない。
どうやったらなれますか？とかそういうスレばかりだよ。
そんなもんだって。
だいたい、自分の仕事を赤の他人に聞いてどうすんの。
自分が尋ねられたら答えるの？
答えられる程度のことなんて、職業でやってる人が尋ねてくるわけないでしょ。
職業でやってれば答えられない部分は分かっているんだし、答えられる部分は
質問などする必要が無い。
そういう仕組み。
0508デフォルトの名無しさん
2013/12/31(火) 04:44:47.34とことんやると、二分探索でも30年かかるけど
0509デフォルトの名無しさん
2013/12/31(火) 04:52:17.78なぜとことん＝全探索になるんだよｗ
0510デフォルトの名無しさん
2013/12/31(火) 04:53:03.27この場合のとことんっていうのはテスターがやるのと同程度の意味
0511デフォルトの名無しさん
2013/12/31(火) 04:54:30.92別に隠さなくていいんだよ
0512デフォルトの名無しさん
2013/12/31(火) 06:20:20.71本当のこと書いちゃダメなルールだった？
0513デフォルトの名無しさん
2013/12/31(火) 07:12:32.59いいのに。飲みにいく金もないか？
0514デフォルトの名無しさん
2013/12/31(火) 07:16:11.62色々やらかして選択肢が減っていって最後に落ちるとこがプログラマ。
本人の意思と無関係にやってるんだと思うよ。
0515デフォルトの名無しさん
2013/12/31(火) 07:22:36.79職業でやっている以上、何か出すなら何か得ないといけないわけだから
意見を述べるにしてもSNSやブログ、マイクロブログの類になるはずなんだよね。
匿名はあり得ない。
だいたい、このスレや上下のスレ見てごらんよ。
これ、職業でやってる人の書き込み？
ちょっとレベル低すぎない？
明らかに趣味でこれから入門しようって感じの書き込み。
しかもそんなに本気出してない。
ぱらぱらと雑誌めくる感じのレベルだよね。
ほとんどは無職だと思う。
0516デフォルトの名無しさん
2013/12/31(火) 07:24:00.21逃げたのかね？ 流行の人売業とかか？
元甲子園球児(でも万年ベンチ組)が、メジャー野球を語っているように
見えて仕方ないよ。
0517デフォルトの名無しさん
2013/12/31(火) 07:45:49.16派遣はマ板。
職業人なら会社職業学問理系だろ？
でも、特定できるような突っ込んだ話は出来ないんだからほとんど意味はない。
だから二チャンネルでは野球の話とかするわけ。
仕事の話なんかしない。
あたりまえだろ？仕事の相談なら同僚や上司とすればいい。
わざわざ二チャンネルでするわけない。
0518デフォルトの名無しさん
2013/12/31(火) 07:49:20.930519デフォルトの名無しさん
2013/12/31(火) 07:50:01.710520デフォルトの名無しさん
2013/12/31(火) 07:50:24.84同僚や上司とすべき仕事の相談を
２ちゃんねるでやってるってこと？
0521デフォルトの名無しさん
2013/12/31(火) 07:54:38.36野球の話とかだろ。
0522デフォルトの名無しさん
2013/12/31(火) 07:58:02.43なんか机上の空論ばかりなんだよ。
テストなんて完璧は無理だし
テスト駆動も同様。
最終的には技術力がものをいう。
何をするには技術がいるからね。
0523デフォルトの名無しさん
2013/12/31(火) 07:58:42.59納得できましたか。
0524デフォルトの名無しさん
2013/12/31(火) 09:36:35.580525デフォルトの名無しさん
2013/12/31(火) 09:37:44.150526デフォルトの名無しさん
2013/12/31(火) 10:26:45.600527デフォルトの名無しさん
2013/12/31(火) 10:47:50.60られない寄生虫の数の方が増えてしまったのが今の日本。
能力では敵わないから、ドカタと言って蔑むのが精一杯。所詮寄生虫だから、
工場閉鎖のパナソニックみたいに、宿木がなくなると死ぬしかない。
モノづくり脱却で、金融立国とか言う馬鹿を見かけるが、金融システムは
誰が作るというんだ？
インドやベトナム、中国みたいな新興国だけでなく、アメリカだって、今も
プログラマの希望は多いし、金銭的・社会的な評価も高い。
0528デフォルトの名無しさん
2013/12/31(火) 11:06:53.68＞金融システムは誰が作るというんだ？
所詮、生産活動があっての金融、だと思うのだが
0529デフォルトの名無しさん
2013/12/31(火) 11:08:31.590530デフォルトの名無しさん
2013/12/31(火) 11:10:59.560531デフォルトの名無しさん
2013/12/31(火) 11:11:43.540532デフォルトの名無しさん
2013/12/31(火) 11:13:32.62この世界ほど技術力とかいう漠然としたバズワードなんて存在しないよ
0533デフォルトの名無しさん
2013/12/31(火) 11:14:40.230534デフォルトの名無しさん
2013/12/31(火) 11:17:17.74ねぇ、今のどんな気持ち？どんな気持ち？
0535デフォルトの名無しさん
2013/12/31(火) 11:19:48.040536デフォルトの名無しさん
2013/12/31(火) 13:56:40.31そもそもオブジェクト指向が理解できていないからではないか
手続き思考を引きずったままであることの表れではないか
0537デフォルトの名無しさん
2013/12/31(火) 14:12:12.10テストコードは万能ではない。
テストコードはバグがないことを証明しない
テストに通ってもコードが完成しているとは限らない
テスト駆動はできないか困難な場合がある。
内容としてはこんな所だろ。
0538デフォルトの名無しさん
2013/12/31(火) 14:43:27.86長々と書き込み続ける馬鹿は居たけど、
テスト駆動が困難な理由を説明できた奴が居ない件
0539デフォルトの名無しさん
2013/12/31(火) 14:52:16.250540デフォルトの名無しさん
2013/12/31(火) 15:59:33.37肝心のロジックに集中出来るようにする為に、瑣末なミスは自動的に発覚させるのが本来のテスト。
0541デフォルトの名無しさん
2013/12/31(火) 16:46:27.2930 名前：デフォルトの名無しさん[sage] 投稿日：2013/12/23(月) 21:01:15.80
誰もユニットテストがだめとは言ってないんだよ。
テスト"駆動"がだめという話。
テストはアプリを正しく作る上で必須のものではない。
省略しても正しく動くアプリは作れる。
だけどテスト駆動開発だと、テストを最初に書かないといけない。
これが大きなネックになる。
テスト駆動はコードの書き方の一つ
一つの開発の中で、この関数（クラス）はテスト駆動で作ったが
こっちはテストそのものがないみたいに、バランスよく使うもの
0542デフォルトの名無しさん
2013/12/31(火) 17:23:38.11テスト駆動にあったっけ？
0543デフォルトの名無しさん
2014/01/01(水) 06:48:13.03バグを埋め込んではいけない、子供でも知っている理屈
それがわかっていないからテストが必要になる
本来は必要ない
0544デフォルトの名無しさん
2014/01/01(水) 07:10:57.610545デフォルトの名無しさん
2014/01/01(水) 09:01:10.83こんなところでほざいても何もかわらないわんだけどねw
0546デフォルトの名無しさん
2014/01/01(水) 09:33:29.96実施したかどころか、どんな言語で開発したかさえ、最終的に納品した
プログラムが不具合なく動けば問題ないはずなんだけどね。
実際には、まともな仕様もかけない、そもそも開発能力すらもない、
発注元の担当者や、中間会社が、言語やフレームワーク、開発手法
から、箸の上げ下げに至るまで口出しするからグダグダになる。
0547デフォルトの名無しさん
2014/01/01(水) 09:46:03.62なんでテストを最初に書くのが大きなネックになるんだ？
全く理由が書かれていないんだが。
0548デフォルトの名無しさん
2014/01/01(水) 09:58:14.26顧客囲い込みの為にマイナー言語で開発する奴もいるから
ある程度は他社に引き継げる程度にメジャーな言語でやってもらわないと困る
0549デフォルトの名無しさん
2014/01/01(水) 10:01:48.800550デフォルトの名無しさん
2014/01/01(水) 10:04:58.52つまり、言語やライブラリに対しての知識がない場合にひとつずつ動作を確認してコードを拡張していく方法だ。
俺だけじゃなくて素人のほとんどは少し書いては実行して動作を確認しているだろう。
おまえら、自分がやってる方法にもっともらしい理由をつけてるだけじゃねーの？
0551デフォルトの名無しさん
2014/01/01(水) 10:14:26.15コードを書いて自動でやれるようにするのとは
全然違いますから
0552デフォルトの名無しさん
2014/01/01(水) 10:23:14.05この世に、他人に見せたときにバグがなかったアプリケーションが TeX 以外にあったら見てみたい
0553デフォルトの名無しさん
2014/01/01(水) 10:34:52.960554デフォルトの名無しさん
2014/01/01(水) 10:37:50.00本のなかのVisual Studioも手持ちのVSも2010でそこだけ都合が良いのだが。
0555デフォルトの名無しさん
2014/01/01(水) 10:41:03.120556デフォルトの名無しさん
2014/01/01(水) 10:42:24.81テスト駆動の話だよね
リテラルを引数に突っ込んで戻り値をprintfするような事もテストに含まれるぞ
ひょっとしてテストファーストを勘違いしてないか？
0557デフォルトの名無しさん
2014/01/01(水) 10:42:29.030558デフォルトの名無しさん
2014/01/01(水) 10:46:27.63それをテストと呼ぶのはドカタ界隈だけ
0559デフォルトの名無しさん
2014/01/01(水) 10:53:40.78内包表記にしたって、ランダムにリテラル生成して突っ込んでるだけだし
0560デフォルトの名無しさん
2014/01/01(水) 12:11:44.77それをテストと言わなければなんて呼んでるんだ？
0561デフォルトの名無しさん
2014/01/01(水) 12:40:23.68金をもらうためのレスにマジレスしても意味ないぞw
0562デフォルトの名無しさん
2014/01/01(水) 12:52:15.240563デフォルトの名無しさん
2014/01/01(水) 15:26:08.110564デフォルトの名無しさん
2014/01/01(水) 15:48:37.05printfデバッグ
0565デフォルトの名無しさん
2014/01/01(水) 16:59:23.830566デフォルトの名無しさん
2014/01/01(水) 17:00:55.01やる気の問題です。
0567デフォルトの名無しさん
2014/01/01(水) 17:36:09.940568デフォルトの名無しさん
2014/01/01(水) 17:54:36.56テストだけやってデバッグ(Bug Fix)しないと、JR北海道の脱線事故みたいに
なる。挙句、テスト結果の記録を捏造して帳尻合わせ＆口裏あわせ。
0569デフォルトの名無しさん
2014/01/01(水) 18:06:55.36駆除すべきバグはどうやって見つけるのですか？
0570デフォルトの名無しさん
2014/01/01(水) 18:14:23.66だとするとあなたは能力が低すぎる。
0571デフォルトの名無しさん
2014/01/01(水) 18:14:29.07本来の意味でのテストとはかけ離れたものになっちゃうんだよな。
そのテストケースに含まれてない部分がバグの発生源になるだけの話。
テストケースを書く労力をコードに向けるのと、結局何も変わらない。
0572デフォルトの名無しさん
2014/01/01(水) 18:17:25.43つまり、納品後にバグが見つからなかったアプリケーションがこの世に存在するということですね
TeX以外に
0573デフォルトの名無しさん
2014/01/01(水) 18:21:03.260574デフォルトの名無しさん
2014/01/01(水) 18:36:31.14デバッグはテスト作業を含んでいる。テストなしのデバッグは存在しない。
0575デフォルトの名無しさん
2014/01/01(水) 18:39:37.61とか、そういう日本人的言い訳か？
0576デフォルトの名無しさん
2014/01/01(水) 18:39:40.59間違ってもいいと思っているからテストをするのです。
甘えるのも大概にしたほうが良い。
0577デフォルトの名無しさん
2014/01/01(水) 18:42:35.47作者自身が、「バグが見つかったら賞金を出す」と宣言してる
こんなアプリケーションが他にあるなら挙げてほしい
0578デフォルトの名無しさん
2014/01/01(水) 18:44:15.280579デフォルトの名無しさん
2014/01/01(水) 18:45:18.40テストツールでは見つからなかったと言い訳するのに都合がいい。
依頼主はバグのないプログラムを頼んだのであって、テストツールを使って
くれとは頼んでいないだろうけど。
経験上、本気でテストツール使い始めると、テストツールのデバッグに付き
合わされるハメになるのがオチ。
大昔、ソフィアのICEを繋ぐとボードが動かないとかあったのを思い出すわ。
0580デフォルトの名無しさん
2014/01/01(水) 18:46:15.340581デフォルトの名無しさん
2014/01/01(水) 18:46:48.84どうせ、はした金でしょ。 その手の宣伝行為は暗号化ツールでもやってるよ。
0582デフォルトの名無しさん
2014/01/01(水) 18:52:21.060583デフォルトの名無しさん
2014/01/01(水) 18:53:13.280584デフォルトの名無しさん
2014/01/01(水) 19:03:04.69とは無関係。
0585デフォルトの名無しさん
2014/01/01(水) 19:07:57.78ということは、あなたは「自分のコードの中にバグがあったら給料いりません」と言えるわけか…
0586デフォルトの名無しさん
2014/01/01(水) 19:11:56.87あなたは言えないのですか？
0587デフォルトの名無しさん
2014/01/01(水) 19:16:49.470588デフォルトの名無しさん
2014/01/01(水) 19:25:30.56ニートだからそもそも給料もらってないだろ
0589デフォルトの名無しさん
2014/01/01(水) 19:30:58.95昔はソース持ってきてビルドする時にテストスクリプトが
走って正規のデータとdiff取るようなのもあったけど
今はマルチスレッドが当たり前だしテストが通っても
OKとは判断できなくなってる気がするんだが
あとコードの網羅度が指数関数的になるGUIプログラムとかは
自動テストは不可能だよね
0590デフォルトの名無しさん
2014/01/01(水) 19:45:17.06Web系だと自動でリンククリックしてくれるテスト用アプリがある
0591デフォルトの名無しさん
2014/01/01(水) 20:33:41.87そうですね。
リリースした以上、バグがあることはありえません。
すべて仕様ですから。
0592デフォルトの名無しさん
2014/01/01(水) 20:40:44.69059318
2014/01/01(水) 20:57:18.78バグ見つかってるでしょ。
今のバージョンは 3.1415926 だよ。
http://www.ctan.org/pkg/tex
0594デフォルトの名無しさん
2014/01/01(水) 20:57:47.71コミットする毎にテスターさんがテストしてくれるような
お金がたくさんあるプロジェクトはいいですね。
0595デフォルトの名無しさん
2014/01/01(水) 21:03:09.86テストツール使わないでくれと頼んだ覚えもないんだが。
0596デフォルトの名無しさん
2014/01/01(水) 21:03:30.38クヌース先生が「バグが見つけたら賞金出す」と自信満々でドヤ顔で宣言したのに、それでも見つかったということですよ
0597デフォルトの名無しさん
2014/01/01(水) 21:07:32.57まともなテストツールすら書けないのを棚に上げといて、
テストツール使うのをdisるのはよくないなー
0598デフォルトの名無しさん
2014/01/01(水) 21:08:29.35それ以外のことがテストファーストでできないとかほざいても仕方ない
テストツールなんもつかわず学生に５０００えんずつ渡してボタン連打
させてるとこより全然幸せな仕事してるよ
0600デフォルトの名無しさん
2014/01/01(水) 21:55:50.01060118
2014/01/01(水) 22:07:15.57俺が納入した保守ソフトは納入後バグ見つからないまま廃棄されたよ。
ほとんど使われなかったけど (w
そう言うソフトは珍しくないだろ。
0602デフォルトの名無しさん
2014/01/01(水) 22:07:24.39一文字一文字心を込めて打てばテストなんて必要ありません。
0603デフォルトの名無しさん
2014/01/01(水) 22:10:51.85「使われないモノを開発した」というバグは無視か…
0604デフォルトの名無しさん
2014/01/01(水) 22:24:40.44汎用性の高い他の手法に流れるんだろ
やることわかってるならテスト駆動は楽
0605デフォルトの名無しさん
2014/01/01(水) 22:28:22.99ただ、最初にテストを作ってそれに対していきなり完成した関数やメソッドなりを作ると思ってるなら間違い
テストはどんどん成長していくし、コードも成長していく
0606デフォルトの名無しさん
2014/01/01(水) 22:28:39.95派遣は能力が低いというのもあるけど、心構えがまず違う。
派遣切りは大きな成果があるので「派遣切り」という言葉ができるくらい
一般に行われてる。
0607デフォルトの名無しさん
2014/01/01(水) 22:33:32.77どちらがよいシステムでしょうか
0609デフォルトの名無しさん
2014/01/01(水) 22:35:58.58このスレみてると最初に仕様を決めて、それに対応したテストを作ってそれからコーディングって流れになってるだろ？
それはテスト駆動じゃないよ
0610デフォルトの名無しさん
2014/01/01(水) 22:35:59.400611デフォルトの名無しさん
2014/01/01(水) 22:37:08.61派遣はバグの元です。
派遣がいないことを保証できる分、派遣がいたら回らないシステムのほうが有利です。
0612デフォルトの名無しさん
2014/01/01(水) 22:37:46.52派遣かどうかでシステムが動いたり動かなかったりするわけないだろ
バカじゃないの
0613デフォルトの名無しさん
2014/01/01(水) 22:39:30.870614デフォルトの名無しさん
2014/01/01(水) 22:39:55.79どちらがよいシステムでしょうか
0615デフォルトの名無しさん
2014/01/01(水) 22:40:23.22入り口が派遣かどうかでわかれてる所ならあるよ
0616デフォルトの名無しさん
2014/01/01(水) 22:41:21.79お前無職だろ。
社会に出れば、その程度の常識すぐ身に付く。
0617デフォルトの名無しさん
2014/01/01(水) 22:44:39.81パワーポイントのプレゼン資料をコンパイルして機械語を出力できると思ってた上司を思い出した
0618デフォルトの名無しさん
2014/01/01(水) 22:59:39.70勝手に派遣が入ってくるのではなく、派遣会社に依頼して、しかも違法な事前
面接までやって採用決めているんでないの？ それとも、派遣に逃げられて
恨み節か？
たとえ決済権がなくても、上司に掛け合ってプロパーだけでプロジェクトを
回せばいいのに。
061918
2014/01/01(水) 23:02:44.47だからなに？
ますます意味不なんだが。
>>610
単なる煽りだろうけど...
保守って書いてあるでしょ？
装置にトラブルないと使われないのよ。この前のやつも、10年程度の間に使われたの３回だけだし。
しかも、教育受けた保守員が保守マニュアルに従って使うからイレギュラーな事態がほとんど発生しない。
バグはあるとは思うけど、見つからないわな。
0620デフォルトの名無しさん
2014/01/01(水) 23:33:49.52派遣が蔑まれるのは仕方ないんじゃないの？
0621デフォルトの名無しさん
2014/01/02(木) 00:21:39.200622デフォルトの名無しさん
2014/01/02(木) 01:05:07.25そこで他社の人間が、使うと言えば、採用される
なぜそうするかというと、
雇ったけど、社内でブラブラされると、
月給30万円がただ損になるから
雇ってすぐ、月100万円で他社へ出向させれば、
100-30=70万円の得
企業は簡単にもうけることしか、考えてない
わけのわからない企業に、もうけられるのがイヤなら、
信用できる仲間を集めるか、自分で起業すればよい
0623デフォルトの名無しさん
2014/01/02(木) 01:23:48.69日本の法律が適用されない
選挙権や厚生年金、共済ちゃんとあるの？
心配になっちゃうわ
0624デフォルトの名無しさん
2014/01/02(木) 01:35:10.20テストはどう考えたって必要だろうが
0625デフォルトの名無しさん
2014/01/02(木) 01:36:52.79大半は偽装請負だからな。
0626デフォルトの名無しさん
2014/01/02(木) 01:38:21.210627デフォルトの名無しさん
2014/01/02(木) 01:42:50.93僕の夢は自動コーディング技術を究極までつきつめて、プログラマを労働から解放することです
0628デフォルトの名無しさん
2014/01/02(木) 01:44:30.18もう十分だ
全ての辛いことから解放してあげるべき
0629デフォルトの名無しさん
2014/01/02(木) 01:54:23.20選挙権はあるよ
社会保険はどうかな
でも君が日本の国籍をもらうより簡単
0630デフォルトの名無しさん
2014/01/02(木) 02:02:28.140631デフォルトの名無しさん
2014/01/02(木) 02:07:50.42天才
0632デフォルトの名無しさん
2014/01/02(木) 02:35:04.420633デフォルトの名無しさん
2014/01/02(木) 05:01:08.04つまり、計画犯罪。
ミスではない。
0634デフォルトの名無しさん
2014/01/02(木) 05:47:06.740635デフォルトの名無しさん
2014/01/02(木) 06:54:31.780636デフォルトの名無しさん
2014/01/02(木) 07:16:38.08皆、最高にハイになって幸せそうにするぜ
0637デフォルトの名無しさん
2014/01/02(木) 14:18:12.95彼がもし外国人だとして
3年日本に住めば国籍もらえるよ
永住許可でもせいぜい5年
0638デフォルトの名無しさん
2014/01/02(木) 15:31:26.660639デフォルトの名無しさん
2014/01/02(木) 15:49:37.27品質向上に効果がある=絶対採用する
という一原論でしか考えられない
頭が硬直した人間は手に負えない
0640デフォルトの名無しさん
2014/01/02(木) 16:38:14.16ユニセフがやってきそう。
0641デフォルトの名無しさん
2014/01/02(木) 16:45:34.32良くやるといつも感心する。
0642デフォルトの名無しさん
2014/01/02(木) 16:47:06.10テストなんてやってる場合じゃない。
0643デフォルトの名無しさん
2014/01/02(木) 17:23:03.91グリーンピースやシーシェパードが暴れてくれる方に期待するよ
0644デフォルトの名無しさん
2014/01/02(木) 20:09:40.140645デフォルトの名無しさん
2014/01/02(木) 20:46:28.830646デフォルトの名無しさん
2014/01/02(木) 20:46:33.84テスト駆動でバグセロとか、ほとんどツール屋のステマでしょ。
0647デフォルトの名無しさん
2014/01/02(木) 21:56:40.56その日の仕事が出社して30分で終わる人はやる価値があるってことか…
0648デフォルトの名無しさん
2014/01/02(木) 22:05:45.08希望的観測としては手戻りが減るんじゃないかと思うんだがどうなんだろうな
0649デフォルトの名無しさん
2014/01/02(木) 22:09:28.29可能な限りバグを少なくするのが目的だから、バグゼロを目指すなら別の開発手法を試した方がいいと思う
念力駆動とか
0650デフォルトの名無しさん
2014/01/02(木) 22:26:25.62バグを組み込む気が無ければテストは必要ない。
つまり、テストをしている限りバグは無くならない。
テストは撤廃するべき。
0651デフォルトの名無しさん
2014/01/02(木) 22:31:54.72ぜひテスト不要教でも設立して下さい
0652デフォルトの名無しさん
2014/01/02(木) 22:34:44.05画面を2回以上スクロールする量をコーディングしてバグが一つもなければ拍手
そういう人達が来る板だから、あなたは宗教板へ行った方がいいと思われる
0653デフォルトの名無しさん
2014/01/02(木) 22:47:27.170654デフォルトの名無しさん
2014/01/02(木) 22:55:16.700655デフォルトの名無しさん
2014/01/02(木) 23:15:16.980656デフォルトの名無しさん
2014/01/02(木) 23:26:43.19そのためにはテスト駆動開発が必要なのです
0657デフォルトの名無しさん
2014/01/02(木) 23:35:12.710658デフォルトの名無しさん
2014/01/02(木) 23:45:16.090659デフォルトの名無しさん
2014/01/03(金) 00:20:40.98正しく動くことを確認するアプローチでは、まず、確認すべき正しい『結果』を定める。結果指向のテストである。
これに対して、バグを見つけるためのテストでは、どのようなバグを見つけられるかを、予め定めておくことはできない。
「テスト項目」は、バグを見つけるためのテストに適さない
http://www.aerith.net/design/test_bug-j.html
0660デフォルトの名無しさん
2014/01/03(金) 00:21:32.73ステマ乙。
0661デフォルトの名無しさん
2014/01/03(金) 01:58:36.03実は、どのようなバグを見つけられるかは、ある程度は分かっている
例えば、それをセマンティクスを無視して検出する古典的ツールが lint
現実の開発では、はじめからまったく予想もできなかったバグはごくごく少数
ほとんどのバグは隣で「これ」と言われたら、バグを入れた本人ですら「あっ」と即理解できるバグ
問題は、そのシンプルなミスが広大なコードの中に薄く混入しているという点
0662デフォルトの名無しさん
2014/01/03(金) 02:06:59.100663デフォルトの名無しさん
2014/01/03(金) 02:13:42.11バグの検出なんかできねぇよ。 つぅか、lint程度の構文チェック機能は
最近のコンパイラなら普通に入ってる。
0664デフォルトの名無しさん
2014/01/03(金) 02:18:37.290665デフォルトの名無しさん
2014/01/03(金) 02:47:06.68セマンティクスを無視して検出する ＝ 論理を無視して構文だけをチェックする
ですよ
もっと言うと、実際の現場では、普通のコンパイラで -Wall でコンパイルすれば検出できてたバグがほとんど
0666デフォルトの名無しさん
2014/01/03(金) 02:51:20.820667デフォルトの名無しさん
2014/01/03(金) 03:02:20.66int a;
int n;
int table[4]={1,2,3,4};
for(n=0;n<4;n++)
{
a=table[n];
...(略)
}
みたいなコードの「n<4」が「n<=4」となっていてもまず検出できない。
あとテーブルの数を増やすとループ回数と整合とれなくてバグったり。
単純な初期化処理のループなら、毎回すべての値が参照されるけど、例えば
テーブル参照してコマンドライン引数と照合するような処理の場合、仕様上は
未定義の引数を与えてテーブルの最後まで参照しないとバグが見つからない
とかある。 WindowsやLinuxみたいなメモリ保護のあるOS下であっても、要素
数を超える配列をアクセスしてもページ境界を超えなければ保護エラーには
ならない。
本来は「n<(sizeof((table)/sizeof(table[0]))」とか
#define LOOP_COUNT (sizeof((table)/sizeof(table[0]))と定義しておいて
「n<LOOP_COUNT」とか書くべき。 でもテストツールではこういう不適切な
コーディングは検出できない。
0668デフォルトの名無しさん
2014/01/03(金) 03:04:27.96それは誰でもな
ただ、1日8時間や場合によってはそれ以上の時間を気合が入った状態に保つ事は難しいし
それをしたところでメリットがないのが問題
0669デフォルトの名無しさん
2014/01/03(金) 03:09:56.30禅の心、そして一球入魂です。
0670デフォルトの名無しさん
2014/01/03(金) 03:11:09.98int a[4],i;
for(i=0; i<=4; i++) { a[i] = ...}
はツールが検出して警告出してくれますよ
0671デフォルトの名無しさん
2014/01/03(金) 03:14:21.34飛べる鳥で、気合入れないと飛べない鳥とかおらへんし、ヤンバルクイナとか
いくら気合入れても飛べへんで〜。
それとも、オッチャン気合入れたてら自分がイチローになれた人生があった
かもしれんと思うてるの？ おるよねぇ、そういうオッチャンは安酒場に。
0672デフォルトの名無しさん
2014/01/03(金) 03:17:24.63そのマクロを ( ) で囲んだり関数の引数にしたりしたときに新たにバグが生まれそうな気がしてならない
0673デフォルトの名無しさん
2014/01/03(金) 03:17:46.64気合では1/10だと書かれていました。
禅と入魂なら0にできる。
とってもお得です。
0674デフォルトの名無しさん
2014/01/03(金) 03:22:02.83ただ残念なことに、この世には魂が存在しないんですよね…
0675デフォルトの名無しさん
2014/01/03(金) 03:23:28.320676デフォルトの名無しさん
2014/01/03(金) 06:58:30.79> int table[4]={1,2,3,4};
バグの匂いがプンプンｗ
067718
2014/01/03(金) 08:53:47.510678デフォルトの名無しさん
2014/01/03(金) 09:05:37.14一球入魂するとC++に見えるけどな。
0679デフォルトの名無しさん
2014/01/03(金) 09:13:05.650680デフォルトの名無しさん
2014/01/03(金) 09:26:19.61・最初に実装するときはテストは書かない
・バグが出たら、テストを書いて再現を確認してから直す
くらいが負担も少なくてやりやすい
TDD の最後の D が Development じゃなく Debug の略になってる感じ。
元来が完璧主義者なので、TDD でやるぞ！と意気込むと、バグなんて出すわけのないような簡単なコードまで
きっちりテストを書きたくなってしまって、結果コスト的に見合わないただの自己満足になってしまう。
(プログラマってそういう奴多くない？)
だから、それはやめて、実際にバグを出したところだけテストを書くスタイルに落ち着いた。
0681デフォルトの名無しさん
2014/01/03(金) 09:31:46.32ツールは何使ってるの？
0682デフォルトの名無しさん
2014/01/03(金) 10:09:08.48マクロの副作用を防ぐため、#define の定義を()で囲むのは、MISRA-Cの
必須項目だったと思うけど？
0683デフォルトの名無しさん
2014/01/03(金) 11:14:24.490684デフォルトの名無しさん
2014/01/03(金) 11:45:11.64zen codingってやつかしら？
0685デフォルトの名無しさん
2014/01/03(金) 11:52:33.83そのカッコで囲んだモノをさらにカッコで囲むと新たにバグが生まれることがあるんすよ…
しかもなんだよ、これ↓
#define LOOP_COUNT (sizeof((table)/sizeof(table[0]))
グローバル変数使ってるとか、tableのnullチェックやってないとか、突っ込みどころ満載なんだけど
0686デフォルトの名無しさん
2014/01/03(金) 12:27:26.63式ではない値を含めて#defineを全て括弧で囲っていなくて、演算子の優先順位の
関係でバグが出ることはあるが、宣言に括弧を使ってバグが出るとは初耳だなぁ。
> グローバル変数使ってるとか、tableのnullチェックやってないとか、突っ込みどころ満載なんだけど
グローバル変数？ 外部ファイル等から動的に読み込むなら空配列のチェック
も必要だが、プログラム定数配列で空配列かどうかチェックする必要はない。
Cでも別に関数内部でstatic宣言して、その後に関数内部で#defineすれば
いいだけ。 C++のクラスならstaticなメンバ関数やConst型のメンバ変数、
enum値にするとか、いくらでも書き方はある。
そもそも、あくまで例を出しただけだが、馬鹿はあさっての方向にしか突っ
込みできんのだね。
0687デフォルトの名無しさん
2014/01/03(金) 12:36:12.57仮に、プログラム定数配列で空配列かどうかチェックする必要がないほど頑健なら、そもそもそのマクロは必要ない
0688デフォルトの名無しさん
2014/01/03(金) 12:42:49.33カッコの対応をよく見れ↓
#define LOOP_COUNT (sizeof((table)/sizeof(table[0]))
これは、LOOP_COUNT) という狂った使い方をするマクロでしょ？
0689デフォルトの名無しさん
2014/01/03(金) 12:46:00.970690デフォルトの名無しさん
2014/01/03(金) 12:54:42.800691デフォルトの名無しさん
2014/01/03(金) 12:55:12.17今の時代に合わなさ過ぎる。
0692デフォルトの名無しさん
2014/01/03(金) 13:07:46.91テンプレートプログラミングといいながら、実際はテキストを置換してバグを混入させるだけの嫌なモノがまた流行ってしまいまして…
0693デフォルトの名無しさん
2014/01/03(金) 14:09:57.34本質が同じということが理解できてないという時点で論外。
0694デフォルトの名無しさん
2014/01/03(金) 14:17:21.98> int table[4]={1,2,3,4};
> バグの匂いがプンプンｗ
何が変なのかさっぱりわからん。
誰か解説よろ
0695デフォルトの名無しさん
2014/01/03(金) 14:24:46.23えっ？
0696デフォルトの名無しさん
2014/01/03(金) 14:25:18.90・後で要素追加するときに、修正が2箇所にならないように int table[]={1,2,3,4}; とする
・グローバル変数で table という名前はやめれ
0697デフォルトの名無しさん
2014/01/03(金) 14:35:44.58> ・後で要素追加するときに、修正が2箇所にならないように int table[]={1,2,3,4}; とする
非常にくだらない。煽りではなく。
> ・グローバル変数で table という名前はやめれ
>>667を見てどうしてtableがグローバル変数と思えるのか不思議
それにどちらにしてもバグとは言えない。
0698デフォルトの名無しさん
2014/01/03(金) 14:40:56.37本当に要素数が５でいいのかは不明。
int table[4]={1,2,3,4}; から int table[5]={1,2,3,4,5}; に変える場合は本当に変える意思が
あると考えられるし、間違って int table[4]={1,2,3,4,5}; としてもエラーになるんだから害なし。
0699デフォルトの名無しさん
2014/01/03(金) 14:45:13.97tableがグローバル変数じゃなくて局所変数だというなら、その局所変数の変数名をマクロに直書きするは「バグだ」と断言していいと思う
0700デフォルトの名無しさん
2014/01/03(金) 14:45:36.970701デフォルトの名無しさん
2014/01/03(金) 14:50:42.23int table[6]={1,2,3,4,5}; とタイプミスしてエラーにならずに table[5] に変な制御コードが入るとか考えないの？
0702デフォルトの名無しさん
2014/01/03(金) 15:05:25.37> int table[6]={1,2,3,4,5}; とタイプミスしてエラーにならずに table[5] に変な制御コードが入る
そりゃ可能性はある。その上でどっちを選ぶ？って話。
俺は int table[5]={1,2,3,4,5}; を選ぶし、バグの匂いとか言うのは違うんじゃね？
0703デフォルトの名無しさん
2014/01/03(金) 15:09:32.42tableがグローバル変数だというなら、for 文がグローバルスコープにあることになる。バグ以前だな。
0704デフォルトの名無しさん
2014/01/03(金) 15:10:28.570705デフォルトの名無しさん
2014/01/03(金) 15:15:07.555個で要素が順番に並んでるときは int table[5]={1,2,3,4,5}; だとしましょう
10個のときは？ 50個のときは？ 数値がランダムに並んでるときは？
個数に応じて脳ミソ使ってコーディングスタイルが変わるなら、それはバグの元でしょう
そもそも int table[5]; みたいに宣言時にマジックナンバーを見たらバグだと思うべきではなかろうか
0706デフォルトの名無しさん
2014/01/03(金) 15:17:12.25コンパイルエラーが出てないとすれば、変数宣言の後とfor文の前にmainが省略されてるんだよ
0707デフォルトの名無しさん
2014/01/03(金) 15:18:13.52テスト前提でプログラムアーキテクチャまで変更しなきゃならんとなれば
(しかも可読性が下がる方向で)受け容れられん向きも多くなるわな。
0708デフォルトの名無しさん
2014/01/03(金) 15:30:24.98> 10個のときは？ 50個のときは？
50個のとき int table[50] = { ・・・
なんて本当に書くのか？個数に応じて方法を変えるのが当たり前だろ？それは「スタイル」の問題じゃないよ。
[ ]の中を空白にするかしないかという論点であって、リテラルを直書きするかどうかは論点外。
0709デフォルトの名無しさん
2014/01/03(金) 15:32:12.190710デフォルトの名無しさん
2014/01/03(金) 15:32:41.26＞個数に応じて脳ミソ使ってコーディングスタイルが変わるなら
変えろよ。
個数に応じて最適な方法が変わってくるに決まってんだろ。
0711デフォルトの名無しさん
2014/01/03(金) 15:38:39.74個数に応じて脳ミソ使って方法を変える and しかも修正箇所が複数ある ＝ バグの元
0712デフォルトの名無しさん
2014/01/03(金) 15:38:47.330713デフォルトの名無しさん
2014/01/03(金) 15:41:22.71一切変更する予定がなくても 1,3,4,5 と打ち間違えてて、後で気付いて修正することもある
0714デフォルトの名無しさん
2014/01/03(金) 15:43:17.68何か論理的に決まる組み合わせによって数が不変の場合だけだな。
その時は[ ] の中に数を明記する。マジックナンバーは使わんが。
0715デフォルトの名無しさん
2014/01/03(金) 15:48:11.060716デフォルトの名無しさん
2014/01/03(金) 15:52:09.87エアギターのほうがまだ意義ある。
お前ら使ってるツールすら言えないじゃん。
0717デフォルトの名無しさん
2014/01/03(金) 15:57:14.19だけど、
int table[3] = {1,2,3} ; の意味はtable.fill, table.set({1,2,3}), で何fillしてるか分からないんだよね
たまに 0 以外を埋めるバカコンパイラもあるし
0718デフォルトの名無しさん
2014/01/03(金) 15:58:24.55むしろ助かりそうなもんだが。
0719デフォルトの名無しさん
2014/01/03(金) 16:16:30.03そして往々にしてその願いは叶えられないものなのだ
ＯＳ変わった時に発覚したりとかな
0720デフォルトの名無しさん
2014/01/03(金) 16:17:25.50↓
ﾌﾌﾌﾌﾌはバカコンパイラ。
こういう流れなのかな？
0721デフォルトの名無しさん
2014/01/03(金) 16:25:19.470722デフォルトの名無しさん
2014/01/03(金) 16:26:39.440723デフォルトの名無しさん
2014/01/03(金) 16:30:08.28テストはバグを埋め込むことを目標にしてるからするんだろ。
バグを入れる気が無かったらテストする意味ないだろ。
しかも、お前らがやってるのってエアコーディング、エアテストだろ。
コードも書かずに脳内でコード書いたーテストしたーってだけだろ。
それじゃなきゃ具体的なツール名くらいあるはずだろ。
0724デフォルトの名無しさん
2014/01/03(金) 16:34:51.61ツール名が知りたいよー！
と素直に書くべき
0725デフォルトの名無しさん
2014/01/03(金) 16:36:25.48ツール名が知りたいよー！
0726デフォルトの名無しさん
2014/01/03(金) 16:37:32.460727デフォルトの名無しさん
2014/01/03(金) 16:39:26.200728デフォルトの名無しさん
2014/01/03(金) 17:04:10.73>テストはバグを埋め込むことを目標にしてるからするんだろ。
私の頭には蛆が湧いてます…のようにしか読めない。
0729デフォルトの名無しさん
2014/01/03(金) 17:09:32.95↓
テスト必要ない。
バグを埋め込む。
↓
テストができる！
0730デフォルトの名無しさん
2014/01/03(金) 17:12:09.64私の頭には蛆が湧いていますなんて自己紹介はもういいからｗ
0731デフォルトの名無しさん
2014/01/03(金) 17:15:30.980732デフォルトの名無しさん
2014/01/03(金) 17:16:58.20ツールが極秘なのはわかった。
NDAとかCIAとかいろいろあるらしいもんな。
そこは理解してやる。
手法名くらい言っても逮捕されないだろ。
0733デフォルトの名無しさん
2014/01/03(金) 17:27:35.41そもそも、自分で手法を決定し、自分でその手法を運用し、自分でコードを書き、
なんて仕事がそうそうあるわけじゃないし、実は無職とかニートの知ったかとか？
0734デフォルトの名無しさん
2014/01/03(金) 17:32:49.95仮に本当にテストでバグが少なくなるなら、それは金のなる木だから、こんなところで話すわけないでしょ
0735デフォルトの名無しさん
2014/01/03(金) 17:35:26.76いや話すだろ。
0736デフォルトの名無しさん
2014/01/03(金) 17:35:56.84コンパイル通れば全てOKというC言語のルールのみ知ってるという奴は完全スルーでいいと思う。
どうせ運営から金貰ってスレを伸ばそうとしているだけで話の内容なんてどうでもいいんだろうしｗ
0737デフォルトの名無しさん
2014/01/03(金) 17:37:51.84いや話すだろ。
0738デフォルトの名無しさん
2014/01/03(金) 17:39:54.73真っ当に使えば減るし、使いこなしてる者にとっては、教えたからといって自分の領分を浸蝕はされない。
0739デフォルトの名無しさん
2014/01/03(金) 17:41:43.380740デフォルトの名無しさん
2014/01/03(金) 17:41:45.09コンパイルの選択で速度が上がっても、それは金のなる木ではない
ゆえにどんどん話す
0741デフォルトの名無しさん
2014/01/03(金) 17:43:31.58ソフトウェアは無料でコピーできる特殊な製品
ゆえに、生産性が上がる技術があったら、それは金のなる木だから、何があっても隠し通す
しかし、言語のことを全世界に公開するネットで話している
つまり、言語で生産性が上がるというのは嘘
0742デフォルトの名無しさん
2014/01/03(金) 17:49:21.810743デフォルトの名無しさん
2014/01/03(金) 17:53:00.860744デフォルトの名無しさん
2014/01/03(金) 18:00:22.22> 10個のときは？ 50個のときは？
世の中、こんなコードはごまんとあるわけだが？
ttp://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-721.26/wtf/MD5.cpp
0745デフォルトの名無しさん
2014/01/03(金) 18:01:57.24思い付きをそれらしく見せたいんなら、もう少し練ろうね。
0746デフォルトの名無しさん
2014/01/03(金) 18:05:55.60配列のサイズに関わらず、きちんと一貫した使い方をしてるのを理解できましたか？
0747デフォルトの名無しさん
2014/01/03(金) 18:06:45.51だがその名称を公開すると当社の利益に影響する
守秘義務契約にも違反する
従って公表できない
0748デフォルトの名無しさん
2014/01/03(金) 18:24:38.31仕様も同時に修正する自作ツールがたくさんあるし
0749デフォルトの名無しさん
2014/01/03(金) 18:39:35.48つまんないから、2点。
0750デフォルトの名無しさん
2014/01/03(金) 18:41:26.34配列を受け取って処理する関数はあるが、配列の宣言と定義がここにはない。
そっちはどうなってるんだ？
0751デフォルトの名無しさん
2014/01/03(金) 18:57:36.450752デフォルトの名無しさん
2014/01/03(金) 19:00:05.910753デフォルトの名無しさん
2014/01/03(金) 19:21:04.950754デフォルトの名無しさん
2014/01/04(土) 01:44:04.02配列のサイズを宣言する事がテストの役割を果たしてるんだな
0755デフォルトの名無しさん
2014/01/04(土) 01:49:23.95テスターとは関係ないプログラマのテストコードを業績評価に入れたら別の悪いことが起きそうな気がする
テストコードは成果物(バグ)がなくて当然のモノだから、昔みたいにコード1行10円とかになりそうな気がする
0756デフォルトの名無しさん
2014/01/04(土) 01:54:36.81テストもいずれ不要になっていくんじゃないだろうか
0757デフォルトの名無しさん
2014/01/04(土) 09:18:09.71キーボードショートカットすら使いこなせない雑魚を排除せよ
0758デフォルトの名無しさん
2014/01/04(土) 09:48:43.40ファイルの保存みたいな単純作業とテストを一緒にすんじゃねーよ。
0759デフォルトの名無しさん
2014/01/04(土) 11:35:41.74どういうふうに解釈した？
純粋に質問
0760デフォルトの名無しさん
2014/01/04(土) 12:18:37.400761デフォルトの名無しさん
2014/01/04(土) 13:30:25.83流行る＝ツールや事例がたくさんあって選択肢が広がる
良いモノである必要はない
0762デフォルトの名無しさん
2014/01/04(土) 13:44:15.12実際に使えるかどうか判断して、使えなかったら捨ててしまえばよいだけ。
0763デフォルトの名無しさん
2014/01/04(土) 19:32:07.59実際に使えるかどうか判断して、使えなかったら捨ててしまえばよいだけ。
○○○に "当てはまらないもの をあげよ。
そして理由も述べよ。
例 プログラミング。理由 時間が無駄になるから
0764デフォルトの名無しさん
2014/01/04(土) 19:38:41.950765デフォルトの名無しさん
2014/01/05(日) 05:50:40.000766デフォルトの名無しさん
2014/01/05(日) 09:48:17.000767デフォルトの名無しさん
2014/01/05(日) 10:08:49.09今でさえ文法エラーはリアルタイムで指摘される
次世代はテストさえ先に書いておけばリアルタイムで単体テストぐらいしてくれるんじゃないだろうか
もしくは、テストすら自動生成される時代が来るのではないか
0768デフォルトの名無しさん
2014/01/05(日) 10:37:56.540769デフォルトの名無しさん
2014/01/05(日) 12:23:39.36テストの基となる仕様が存在しないわけで。
仕様を数学的に記述した場合はそれを読み込んでテストの自動生成は可能だが、
テストを自分で書く方が仕様を数学的に記述するよりも低コストってのが現在の常識。
0770デフォルトの名無しさん
2014/01/05(日) 12:36:46.56じゃあ黒い破線にすればいいのでは？
0771デフォルトの名無しさん
2014/01/05(日) 15:17:21.66メリットも用途もあんまりないな。
ユニットテスト自動生成はもうあるだろ。
0772デフォルトの名無しさん
2014/01/09(木) 00:26:25.50流行る＝世間の大多数が使いたがる。
で、世間の大多数は優秀なのか否かを考えれば、流行るもののレベルが判るだろ。
0773デフォルトの名無しさん
2014/01/09(木) 01:23:38.10みんな嘘だと知ってるのに、納品するときには、書類上はテストをしたことになってる
みんなその矛盾を解決できないかと模索してるんだよ
0774デフォルトの名無しさん
2014/01/11(土) 00:32:20.20そんな設定できたっけ？
0775デフォルトの名無しさん
2014/01/11(土) 00:33:27.70ほんとだ
全分岐テストするぐらいなら自動生成できるんだな
知らなかったよ
0776デフォルトの名無しさん
2014/01/11(土) 04:26:41.73ではなく、動作をどう確認するかすら分からないのにコードを書き始める連中が大量生産されていくというわけか…
0777デフォルトの名無しさん
2014/01/11(土) 04:44:39.430778デフォルトの名無しさん
2014/01/11(土) 09:41:28.020779デフォルトの名無しさん
2014/01/11(土) 13:31:43.77それにマッチする実装作業を別の誰かに任せられる
そういうワークフローとセットじゃないと意味ないんじゃ
ペアプロと相性よさそうだな
0780デフォルトの名無しさん
2014/01/11(土) 13:45:46.03完璧なテストがかければな。
1なら2、2なら4を返す関数に、
3を入れたときどうするかなんてわからないんだよ。
想像はできるかもしれないがな。
結局、”仕様"が必要であり、
仕様さえあれば、それにマッチする
実装作業を別の誰かに任せられる
0781デフォルトの名無しさん
2014/01/11(土) 13:47:46.60> ペアプロと相性よさそうだな
ペアプロは担当者わけの仕組みじゃない。
同じコードを見ていなければ意味が無い。
たとえば、一人が書いているテストコードを
もう一人が読んでレビューしなければならない。
0782デフォルトの名無しさん
2014/01/11(土) 18:56:54.36完全な仕様を文書化できるなら最初からコードで書けって話であって、
完全に文書化できないからこそ「こういう入力ではこういう出力」
というテストが必要になるんじゃねえのか。
0783デフォルトの名無しさん
2014/01/11(土) 19:20:26.43先にコード書いたら、テストを作るまで帰れないじゃん
作業途中でも帰りたいんだよ
あと、突然にミーティングが入った時に、帰ってくるまでテスト回しておくとかもやりたいし
0784デフォルトの名無しさん
2014/01/11(土) 19:27:30.32> 先にコード書いたら、テストを作るまで帰れないじゃん
帰ればいいんじゃね？
> あと、突然にミーティングが入った時に、帰ってくるまでテスト回しておくとかもやりたいし
テストが中途半端だったらエラーになるし、
コードが出来てなくてもエラーになる。
エラーを何度も出現させてなんの意味があるの？
0785デフォルトの名無しさん
2014/01/11(土) 19:29:29.77仕様は穴があるから、解釈が幾通りもあって多人数でやると失敗しまくる
1なら2、2なら4を返す関数に、 3を入れたときどうするか書いてないのが仕様なんだから
必要なのは、書き上げたコードの何をどう確認するかを、コードを書く前に決めておくこと
頭の中にあってもいいけど、多人数のときには、それがテストコードになる
0786デフォルトの名無しさん
2014/01/11(土) 19:31:54.22違うぞ。仕様は入力と出力を記述するだけなんてことは絶対しない。
仕様には、入力と出力の間にある、処理の内容を書くもの。
0787デフォルトの名無しさん
2014/01/11(土) 19:34:42.09明日の朝と1週間後
エラーの報告を受けるのはいつがいいですか？
0788デフォルトの名無しさん
2014/01/11(土) 19:37:12.58なぜ明日の朝と1週間後？
開発に1週間かかるから？
じゃあさ、毎朝コードがまだできていないことによる
エラー報告を1週間貰って嬉しいという理由を教えてくれ。
0789デフォルトの名無しさん
2014/01/11(土) 19:37:28.58仕様は処理の内容を書くものだから、何を入れれば何が出てくるかは書いてない
0790デフォルトの名無しさん
2014/01/11(土) 19:38:08.19プログラム全体が出来上がってからテストを書くとは
ひとことも言ってないんだがね。
0791デフォルトの名無しさん
2014/01/11(土) 19:39:09.14いやｗ 処理（＝関数）があれば
入力から出力はわかるだろ。
入力と出力がわかっても
関数の内容はわからないけどさ
0792デフォルトの名無しさん
2014/01/11(土) 19:39:31.810793デフォルトの名無しさん
2014/01/11(土) 19:40:00.470794デフォルトの名無しさん
2014/01/11(土) 19:47:19.54月曜: sin関数を実装する
火曜: cos関数を実装する
水曜: tan関数を実装する
木曜: exp関数を実装する
金曜: テストを書いてテストする
土曜: 前の日までの修正をする
月曜: テストを書く
火曜: sin関数を実装して、寝てる間にsin関数のテストをする
水曜: 前の日までの修正をして、cos関数を実装して、寝てる間にsin関数とcos関数のテストをする
木曜: 前の日までの修正をして、tan関数を実装して、寝てる間にsin関数とcos関数とtan関数のテストをする
金曜: 前の日までの修正をして、exp関数を実装して、寝てる間にsin関数とcos関数とtan関数とexp関数のテストをする
土曜: 前の日までの修正をする
土曜日の朝に残りの作業の見積もりができるのはどちらでしょうか
0795デフォルトの名無しさん
2014/01/11(土) 19:51:51.68コードを書いた後に動作確認をするんだけど、その動作確認用のコードを先に用意するか、後に用意するかの違い
0796デフォルトの名無しさん
2014/01/11(土) 19:54:14.05処理を記述して、入力と出力については典型的なモノしか分からないのが仕様
0797デフォルトの名無しさん
2014/01/11(土) 19:56:09.45ほらな。やっぱりお前が馬鹿だった。>>790で指摘したとおりだな。
月曜: sin関数を実装する。sin関数のテストを書いて、sin関数のテストを実行する。
火曜: 前日までの修正をしてcos関数を実装する。cos関数のテストを書いてsin関数とcos関数のテストを実行する。
水曜: 前日までの修正をしてtan関数を実装する。tan関数のテストを書いてsin関数とcos関数とtan関数のテストを実行する。
木曜: 前日までの修正をしてexp関数を実装する。exp関数のテストを書いてsin関数とcos関数とtan関数とexp関数のテストを実行する。
金曜: 前日までの修正をして終わり
土曜: 休み
0798デフォルトの名無しさん
2014/01/11(土) 19:57:33.50最後に全部まとめてしかできんのか？ｗ
0799デフォルトの名無しさん
2014/01/11(土) 20:01:40.71火曜: sin関数を実装して、sinのテスト結果は次の日の朝までわからない。sin以外のテストは失敗する。
水曜: cos関数を実装して、cosのテスト結果は次の日の朝までわからない。sinとcos以外のテストは失敗する。
木曜: tan関数を実装して、tanのテスト結果は次の日の朝までわからない。sinとcosとtan以外のテストは失敗する
金曜: exp関数を実装して、tanのテスト結果は次の日の朝までわからない。
土曜: tanのテスト結果が終わって、やっとコミットする。エラーが出てる状態でコミットしてはいけないので終末やっとコミットできる。
ひどい開発スタイルだｗ
もっと小さく開発しろよ。
0800デフォルトの名無しさん
2014/01/11(土) 20:13:12.40そのやり方だと、コードの実装が途中だと、帰って寝てる間にテストできないじゃん
0801デフォルトの名無しさん
2014/01/11(土) 20:16:12.14そんなに時間が掛かるテストを書くな。
テストに一晩かかるようなやり方じゃ、
何度もテストを回せないだろ。
0802デフォルトの名無しさん
2014/01/11(土) 20:21:31.57> 火曜: 前日までの修正をしてcos関数を実装する。
前日までの修正をして・・・そのテストをしないといけない。それが一晩かかる。
0803デフォルトの名無しさん
2014/01/11(土) 20:21:42.12テストコードを個々の関数実装よりも後に書いちゃいけない理由は、後にテストを書くと、書いたコードに合わせてテストの方が変更されるから
テストコードとは、書いたコードの動作が正しいことをどのように確認するかの「事前の」同意事項をコード化したもの
だから、本来なら、要求定義の次に用意されてしかるべきもの
0804デフォルトの名無しさん
2014/01/11(土) 20:23:03.09なんでだよｗ
0805デフォルトの名無しさん
2014/01/11(土) 20:25:01.60cos関数なら、本来なら、10^28個の数値できちんと動くことを確認したい
テスト時間はいくらあってもよい
0806デフォルトの名無しさん
2014/01/11(土) 20:26:06.04797さんは、xUnit とか CI とか知らないんぢゃないの?
xUnit は、一度書いてしまえば、IDE( Eclipse / VS / NetBeans) 上で
何度も自動実行できます。最近では、ちょっとコードを書いてはテスト
を実行する開発手法が主流。
そういう流れで、テスト駆動。
CI (継続的インテグ) は、xUnit を全実行して、レポートを作ってくれます。
Jenkins などが有名で、テストの合否の他に、カバレッジや、規約違反、
複雑性の静的評価レポートなども出してくれます。
よくやるのは、15分おきに、git を見に行って、変更があれば pull して全テスト。
深夜に全テスト＋静的評価レポート。
0807デフォルトの名無しさん
2014/01/11(土) 20:31:11.66例えば、本来なら、「テストコードの使われ方見るとfloat型だから、float型で実装しよう」 だけど、
実装が先だと、「今日は float型で実装したから、テストコードも float型で書こう」 になる
0808デフォルトの名無しさん
2014/01/11(土) 20:31:18.391秒間に10^12個（1兆個）のテストをやって、
115740740740日かけてテストすればいいんじゃね？
0809デフォルトの名無しさん
2014/01/11(土) 20:33:39.28だからなんでだよｗ
それが間違っているならば
正しく書けばいいだろ。
っていうかテストを最初に書いたつもりでも、実装しなきゃわからんことがあるし、
あとでテストをつけ加えたり、テストを修正したりすることなんてざらにあるんだが。
ましてや、週の最後にならんとわからんようなものを
週の最初に全部完璧にテストをかけるわけがない。
テストが間違っていたとしても、実装の方を直すっていうのか？
実践経験足りないんじゃなねーか？
理屈しかわかってない。
0810806
2014/01/11(土) 20:48:06.61テストは、テスト対象が完全であることを証明できないから無意味
ということを言いたいんだろうけど、そんなの皆分かってますよ。
分かった上で、時間も労力も限られている現実世界でどうするか
っていう話です。
経験的に、同値分割と境界値分析でテストケースをちゃんと作っとけば
単体の不具合も、他のモジュールに起因するリグレッションも検知できる。
仮に漏れたら、テストを追加すればいい。
ちなみに Google の ARM 版 Javascript エンジン (V8) は 境界値分析
がちゃんとできてなくて sin(0), cos(0), tan(0) が変な値になる。
0811デフォルトの名無しさん
2014/01/11(土) 20:49:26.49まず前提として、今から書こうとするコードの動作をどのように確認するかが分からないなら、コーディング作業に入るべきではない
分かってるなら、先に書けばいい
実装した後に、テストを修正したりするのは勝手だけど、それはテスト作成時の仕様の理解不足か思い込みか注意不足か仕様自体の穴の存在を意味する
つまり、実装した後にテストを修正するのが当然と思い込んでいるということは、あなたは、大した熟考をせずに仕事を受注してくる会社にいるということを自覚した方がよい
0812デフォルトの名無しさん
2014/01/11(土) 20:52:32.810813デフォルトの名無しさん
2014/01/11(土) 20:55:36.60納品の際にに、きちんとテストをやったという書類を山のように積み上げるから
じゃあ、いつ書くの？ 今でしょ
0814デフォルトの名無しさん
2014/01/11(土) 20:58:44.320815デフォルトの名無しさん
2014/01/11(土) 21:37:28.23本格的な運用テストは納品後1ヶ月の瑕疵期間でやる
現場に1人張り付けてもそのほうが効率いいだろ
トラブル対応の経験もできる
0816デフォルトの名無しさん
2014/01/11(土) 22:16:44.130817デフォルトの名無しさん
2014/01/11(土) 22:50:34.140818デフォルトの名無しさん
2014/01/11(土) 23:18:47.410819デフォルトの名無しさん
2014/01/11(土) 23:26:49.31テストだってわける必要ねーんだよ
どの書類に対するテストか意識せずに
教科書どおりにテストするほうがおかしい
0820デフォルトの名無しさん
2014/01/11(土) 23:59:55.74脳がフレッシュて柔軟な若者からみてSmalltalkのやり方やアラン・ケイの考え方ってどうみえる？
プロダクトはもちろん、それを記述している処理系すらも
常に走らせながら枠組みから変えていける仕組みやスタイルについて。
http://metatoys.org/oxymoron/oxymoron.html
0821デフォルトの名無しさん
2014/01/12(日) 00:56:00.00基本設計と詳細設計でわけたりしてないけど、社内で閉じた納品前の作業と、設計にも関わってこなかった人の目に触れる納品後の作業は意識して分けろよ…
0822デフォルトの名無しさん
2014/01/12(日) 00:57:51.66オープンソースなら使えると思うが、
プログラミング以前に、実務として、どの段階でどうやって契約してお金もらうのか分からない
0823デフォルトの名無しさん
2014/01/12(日) 01:14:08.85なるほど。でもケント・ベックのXPとかはこういう開発スタイルの特性から編み出されたんだよね？
けっきょく失敗したけれど、クライスラーでベックが請け負った仕事もSmalltalkでやっていたわけだし。
0824デフォルトの名無しさん
2014/01/12(日) 02:53:44.58分けて考えなきゃダメだろ。テスト駆動開発の是非はともかくてとして、テストコードを
書くことすら嫌な奴は死ねばいいよと思うよ。
0825デフォルトの名無しさん
2014/01/12(日) 03:46:38.75その習慣をやめてまずはテストコードでテストするようにして
次にテスト駆動にしなければならない
段階すっ飛ばしていきなりテスト駆動にしようとするから
・テストコードなんて書いたことないのに・・・
・しかも、プログラミング前に書くなんて・・・
と障壁が二つになってしまう
もともと、テストコードを書く習慣があれば、すんなりテスト駆動のメリットは理解できるはずだ
0826デフォルトの名無しさん
2014/01/12(日) 03:54:33.45テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの？
0827デフォルトの名無しさん
2014/01/12(日) 04:01:00.98そういえば、POI使ってexcelからデータ取り出せるの知ってから仕事が半分になったの思い出したわ
0828デフォルトの名無しさん
2014/01/12(日) 04:43:44.74テストコードでテストする前に
テストコードでテストしやすいコードを書けるように
コード記述力を高めないといけない。
あと各モジュールの独立性が高い設計も。
それれができていないところにテストコードを導入すると悲惨だぞ。
メンテンス不要のテストがたくさん出来きる。
テストコードを書く時間ばかりがかかってしまい、
これが俗にいう、ユニットテスト導入の失敗になる。
0829デフォルトの名無しさん
2014/01/12(日) 04:46:14.61> テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの？
動作確認するぞ。
ただし、単体ではない。
結合された状態でテストをする。
これをそのままテストにしても、
入力と出力の間に数多くの処理が含まれ
複数の入力と複数の出力と複数の副作用
組み合わせ爆発をおこし、再利用可能なコードにならない。
0830デフォルトの名無しさん
2014/01/12(日) 04:47:20.87○ メンテンス不能のテストがたくさん出来きる。
0831デフォルトの名無しさん
2014/01/12(日) 09:12:51.35テスト書くのサボらせないために、コード書く前に必ず書かせることを義務づける
っていうことじゃないの？
0832デフォルトの名無しさん
2014/01/12(日) 09:21:24.44そもそもトップダウン構築とボトムアップ構築の意識の齟齬から直すべきだったりして
0833デフォルトの名無しさん
2014/01/12(日) 10:17:21.44自分で書く。
その手法を総称して、TDDと言います。
開発時間が短縮される効果があり、コストを低減できます。
0834デフォルトの名無しさん
2014/01/12(日) 10:22:56.370835デフォルトの名無しさん
2014/01/12(日) 11:12:22.70流行ってるだろ。
0836デフォルトの名無しさん
2014/01/12(日) 13:48:12.51根付いて静かに広がらないと
0837デフォルトの名無しさん
2014/01/12(日) 14:32:21.01いや、エディタに打ち込んでて、関数のカッコを閉じて、一息つく前に動作確認しないの？
0838デフォルトの名無しさん
2014/01/12(日) 14:57:14.98？ するだろ。
結合された状態で。
0839デフォルトの名無しさん
2014/01/12(日) 15:02:22.99いや、結合すらもされてない状態で
例えば、java とか python だと、必要ないのに各ファイルにmainメソッド書いて、そこに関数の典型的な仕様例書いて、mainメソッド呼び出してカッコ閉じたばっかりの関数の動作確認しないの？
0840デフォルトの名無しさん
2014/01/12(日) 15:14:11.75単体テストせずにいきなり結合テストすると、それこそバグの場所特定のときに組み合わせ爆発すると思うのだが…
0841デフォルトの名無しさん
2014/01/12(日) 15:48:15.82今の話をちゃんと書いておくね。
テスト書いたことがない人でもテストをするという話。
そのテストの内容というのは（結合テストではなくて）結合された状態でテストする。
組み合わせ爆発してどっちが大変とかそんなことは今の話はしてなくて
テストを書いたことがない人は、こういうやり方でテストするという話。
>>839
> 例えば、java とか python だと、必要ないのに各ファイルにmainメソッド書いて、そこに関数の典型的な仕様例書いて、mainメソッド呼び出してカッコ閉じたばっかりの関数の動作確認しないの？
だからするって言ってるだろ。それが結合された状態でのテストって話だよ。
0842デフォルトの名無しさん
2014/01/12(日) 15:53:06.04それは結合された状態のテストじゃないでしょ…
0843デフォルトの名無しさん
2014/01/12(日) 15:55:21.20それテストじゃなくて、動作確認じゃね？
結合された状態で、動作確認すると
0844デフォルトの名無しさん
2014/01/12(日) 15:58:40.24例えば、sin(cos(x)) の実装するときに、sin(x) と cos(x) の動作確認はせずに、 sin(cos(x)) の動作確認しかしないってことだよね？
そんなのあるの？
0845デフォルトの名無しさん
2014/01/12(日) 15:59:53.57いや？ 結合されたテストだよ。
関数Aを作る、mainを作る。まあ最初の関数Aは単体テストかもしれん。
次に関数Aを利用した関数Bを作る。mainはそのままでテストする
次に関数Bを利用した関数Cを作る。mainはそのままでテストする
以下略
他にも関数Aに処理を追加する。mainはそのままで実行する。
関数Aに追加された処理が正しく動くことを確認。OK
という流れもあるね。
なんか混乱してて話がずれていきそうだから、最初のレス(>>826)を引用すると
> テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの？
テストを書いたことがない人は、自分が書き終わった直後にこうやって動作確認してるんだよ。
（やり方がまずいかどうかは論点ではなく）動作確認自体はこうやってやってるんだよ。という説明を俺はしただけ
0846デフォルトの名無しさん
2014/01/12(日) 16:07:18.41> というか、コード書いた後にやってるコードの動作確認を、コードを書く前に再利用できる形でファイルに記述するだけなんだけど
>>845みたいなテストをしているわけで、
「コード書いた後にやってるコードの動作確認」＝ >>845 を
再利用できる形で記述するだけだと、それは単体テストではなく
結合された状態でのテストコードになるっていうのはわかるよね？
だから、そんな「ファイルに記述するだけ」という単純な話にはならない。
テストコードを書いたことがない人でも、ちゃんと動作確認はしているわけだが、
それを単純に書いただけでは、だめなんだよ。
ちゃんとテストコードを書くのにふさわしいコードの書き方や設計から学ばないと。
ユニットテストっていうのは、既存のやり方にプラスαで追加できるものではありません。
既存のやり方がユニットテストに適していなければ、根本的に変える必要があるもの。
だから導入が大変なんだよ。
0847デフォルトの名無しさん
2014/01/12(日) 16:08:44.13Aを作る → Aだけを確認する
Bを作る → AとBをくっつけた状態で確認する
じゃなくて、普通は
Aを作る → Aだけを確認する
Bを作る → Bだけを確認する → AとBをくっつけた状態で確認する
にする理由は、A〜Bの連結でドメインの不整合が、Bの中だけのバグと同じオーダーで発生するから、バグの場所を特定するために、結局Bだけのテストも書くことになるから
0848デフォルトの名無しさん
2014/01/12(日) 16:10:18.41あぁ、そんなことは知ってる。>>846を読む前にレス書いたんだろうと思うので特にレスはしない。
0849デフォルトの名無しさん
2014/01/12(日) 16:13:58.77典型的な 「最後の一個を追加したときに全部動かなくなることが判明して、デバックで徹夜させられるプロジェクト」 の例
システムには相互作用があるから分析不可能な形で積み上げていくなとあれほど…
0850デフォルトの名無しさん
2014/01/12(日) 16:16:25.10典型的な 「最後の一個を追加したときに全部動かなくなることが判明して、デバックで徹夜させられるプロジェクト」 の例
を俺はしただけなんだが？
テストコードを付け加えるだけで終わるみたいに考えてるあまちゃんに
大変さを説明しただけ。
0851デフォルトの名無しさん
2014/01/12(日) 16:16:50.78そのためのフレームワークがJavaで流行ったけど(DI。GuiceとかSeasar2とか)、テストのしやすいコードという観点で使用されることがあまりない。
TDDを強制すればちったあ意識してくれるのかな。
0852850
2014/01/12(日) 16:17:40.09いやだから、
典型的な 「最後の一個を追加したときに全部動かなくなることが判明して、デバックで徹夜させられるプロジェクト」 の例
を俺は "説明" しただけなんだが？
0853デフォルトの名無しさん
2014/01/12(日) 16:19:57.05ユーティリティ関数書いたファイルのmainの中に、ユーティリティを利用する側のシステムのコードを記述しちゃダメでしょ
0854デフォルトの名無しさん
2014/01/12(日) 16:25:29.49いや、そもそも、コードの関数のカッコを閉じて一息つく前の動作確認で、結合された状態のテストをする方が稀
余計に作業が多くなってコケることが「普通は」分かってるから
コードを書き終わった後にさっき書いた部分だけのテストコードを書くのは「普通はみんな」やってるんだから、それを最初に書けってだけの話なんだが
0855デフォルトの名無しさん
2014/01/12(日) 16:25:52.78> TDDを強制すればちったあ意識してくれるのかな。
強制するだけじゃだめ。反発する。
そしてうまくいかなければ、それが拒絶になる。
TDDを強制するならば、テストしやすいコードの書き方を知っている人がいて、
そのレビューの元で（既存のコードを直すのではなく）開発しないといけない。
なぜ、「既存のコードを直すのではなく」と書いたのかというと、それは0から
テストコードを書きやすいコードを書くのに比べると「既存のコードを直す」
という大変な手間がTDDをやるために必要なことだと認識されてしまうから。
本来はTDDにしないことで発生していた問題点なのだが、TDDが大変という印象にしかならない。
でも実際はテストコードを導入しましょう！っていう所は
すでにテストコードが導入されていないコードがたくさん存在しており
開発の大部分は新規開発ではなく修正になるわけで、理想的な状態は作れないことになる。
一言で言えば、テストコードを導入するのは、大変ってことだよ。
0856デフォルトの名無しさん
2014/01/12(日) 16:29:24.11普段書いてる程度のテストコードを付け加えるだけで終わらせなければダメ
開発プロセスを提案するときに、普段やってること以外に余計なプロセスを追加するのはダメ
許されるのは順序を変えるとか、意識して保存することくらい
それ以外の作業を追加すると余計に大変になる
0857デフォルトの名無しさん
2014/01/12(日) 16:34:53.99> コードを書き終わった後にさっき書いた部分だけのテストコードを書くのは「普通はみんな」やってるんだから、それを最初に書けってだけの話なんだが
「普通はみんな」っていう言葉は、
「そういうことに俺はしたいんだ」って言ってるようにしか見えないなｗ
俺がいいたいのはテストはしているが
テストコードが導入されていないところでは
>>845に書いているやり方でテストしているということ。
テストしやすいコードを意識せずに、コードを継ぎ足ししていって出来たコードは悲惨だよ？
テストするのに最初から実行することしか出来ない。
一関数で数千行あって、入力のパラメータは数十個、出力も数十個あるような
コードにテストコードを書くのが、どんなに大変なことかをお前は知らない。
テストコードを導入するというのは、こういう複雑なコードを理解して分解して修正していく作業
そしてそれを書いた人に、なんでこう書いた？ こうするべきだ。今までのやり方は間違っている。
ここからどうやって正しい道に直すか。ということを理解させる作業なんだ。
0858デフォルトの名無しさん
2014/01/12(日) 16:36:19.01考え方の順序が逆
テストしにくいコードになる理由は、コードを書く前に、コードが満たすべきテストのインターフェイスがないから
ただそれだけ
だから、テストの技術がないバカプログラマでも、テストを先に書けば、テストしやすいコードしかできない
分散処理やGUIとか、技術的理由で事前にテストコードが書けないときは、別だが
0859デフォルトの名無しさん
2014/01/12(日) 16:40:53.38明示的にテストコードを書く手法が導入されていないところも、場合によっては大学の演習のバカ学生ですら、納期が2週間前のプロジェクトでない限り、
Aを作る → Aを書いた直後にAだけを確認する
Bを作る → Bを書いた直後にBだけを確認する → AとBをくっつけた状態で確認する
が普通ですよ
0860デフォルトの名無しさん
2014/01/12(日) 16:44:15.74> テストの技術がないバカプログラマでも、テストを先に書けば、
それは普通にまともなテストが書けませんでした。で終わり。
テストの技術がないが、既存のプログラムを修正するぐらいの人はたくさんいる。
そういう人が実戦投入されるとどうなるかわかるかな？
そういう人はたいてい既存のプログラムの簡単な修正をやらされることになる。
テストコード導入されていない既存のプログラムの修正からね。
それはゼロからの開発に比べて、テストコードが書きにくい既存のコードを
修正しながら、正しい設計に直すという大変な作業になる。
それをテストの技術がない人、つまり正しい設計も理解してない人がやるのは不可能。
テストコードはまともに書かれることはなく、無駄な作業と認識され
デスマになるだけ。
あんたは理想的な状態で語ってるだけ。人や状態が最善の状況でやるやり方。
それは現実にはありえないので、そのやり方では失敗する。
0861デフォルトの名無しさん
2014/01/12(日) 16:47:15.09仮に、一関数で数千行あって、入力のパラメータは数十個、出力も数十個あるようなコードがあるとしても、関数のカッコ閉じた直後に動作確認するんだから、テストコードが書けないなんてことはあり得ない
逆に、テストコードが書けないなら、その人の環境では動作確認できない機能ってことになるから、コードの複雑さとは関係ない
0862デフォルトの名無しさん
2014/01/12(日) 16:48:05.53> 場合によっては大学の演習のバカ学生ですら、納期が2週間前のプロジェクトでない限り、
語るに落ちたって感じｗ
大学の演習だから出来るんだよ。
大学の演習っていうのは、問題を適切に解ける時間が十分に与えられている。
0からの開発。問題を適切にとくことが目標であり
（どんな手段を使ってでも）機能を作ることが目標ではない。
そんな理想的な状況なら簡単にできるの当たり前だろ。
ソフトウェアの開発っていうのは、新規開発よりも、既存のシステムの修正や流用が
ほとんどだってわかってる？ 書くことよりも読むことのほうが多いんだよ。
0863デフォルトの名無しさん
2014/01/12(日) 16:50:47.62動作確認用のテストがまともに書けないからデスマになって困りますって、それは開発プロセスの話じゃなくて、ただの人事採用の話なんじゃね？
0864デフォルトの名無しさん
2014/01/12(日) 16:51:22.04> テストコードが書けないなんてことはあり得ない
そりゃ書けないことはないだろうねぇ。理論的には。
何がいいたいかわかる？
どうあがいても適切なコードを書く時間が与えられていない状態で
書くにはどうするのかって話。
数千行のコードを読んで正しく理解する時間すら与えられていない。
修正に修正を重ねているから正しい仕様も存在しない。
どうすんだよ？
お前の言うように、テストコードの導入は簡単な作業ではない。
0865デフォルトの名無しさん
2014/01/12(日) 16:53:37.70読む場合も、普通は
Aを読む → Aの動作を理解するためのテストコードを書く → Aを改造する → 改造した直後にAの改造が正しいか動作確認する
だけど
0866デフォルトの名無しさん
2014/01/12(日) 16:53:41.40> ただの人事採用の話なんじゃね？
そうかもね。
んで、どうする？
人事が悪い。優秀な人採用しろ？
なんでうちに優秀な人こない？と叫ぶ？
テストコードを導入するために
高い給料出して人材を揃えるように、上に訴えるかい？
それができるのなら、それが一番だよ。
いますぐやろう！
0867デフォルトの名無しさん
2014/01/12(日) 16:55:34.78どうあがいても適切なコードを書けないと分かってるなら、不良品を世に出さないために職場でウンコをまき散らして、プロジェクトを破壊してください
中国の毒食品じゃないんだからさ
0868デフォルトの名無しさん
2014/01/12(日) 16:57:46.19実際には
Aを読む → （複雑で読み切るだけの十分な時間がない）
Aの動作を理解するためのテストコードを書く → （テストコードを書く十分な時間がない。）
Aを改造する → 改造した直後にAの改造が正しいか動作確認する → （既存のコードが壊れていないかどうかはわからない）
これがテストコードがない場合の現実だよ。
Aのコードが短かくてAだけの修正で終わる保証なんて無いからね。
だいたいAを修正するときは、Aのインターフェースは変わらなくても
Aの仕様が変わるわけで、それの影響がどれくらい出るかを考えなきゃならん。
0869デフォルトの名無しさん
2014/01/12(日) 16:59:11.71それ絶対に実行不可能な無理な話じゃね？ｗ
0870デフォルトの名無しさん
2014/01/12(日) 17:00:16.99テストコードは「すでに」導入されてる
先に書くか後に書くかの違いだけ
で、先に書けってだけ
テストコードが導入されてないなら、動作確認しないってことだから、問題は「動作確認しないままプログラムを売る方法を知りたい」ということになので、このスレとは関係ない
0871デフォルトの名無しさん
2014/01/12(日) 17:04:02.18Aを読む → （複雑で読み切るだけの十分な時間がない）
Aの動作を理解するためのテストコードを書く → （テストコードを書く十分な時間がない。）
（そしてコードが結合しまくりで、分解しなければまともなテストコードが書けない。結合された状態でのテストコードしか書けない）
Aを改造する → 改造した直後にAの改造が正しいか動作確認する → （既存のコードが壊れていないかどうかはわからない）
>>845で書いたように、Aというコードは、結合しまくりなのに
それにテストコード書いて終わりだと思う？
結合された状態のAのテストコードを書くという話になってるよね。
本来はAを分解して単体に分けてから、それにテストコードを書かないといけないのに、
結合された状態でテストコード書けばいいという話になってるよね。
Aが結合されてないという理想的な状態しか考えてないのかな？それは片手落ち。
0872デフォルトの名無しさん
2014/01/12(日) 17:05:36.54話の発端はこれなんだから、「テストコードは導入されてない状態」がスタート
勝手に話を擦りかるなよ。
826 ：デフォルトの名無しさん：2014/01/12(日) 03:54:33.45
というか、コード書いた後にやってるコードの動作確認を、コードを書く前に再利用できる形でファイルに記述するだけなんだけど
テスト書いたことない人って、もしかして、自分が書き終わった直後の動作確認すらもしてないの？
0873デフォルトの名無しさん
2014/01/12(日) 17:05:39.49逆に聞きたいが、テストなしでそれどうやって実行するの？
既存のプロセスでも論理的に消火不能な仕事がやってきたときには、どの開発手法でも無理ですよ
TDDは可能な限りバグを減らす努力の一つにすぎないんだから
0874デフォルトの名無しさん
2014/01/12(日) 17:08:14.95話をわかってないね。
テストコードが導入されていない所に、
>>826みたいに「テストコードは動作確認をファイルに書くだけ」なんて
現実を知らずに、あまちゃんなことを言ってる人に、
テストコードを導入するのは大変って話をしているだけ。
テストコードがあれば無いよりもいいってのはわかってるよ。
当たり前すぎ。だけどそんな話はしていない。
テストコードの導入が大変って話をしてる。
0875デフォルトの名無しさん
2014/01/12(日) 17:10:41.48前提1： 「普通の」プログラマは、コード書いた後にやってるコードの動作確認をやってる
前提2： 「普通の」プログラマは、それを各モジュールファイルの main メソッドとかに書いてる
提案： それを、コードを書く前に再利用できる形でファイルに記述すれば？
疑問： テスト書いたことない人って、前提1, 前提2の、書き終わった直後の動作確認すらもしてないの？
0876デフォルトの名無しさん
2014/01/12(日) 17:11:26.45普通のプログラマじゃなくて
それは俺がこれが普通と思ってるんだーって
言ってるだけだろｗ
0877デフォルトの名無しさん
2014/01/12(日) 17:12:40.92テストコードをファイルに書かずにどうやって動作確認するの？
念力？
0878デフォルトの名無しさん
2014/01/12(日) 17:13:17.45答え
前提1： 「普通の」プログラマは、コード書いた後にやってるコードの動作確認をやってる（ただし結合された状態で）
前提2： 「普通の」プログラマは、それを各モジュールファイルの main メソッドとかに書いてる （ただし実行は結合された状態で結果を目視）
提案： それを、コードを書く前に再利用できる形でファイルに記述すれば？ （結合された状態でのテストコードにならない）
0879878
2014/01/12(日) 17:14:27.90>>877
テストコードじゃないんだから目視しか無いだろ？
目視じゃ再利用できないから、テストコードってものができたんだし。
なにを当たり前な？
0880878
2014/01/12(日) 17:18:39.00とりあえずコードが実行できればいい。
実行した後、結果は目視。
もちろん、各モジュールは結合された状態で動作確認して終わり。
というようなことがやられているのが現実。
言っとくが、俺はこの方法がいいとは一切言っていない。
このやり方をしているというのに、それを単純にコードに置き換えても
使えないテストコードになるって言ってるだけ。
テストコードがないプロジェクトに、テストコードを導入するのはそんなに簡単な話じゃないんだよ？
既存コードの修正や、メンバーの意識を変える必要がある。
テストしにくい設計の既存のコードはそのままで、追加すれば出来るようなもんじゃない。
0881デフォルトの名無しさん
2014/01/12(日) 17:20:12.28「普通」が、
a. 書き終わった直後に今書いたコードだけの動作を確認して、さらに結合した状態の動作も確認するのか、
b. 結合された状態の動作いか確認しないのか
アンケートをとる必要があるようだな…
0882878
2014/01/12(日) 17:21:01.47× 提案： それを、コードを書く前に再利用できる形でファイルに記述すれば？ （結合された状態でのテストコードにならない）
○ 提案： それを、コードを書く前に再利用できる形でファイルに記述すれば？ （結合された状態でのテストコードにしかならない）
0883デフォルトの名無しさん
2014/01/12(日) 17:22:28.49テストコードを導入していないところの「普通」でお願いねｗ
テストコードを導入するのが大変って話をしてるんだから。
0884デフォルトの名無しさん
2014/01/12(日) 17:28:26.41まず、GUIや分散処理やDBみたいなモノはここでは横に置きましょう
仮に、cos関数の実装の話として、今書いたcos関数の動作を目視で確認する人がいるとしましょう
termに表示された数値と関数表をプリントアウトしたものを照らし合わせて確認する場合、できるのはせいぜい20〜30個ですよ
cos関数を実装してくれと言われた場合、「普通の」プログラマはそれで給料もらえると思います？
0885デフォルトの名無しさん
2014/01/12(日) 17:45:37.360886デフォルトの名無しさん
2014/01/12(日) 17:52:48.59なんでcosみたいな簡単な例を出してるんですか？
関数ライブラリを作って商売をしてるわけじゃあるまいし。
お前が横に置きましょうといった、
GUIを使ったアプリや、ウェブアプリを作るのが普通。
そんな関数作って終わりなんて仕事はない。
たとえば、ボタンを押したら、入力した数個の情報に
10個ぐらいの設定を読み込んでいろんな処理をして
10個ぐらいのデータを作る。
こういったアプリを作るのが普通。
そういう既存の処理に一つ処理を追加する。これが通常の開発。
機能を作るのが仕事として割り当てられる単位で
そんな関数単位で実装してれなんていう仕事はまずない。
0887デフォルトの名無しさん
2014/01/12(日) 17:54:54.91テストの技術がない人 ≠ 正しい設計も理解してない人
0888デフォルトの名無しさん
2014/01/12(日) 17:57:39.31GUIやWEBのテストの話がしたいなら、プロセスとしてのテストではなく、テスト技術そのものが確立してない分野なので、そもそも別のスレに行くべきではなかろうか…
0889デフォルトの名無しさん
2014/01/12(日) 17:57:48.31テストの技術がない人 ≒ 正しい設計も理解してない人
まあ、≒は＝ではないから
≠ってのは当てはまるけどねｗ
0890デフォルトの名無しさん
2014/01/12(日) 17:58:33.55じゃあ言ってやって。
テスト駆動はGUIやWebには使えないって。
0891デフォルトの名無しさん
2014/01/12(日) 17:58:58.27努力の方向が間違ってるだよ。
会社ごと滅べばいいんだよ。
農薬入り食品を輸出する他国の工場の話を聞いたらそう思うだろ？
煽りでもなんでもなく、普通の感覚。
0892デフォルトの名無しさん
2014/01/12(日) 18:00:25.46おまえの会社はすぐ廃業しろ！
0893デフォルトの名無しさん
2014/01/12(日) 18:01:00.20普通は、cos関数よりもさらに単純な関数単位の実装をしろという仕事ばっかりですよ
ただし、その要件が何万もあるわけです
0894デフォルトの名無しさん
2014/01/12(日) 18:03:58.80テスト駆動は、アプリケーションのうち、GUIやWebのリクエストディスパッチの部分には使えない
同時に、どの手法ならバグを減らせるかもよく分かっていない
ゆえに職人が消えたら会社が消滅するような分野
0895デフォルトの名無しさん
2014/01/12(日) 22:29:02.59UWSCやSeleniumを使ったらいいんじゃないのか？
0896デフォルトの名無しさん
2014/01/12(日) 22:34:11.49TDDでテストする範囲って単体テスト未満だし・・・
0897デフォルトの名無しさん
2014/01/12(日) 22:43:11.70テスト自体はできる
自動でテストができない
自動でテストできても、標準APIについてないような特別なツールを導入するのは避けたい
0898デフォルトの名無しさん
2014/01/12(日) 23:32:28.17> 普通は、cos関数よりもさらに単純な関数単位の実装をしろという仕事ばっかりですよ
ねぇよｗ
有名な関数以外の、つまりお前が実際に頼まれたその単純な関数の実装の例言ってみ。
0899デフォルトの名無しさん
2014/01/12(日) 23:32:53.11誰もテストできないなんて言ってないと思う
各言語やフレームワークで定番のテスト方法ってあるやろ
でも、Webではまだその辺みんな探り探りだから、導入しづらいっていうことでしょ
去年ですら↓だよ
http://www.atmarkit.co.jp/ait/articles/1305/08/news015.html
>テストツールはいくつかあるが、「どれを選んでも間違いないレベル」であると佐藤氏は話し、会場のコーダーを安心させた。
もともとテストコード書く習慣がなかったところに、一気に選択肢が沸いてきた
0900デフォルトの名無しさん
2014/01/12(日) 23:35:52.23テストしやすいコードっていうのを理解していれば、
有名どころのツールは何を使ってもいいというのは正しい。
ただ、そのツールを使っても、テストしやすいコードってのを知らなければ
間違った使い方をすることになる。
やろうと思えば出来るんだよね。単体テストを記述するツールで
結合テストを書くことなんて。どんなツールでも間違った使い方はできる。
だから正しいやり方を理解することが必要。
単にテストコードを書けば、必ずしも自体が良くなるってわけじゃない。
0901デフォルトの名無しさん
2014/01/12(日) 23:40:40.850902デフォルトの名無しさん
2014/01/12(日) 23:43:17.53普段自分が作らないような物の話をしてもしょうがないだろｗ
0903デフォルトの名無しさん
2014/01/12(日) 23:50:47.92893じゃないが、
(構造体をつくる関数がすでにあって)
・コンストラクタを作る (8種類のうち4種類)
・空の構造体のデータ領域がヌルで埋まってることをチェックする関数
・すでに作った構造体とメモリがかぶってないか確認する関数
・データのインデックスを、データ領域の配列のインデックスに変換する関数
・構造体の一部を文字列に変換する関数
・文字列の終端がヌルであることを確認する関数
：
：
掛け算どころか、引き算もあんまり出てこないよ
0904デフォルトの名無しさん
2014/01/12(日) 23:53:22.00下請け？
普通会社の仕事としては、その関数を使った
アプリ、システムを作るものだが、
お前の会社は、その関数を作って仕事が終わりなんだよね？
へんなのｗ
0905デフォルトの名無しさん
2014/01/12(日) 23:55:09.04この世に、GUIやWebアプリを作っているときにバグを減らす方法が存在するなら、GUIやWebアプリでTDD使える/使えないを話していいと思うけど
0906デフォルトの名無しさん
2014/01/12(日) 23:58:39.89テストコード書いてる？
0907デフォルトの名無しさん
2014/01/13(月) 00:00:19.87重要なのは、「導入にあたって余計な手順を追加しない」ですよ
今までと異なる正しいテストコードを書けと言うのなら、それは教育プロセスを追加することになるから、それは別で考えるべき
必要に応じて教育プロセスを追加していいという前提なら、それこそ「マイクロソフトで3年研修した後で開発プロセス」でもいいわけだし
目的は、限られた時間でよりバグを少なくすることだから、テストコードを先に書くことで今よりもバグが少なくなるかどうかを考察すべきて、テストの品質は二の次
0908デフォルトの名無しさん
2014/01/13(月) 00:00:32.78GUIやWebアプリではテストコード書けないって話でしょ？
0909デフォルトの名無しさん
2014/01/13(月) 00:01:10.10公官庁のインフラ系はこんなのばっかだよ
0910デフォルトの名無しさん
2014/01/13(月) 00:02:16.55> 重要なのは、「導入にあたって余計な手順を追加しない」ですよ
それは何をするのに重要なこと？
教育プロセス自体、余計な手順なわけだよね？
たとえば、技術力が明らかに低い人。
こういう人に、余計な手順を追加しないで
なのができるというの？
0911デフォルトの名無しさん
2014/01/13(月) 00:02:24.59アプリ―ションの一部(GUI部分やWebアプリのディスパッチ部分など)は自動でテストするコードを書けない
0912デフォルトの名無しさん
2014/01/13(月) 00:04:23.71インフラ系の時点でアプリ開発じゃないじゃんｗ
インフラ系は、アプリが数十行程度の短いコードで終わり
それを毎回0から開発だから、テストすら要らないようなレベル。
テスト駆動が必要なのはアプリの開発。ファイル数百以上、
コード行数、数万行。そういったアプリの話をしてるの。
0913デフォルトの名無しさん
2014/01/13(月) 00:05:50.18アプリケーションの一部は自動でテストコードを書けないんだよね？
だけど、ファットコントローラみたいにコントローラに
ロジックの大部分が書かれているものはどするんだ？
ロジックの大部分がテストできないって話でいいよね？
0914デフォルトの名無しさん
2014/01/13(月) 00:06:51.08プロジェクトにおいて、プロジェクトメンバー全員で開発プロセスを一貫して利用するにあたった重要なこと
ちなみに、「教育用プロジェクト」でない限り、プロジェクトは教育の場所ではないので、技術力が明らかに低い人は存在しない
0915デフォルトの名無しさん
2014/01/13(月) 00:08:07.78あの…、納品する仕様書だけで98cmありますけど
0916デフォルトの名無しさん
2014/01/13(月) 00:09:57.77> プロジェクトは教育の場所ではないので、技術力が明らかに低い人は存在しない
それはありえない。
たとえば10年選手って言葉が存在するだろう？
それは仕事を10年やってきた（だから力がある）という意味であって、
教育を10年やってきたわけじゃないんだよ。
そして10年選手が力があるという意味になるのは、
10年間で成長しているということなんだよ。
そうすると、教育期間が同じであっても、1年選手と10年選手では
明らかに技術力に差があるわけで、技術力が（高い人に比べて）低い人
っていうのは絶対に存在する。
だいたい、仕事やっていて、成長しないわけがないだろ？
0917デフォルトの名無しさん
2014/01/13(月) 00:11:02.58シナリオを自動でトレースするツールを使わない限り、手で確認するしかないだろうね
0918デフォルトの名無しさん
2014/01/13(月) 00:12:50.02技術力が（高い人に比べて）低い人 っていうのは絶対に存在するが、教育用プロジェクトでない限り、プロジェクトの必要レベルに達していない人は存在しない
0919デフォルトの名無しさん
2014/01/13(月) 00:15:28.17> プロジェクトの必要レベルに達していない人は存在しない
じゃあ、話はこういうことだ。
プロジェクトの必要レベルに達するまで
教育は何年必要か？
きれいなコードを書けるようになるまで、
何年もかかるっていうのは知ってるよね？
もし数ヶ月で教育が終わるようであれば、
それはプロジェクトのの技術レベルが全体に低いっていうこと。
0920デフォルトの名無しさん
2014/01/13(月) 00:15:34.77その数十行の変更が何十万人何百万人に影響あるのがインフラ系だろ
テスト必須だった
0921デフォルトの名無しさん
2014/01/13(月) 00:16:34.36利用者の人数は関係ないだろｗ
0922デフォルトの名無しさん
2014/01/13(月) 00:19:00.31だいたい技術力が低い。
教育機関も極端に少ない（1ヶ月とか）
そういうのは、とりあえず動くコードが書けるだけで
正しい設計までは身についていない。
0923デフォルトの名無しさん
2014/01/13(月) 00:20:41.43その低いプロジェクトの技術レベルで教育ゼロで導入できるバグを減らすための努力が、TDDでしょ
0924デフォルトの名無しさん
2014/01/13(月) 00:23:17.20あるだろ
0925デフォルトの名無しさん
2014/01/13(月) 00:28:41.61だから自分で書く。
それがTDD。
もう、通らないテスト、勘違いしてるテストに悩む必要はありません。
自分で書けばいいのです。
これからはTDD。
0926デフォルトの名無しさん
2014/01/13(月) 00:31:13.23逆だよ
確実にテストに通るコードは本人にしか書けない。
だから自分で書く。
それがTDD。
もう、通らないコード、勘違いしてるコードに悩む必要はありません。
自分でテスト書いて、その後にコード書けばいいのです。
これからはTDD。
0927デフォルトの名無しさん
2014/01/13(月) 00:38:18.11ねぇよｗ
全く同じコード書いていても
その利用者数は全く異なる。
0928デフォルトの名無しさん
2014/01/13(月) 00:52:58.60確実に通るテストを書けばよかったのです。
自分で書けばよかったのです。
0929デフォルトの名無しさん
2014/01/13(月) 01:04:53.95これは正確には、テスト量が同じ場合。
実際はこうなるから話がややこしい
TDDを使わないが一部のテストを省略した開発時間 ＜ TDDを使った開発時間 ＜ TDDを使わない開発時間
つまり、TDDを使わないがその分テストを省略しているので開発時間は短い。
だけどTDDを使うと開発時間が増えてしまう。
0930デフォルトの名無しさん
2014/01/13(月) 01:14:06.43他人が書いたテストはなかなか通りません。
なぜなら、仕様の理解が人によって微妙に違うからです。
自分でテストを書けば違いはありません。
通らなければ通るようにテストを書けばいいのです。
これは便利。
これからはTDD。
0931デフォルトの名無しさん
2014/01/13(月) 01:21:55.58いくつの言語を使えるようになって
どれだけの本を読まないといけないかを考えれば、
数ヶ月程度じゃ全然足らないというのは明らか。
0932デフォルトの名無しさん
2014/01/13(月) 01:24:13.27凡人には難しいんだろな。
0933デフォルトの名無しさん
2014/01/13(月) 01:35:08.43「他人は」って言えるようなデータじゃないとダメ。
ぐぐると1万時間は勉強しないと使いものにならないと言われてるね
1万時間といったら、1日8時間で計算して1250日。毎日勉強しても3.5年はかかる。
土日祝日を除いたら5年。それが目安
0934デフォルトの名無しさん
2014/01/13(月) 01:37:51.74実際は1年も勉強に割り当てられないので、数ヶ月で実戦投入されちゃう。
そしてそういうレベルのコードが大量に生産される。
0935デフォルトの名無しさん
2014/01/13(月) 01:42:27.99TDDを使った開発時間 ＝ TDDを使わない開発時間
で
TDDを使ったときのバグの数 ＜ TDDを使わなかったときのバグの数
だよ
0936デフォルトの名無しさん
2014/01/13(月) 01:44:46.23ないないｗ
コードが違うのだから、絶対に＝にはならない。
0937デフォルトの名無しさん
2014/01/13(月) 01:45:06.68勘違いしてると思うけど、普通の開発プロセスでコーディングの後にある「テスト」と、TDDのテストは別だからね
TDDのテストを、そのテストに流用するのはありだと思うが
0938デフォルトの名無しさん
2014/01/13(月) 01:49:28.02テストコードが同じでコードが違う場合は、バグが見付かったか、不必要なコードがあったってことですよね？
0939デフォルトの名無しさん
2014/01/13(月) 01:50:01.53プログラマって1万時間も学習してやっと一人前か。
馬鹿ばっかなんだな。
0940デフォルトの名無しさん
2014/01/13(月) 01:51:37.36初心者すぎてまともにコードが書けないのは、開発プロセスと関係なく人事の問題だから、別のスレで議論するべきではなかろうか…
0941デフォルトの名無しさん
2014/01/13(月) 01:52:11.92テストコード書いても書かなくても関数Aは同じなので、
関数Aのみを書く時間はTDDを使っても使わなくても同じ。
TDDを使った場合は、テストコードの時間が追加される。
TDDを使わない場合は、手動テストの時間が追加される。
TDDで関数Aを書く時間 ＝ 非TDDで関数Aを書く時間
TDD（関数A＋テストコードA'）＜ 非TDD（関数A＋A'と同等の手動テスト）
一般に言われてるのはこういう理由で、TDDを使ったほうが開発は速いと言われるが、
言うまでもなく明らかなように
非TDD（関数A＋手動テスト無し） ＜ TDD（関数A＋テストコードA'） ＜ 非TDD（関数A＋A'と同等の手動テスト）
なのである。
もちろんテストを全くしないわけにはいかないので、少しぐらいするが
その量によってTDDと非TDDでどちらが開発時間が短いかは変わってくるのは当然の話。
0942デフォルトの名無しさん
2014/01/13(月) 01:53:11.06スレタイ通り、「テスト駆動開発が流行らない」原因なんだから
まともなコードが書けない人が多いからってのは、
このスレでいいんだよ。
0943デフォルトの名無しさん
2014/01/13(月) 01:55:03.42総飛行時間だけの話にしたらだめでしょｗ
勉強時間も含めないと。
ATPLなんかしらないけど、飛行許可を得るまでの時間の話。
0944デフォルトの名無しさん
2014/01/13(月) 01:55:40.66いや、そもそも手動テストってなんなの？
ハードウェアとかGUIや分散処理やWEBのディスパッチの話してるの？
0945デフォルトの名無しさん
2014/01/13(月) 01:56:35.59後から治せるという甘えがあるんだろな。
ミスったら数百人死ぬという緊張感が無いんだと思う。
アップデートとかありえないだろ。
0946デフォルトの名無しさん
2014/01/13(月) 01:57:41.17初心者すぎてまともにコードが書けない＝そもそも開発してない だから、流行るとかそういう話ではないのだが
0947デフォルトの名無しさん
2014/01/13(月) 01:59:47.39TDDのテストは検査行程とは違いますよ
TDDのテストは、どちらかというと、プログラマ個人がエディタ保存した直後に行う習慣としてのテストのことですよ
0948デフォルトの名無しさん
2014/01/13(月) 02:00:52.87プロとその家族には当たり前だろ。
テストとか甘えたこと言ってたらダメだ。
一発でOKにしろよ。
0949デフォルトの名無しさん
2014/01/13(月) 02:02:06.04テスト関数Aがあったとき、
それを使用する処理Bがあったとする。
int main() {
いろんな処理
処理B()
いろんな処理
}
int B() {
いろんなコード
int a = 関数A()
いろんなコード
aの処理結果を更に処理した結果をデータベースに保存
}
int A() {
return 計算結果
}
プログラム実行。
データベース確認。
手動SQLを実行して計算した結果が入っていることを目視で確認
OK
これが手動テストの内容。
0950949
2014/01/13(月) 02:03:36.13A()を作る前から存在している。
だからわざわざA()のために書いたコードではない。
先にmainとBが存在していて、
そこにA()を追加した時の手動テストというのは
こういうものという説明。
0951デフォルトの名無しさん
2014/01/13(月) 02:04:42.42昔受注した飛行のシステム45万件の用件定義
そのうち、13万件は職人以外はデバッグすらできないアセンブラで書かれていました
よく飛行機に乗れますね
私は絶対に乗れません
0952デフォルトの名無しさん
2014/01/13(月) 02:06:06.52分散処理は別だとあれほど…
そもそもツールなしのテスト技術が確立してないんだからさ
0954デフォルトの名無しさん
2014/01/13(月) 02:09:15.51独立に動いてるDBMSがある点が分散処理
0955949
2014/01/13(月) 02:09:28.97ウェブプログラミングだとよくF5を押してテストも手動テストになるね。
F5押して、ちゃんと画面に意図したHTMLが表示されてているか？
↓
されていない
↓
最初に戻る
0956949
2014/01/13(月) 02:10:16.89DBMSっていうのは普通独立して動くものだが、
データベースサーバーを使ったものはすべて
分散処理だっていいたいわけだよね？
0957デフォルトの名無しさん
2014/01/13(月) 02:12:35.03FMSは壊れる前提で使われていますし、実際よく故障します。
0958デフォルトの名無しさん
2014/01/13(月) 02:14:07.29実はそういうGUIは、それだけじゃダメなんだ
ブラウザなら、ブラウザのいろんなボタンを押さないと
具体的に言うと、戻るボタンを押して変なページに転送されないことを確認しないと
0959デフォルトの名無しさん
2014/01/13(月) 02:16:28.76DBMSそのものを開発しているのでない限り、DBMSを使ったプログラムはすべて分散処理ですよ
0960デフォルトの名無しさん
2014/01/13(月) 02:18:09.760961949
2014/01/13(月) 02:20:19.56DBMSを使ったら全て分散処理（笑）
まあいいけど、この例は別にデータベースサーバーを使わなくて
ファイルを使っても同じなのだけど、
ファイルを使ったら分散処理ではないってことでいいね？
0962デフォルトの名無しさん
2014/01/13(月) 02:21:22.38超簡単に言うと、再代入のタイミングを特定できない変数がシステムの中に一つでも存在するなら、分散処理でいいよ
0963949
2014/01/13(月) 02:21:41.76手動テストの例
テスト関数Aがあったとき、
それを使用する処理Bがあったとする。
int main() {
いろんな処理
処理B()
いろんな処理
}
int B() {
いろんなコード
int a = 関数A()
いろんなコード
aの処理結果を更に処理した結果をファイルに保存
}
int A() {
return 計算結果
}
プログラム実行。
ファイル内容確認。
コマンドラインからファイルを表示して計算した結果が入っていることを目視で確認
OK
これが手動テストの内容。
0964デフォルトの名無しさん
2014/01/13(月) 02:23:18.780965949
2014/01/13(月) 02:24:38.04そうか、データベースの書き込みやファイルの書き込みっていうのが
再代入で、それらを使うと分散処理になるのかーｗ
0966デフォルトの名無しさん
2014/01/13(月) 02:25:22.60ローカルファイルに保存して、そのファイルにアクセスするプロセスがシステム稼働中常に1つ以下なら分散処理じゃない
システム用件としてネットワークファイルシステムが必須としてるなら確実に分散処理
0967デフォルトの名無しさん
2014/01/13(月) 02:28:36.93データベースの書き込みやファイルの書き込みを抽象化して表現するとそれは再代入で、「それらの再代入が行われるタイミングが特定できないなら」分散処理になる
0968949
2014/01/13(月) 02:28:49.44こいつ放置していい？なんか本当に初心者みたいだからさ。
http://e-words.jp/w/E58886E695A3E587A6E79086.html
> 複数のコンピュータやプロセッサを利用して、分散して計算処理を行うこと。
> 1台のコンピュータに多数のプロセッサを搭載して処理する方法と、
> ネットワークを通じて複数のコンピュータを結びつけて処理する方法の2種類に大別できる。
0969デフォルトの名無しさん
2014/01/13(月) 02:29:38.86int a = 1; // aは変数。
aという変数に再び代入するタイミングが特定できない、つまりユーザーの入力で
代入が起こる場合は、すべて分散処理。
日本語であればそういう意味。
マウス、キーボードの入力を受け付ければすべて分散処理。
俺はそう読み取った。
0970デフォルトの名無しさん
2014/01/13(月) 02:30:40.23キーボード入力がシステムの一部で、キーボード入力するタイミングが特定できないなら、そのシステムは分散処理ということです
0971デフォルトの名無しさん
2014/01/13(月) 02:31:20.01テスト駆動不可能という話になりました。
0972デフォルトの名無しさん
2014/01/13(月) 02:32:54.400973デフォルトの名無しさん
2014/01/13(月) 02:37:16.10「複数のコンピュータやプロセッサやプロセスや人間やその他のシステムを利用して〜 」
で「複数の」を「イベント発生の時系列を相互にコントロールできない」と具体的に定義すれば
なら完璧かな
0974デフォルトの名無しさん
2014/01/13(月) 02:39:50.27完璧かな？ いやつまりお前の定義とリンク先の定義は違うってことでしょ？
リンク先の定義のほうが正しいので、
それとお前の言っていることが一致していないのであれば、
お前が間違っているということだよ。
0975デフォルトの名無しさん
2014/01/13(月) 02:41:06.51正確には、
ほとんどのプログラムは分散処理であり、どの開発プロセスであれ、特別なツールなしにバグを減らすテスト手法は確立されていない
ごく一部のプログラムくらいについての、バグを減らすテスト手法を議論しているだけ
です
0976デフォルトの名無しさん
2014/01/13(月) 02:42:39.96答え、
ごく一部のプログラムしか通用しないから
>>975によるとという結論です。
0977デフォルトの名無しさん
2014/01/13(月) 02:42:58.210978デフォルトの名無しさん
2014/01/13(月) 02:44:30.70リンク先の定義が間違っている理由は、処理をシステムとして抽象化してないから
0979デフォルトの名無しさん
2014/01/13(月) 02:46:01.98間違ってるのはお前のほうだよ。自覚しな。
0980デフォルトの名無しさん
2014/01/13(月) 02:46:54.86↓やれ！
0981デフォルトの名無しさん
2014/01/13(月) 02:46:55.94そのTDDが通用しないプログラムでは、そもそも「職人芸」以外に流行ってる開発プロセスはない、と追加しておいて
0982デフォルトの名無しさん
2014/01/13(月) 02:57:33.590983デフォルトの名無しさん
2014/01/13(月) 03:07:23.780984デフォルトの名無しさん
2014/01/13(月) 03:14:51.720985デフォルトの名無しさん
2014/01/13(月) 03:23:56.71相手が初心者であるかどうかと関係ない。
単に一般的な定義とは違う定義をしている奴は
初心者ってだけの話。
0986デフォルトの名無しさん
2014/01/13(月) 03:42:07.49TDDの場合は関数Aに対して複数のテストコードを書くことになるから
テストに要する時間はもっと加算していいのでは？
単体テストに応用できるからそっちの時間削ればプラスマイナスとなって誤差なのかもしれんが
0987デフォルトの名無しさん
2014/01/13(月) 03:46:51.92実際、キーボード入力が絡むとテスト駆動無理じゃね
0988デフォルトの名無しさん
2014/01/13(月) 03:47:16.860989デフォルトの名無しさん
2014/01/13(月) 03:52:46.110990デフォルトの名無しさん
2014/01/13(月) 03:56:49.40> 実際、キーボード入力が絡むとテスト駆動無理じゃね
一連の処理の中にキーボード入力コードが切り離しづらい形で入っているとそうだね。
だからコードの正しい書き方が重要になってくるし、
テストしにくいコードはテストしやすい形に修正する必要が出てくる。
既存のコードに単純にテストコードを追加すればそれでOKとは限らないんだよね。
>>989
誰もそんなこと言ってないと思うが？
0991デフォルトの名無しさん
2014/01/13(月) 05:44:09.730992デフォルトの名無しさん
2014/01/13(月) 05:57:50.920993デフォルトの名無しさん
2014/01/13(月) 06:59:27.57キーボード入力が切り離せるなら
GUIも切り離せるから問題ないな
0994デフォルトの名無しさん
2014/01/13(月) 07:00:23.79>>941の式を見る限り1回書ききりだな
0995デフォルトの名無しさん
2014/01/13(月) 07:22:42.10一回なんて書いてないじゃんｗ
0996デフォルトの名無しさん
2014/01/13(月) 07:24:21.04そのとおりだよ。
だけど、切り離すっていうのは
ソースコードの修正を意味する。
コードの途中にキーボード入力が合ったりしたら
それを取り除くのは大変だからね。
単純にテストコードを追加するだけじゃダメなんだ。
テストコードを導入するには、テストしやすいコードに修正しなければいけない。
0997デフォルトの名無しさん
2014/01/13(月) 07:37:13.90テストの為に機能を追加しよう
0998デフォルトの名無しさん
2014/01/13(月) 07:38:09.55ただしコードが汚い場合は
テストコードを入れる前にコードの修正が必要。
0999デフォルトの名無しさん
2014/01/13(月) 07:48:54.17あれのせいで日本のコードは品質があがらないんだよ
1000デフォルトの名無しさん
2014/01/13(月) 07:54:40.34全くだ。
品質をあげることをしない＝品質を下げる だからな。
既存のコードの品質をあげないまま、コードを追加するという作業は
品質を下げるということを意味する。
コードを追加したのに品質は変わらないってことは存在しない。
品質は下がるか、（品質を上げる作業をすることで）上げるしかない。
なにもしないでコードを追加したら、当然品質は下がる。
1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。