「単体テストを手動で行いエビデンス取る」の破壊力
単体テストは自動化するものだと思っていたから
一瞬何を言っているのかわからなかった >>174
アマゾンの日付wwww
お前そんないい加減なことやってんの? 驚愕だわwww
お前の単体テストもそんな感じなんだろ アマゾンの日付wwwww
出版社に電話かけて原本の初版の発売日聞いてみろ
ほぼ全部20年前だから 未だに単体テストの本書いてる人はいるだろうが
お前のようなただの情弱だからwwww アマゾンの日付wwwwwあかんわろてまうわwwwww >>176
試しに逆に聞くけど君はどう思ってるの? >>211
別に?
あって当然のノウハウであり、必須すぎてどうかと問われても困る。
もしも、そこから否定する馬鹿がこのスレにいたら流石に驚く。
まぁ、そのレベルなんじゃないかって疑われてんだよお前は。 >>208
1時間近く考えた結果がアマゾンの日付が間違ってるとかwwwwwww
いや、別に煽るのは構わんけど、原本20年前で戦うのは無茶だぞ?本当に
例えば最新のプログラミングノウハウ書かれた本、英語の原本でも良いから紹介してくれん?って言っても
自分で調べろ一転張り多分出す気無いと思ってるんだけどさ
そうなると自分の主張を補完するソースというか書籍を出せないけどそれは良いのか?
「自分の主張はネットにも書籍にも載ってないけど絶対に正しいです」って言うのは多分一番人を納得させるのが難しいけど良いのか? >>152
今更だが、ごめん。このスレタイのせいで俺のツッコミが自動化の否定に捉えられたか。
そういう意図のツッコミじゃなかったんだ。
すまぬ。 >>214
沢尻エリカじゃんwwwwやるじゃんwwww >>217
いい加減に俺の質問に答てくれ。
お前は別スレでも、いつも都合が悪くなると質問を質問で返したり、無関係な話に話題を逸したり、どうでもいいところで揚げ足を取って相手を批判するよな。
今度はそういうの無しで頼むわ。 176で質問してるんだがな。
質問の仕方を変えるか。
君さ、そもそも有意義な単体テストができるコードを書ける?神クラスとか作ってない? >>208
> アマゾンの日付wwwww
> 出版社に電話かけて原本の初版の発売日聞いてみろ
Amazon(もともとは本屋)はISBNがついている本の情報は出版社から仕入れています。
一応メインであるはずの商品データを手入力してる訳がないやろw クソみたいにピーキーなアサート入れるテストするくらいならそのままログ出力でもしろっていう
馬鹿コード書くやつはよく見るわな。 ピーキーなアサートの意味がよくわからんがアサートとログじゃ用途が違うからお前のアホ意見は却下で アサート書いて実行したらテスト完了、エラーがあれはエラーの出たテスト箇所を知らせるでいいじゃん。
なぜログの目視に拘る。 >>226
成功したところはやってないとかイチャモンつける馬鹿だから。
全ログ流しときゃいいのよ。
馬鹿と馬鹿に挟まれながら作業するってのは大変よ。 単体テストはプログラマの自己満足だから無駄
っていう話がたまに出るけど、あれは一体何故なんだ >>228
使ってない奴がわめいてるだけでしょ
自己満足だろうが修正時の安心感を捨てるとかあり得ん コーダーの安心感のためにどれだけの人件費がかかってると思ってるんだ
経営者目線で仕事しろ 自己満で仕事するな、テストはテストのスペシャリストにやらせろ
組織の足を引っ張ってることを自覚しろ、単体テストをいますぐやめなさい またycF3TYueかよ。いい加減、ROMってろ。 >>226
> アサート書いて実行したらテスト完了、エラーがあれはエラーの出たテスト箇所を知らせるでいいじゃん。
> なぜログの目視に拘る。
アサート書くためには関数の戻り値が必要
だけど関数の戻り値はわからない。
計算式が難しいから、実際に関数作って実行してみないと、計算結果はわからない
だから最初に関数を作る。
その計算結果がそれっぽければ、関数にバグはないとみなす。
関数にバグはないとみなしたからと言って、本当に関数にバグがないかどうかはわからない
つまり計算結果が正しいと証明する方法は存在しない。
だからログを目視してそれっぽいかどうか見るしかない
という理屈だそうな(笑) >>235
その「それっぽい結果の判定」をテストコードとして記述すればいいのに。
そもそも、テスト仕様が不明確な時点で駄目な気がするが...そういう開発しかした事がないのかな。詳しくは本人に聞けってところか。
>>231
経営者目線で仕事をするのなら、単体テストくらいできるようになってくれ。
意味のある単体テストすらできない生産性の低い奴とか俺の会社にイラネ。
もしもテスターと詳細設計担当が別人で、単体テストができないくらいクラス間の依存強度高いクソコードを渡された側であれば許すが、クソコードを作った挙げ句、自分のクソコードを反省もせず、単体テストは無意味だとほざく奴はイラネ。
数千から数万台出荷される製品のソフトウェアや、一般公開されているライブラリに対して単体テストしてませんとか言ったら出荷や公開を止める。リスク高すぎだろ。
なんでたかが人件費のために単体テストをやめるんだよ。それすら回収できないの?
受託開発だったらそこは委託元と相談して決めることだし、自社開発だったら...ビジネスモデルが破綻してるな。
詳細設計そのものがクソでも他テストは通る恐れがある。
販売活動中に詳細設計がクソすぎて開発が止まる恐れのある製品とか怖くて売れない。 >>236
経営者目線で単体テストてwwwww
wwwwアホすぎわろすwwwww
wwwwwwwwwwwwwひぃーひぃー腹が痛いーwwwwww 単体テスト頑張れば頑張るほど品質は下がるというのが現代のものづくりの常識なわけだが
10年前の本読んで仕事してる人とは仕事したくないなあwwwwwwwwwwwwww テストのスペシャリスト(エクセルスクショパシャパシャ)
実際、テスト計画からテストの自動化含めて全部やれる人って
ほとんどいない気がするか……
というよりテスト自動化すらまだ全然進んでない印象 自動化しなくても良い、総合テストに時間をかけたほうが製品の品質は高まる
テスラのロケットもそうやって飛んだんだよ
自動化という手法にこだわってコーダーの自己満で単体テストやってるのは
所詮ホリエモンロケット止まり 大事なのはユーザビリティでありプロダクト
細かい部品のチェックを頑張ってもどうにもならんぞ >>240
ycF3TYueさんよ、マジで黙っててくれないか?
お前さっきから邪魔。昨日のように逃げて大人しくしてろ。 単体テスト頑張って会社の売上が上がった人は単体テストのコンサルタントやってるIT業界のマナー講師くらいだろ
やってることが自作自演なんだよ
日本の仕事の生産性が低いのも細かいところで頑張って全体の品質から目を背けているからだ
開発者が力を注ぐべきはプロダクトでありユーザの満足度だ
わーい単体テスト自動化できたーとこれで安心だーなんていってるのはレベルが低すぎるんだよ
高卒ならそれで良いかも知れないが大卒はそんなことやっちゃダメ 大局を見よ、戦略を練れ、竹槍にこだわって戦争に勝とうとするな >>239
まぁ、自動化以前のところで詰まってる人は多いかも。 リファクタリング、単体テストを頑張る人間は一生クリエイティブな仕事できない
ユーザはネジの品質なんて気にしない、プロダクトが使いやすいかどうかが全て
ユーザ目線に立って生産性の高いアジャイルな仕事を成功させるためには自己満足を捨てて
顧客満足を選ばなければいけない 単体テストの自動化を目的に仕事してる人がいる、IT業界のマナー講師だ
嘘をバラマキ生産性を下げる原因だ、出会ったら心から軽蔑してあげよう >>243
アジャイルなのに単体テストに意義を見いだせないって終わってるな。しかも、自動化スレでこんな発言だもんな。
アジャイルという言葉を理解していなさそう。 >>248
アジャイル == 単体テストと思ってそうwwwwwwwwww
wwwwwwwwwwザ・ガラパゴスって感じwwwwwwwwwww アジャイル == ユーザ
これが本当のアジャイル
ユーザが見るのは単体テストの結果じゃない、プロダクト >>249
そういえば、お前、昨日220の質問で逃げてたけど、答えないの? まともな企業で仕事してみ、総合テストを重視したほうが品質高まるねってのが常識だから >>243
>日本の仕事の生産性が低いのも細かいところで頑張って全体の品質から目を背けているからだ
>開発者が力を注ぐべきはプロダクトでありユーザの満足度だ
なんでアジャイル開発やTDDに発展していったかっていう経緯が全然分かってないやん
単体テスト無しで各コードが密結合されたプログラムの場合、変更のコストが膨大になる(作業工数の膨大)
で、プログラムっていうのは常に変化するものだ
不具合対応だけでなく、それこそユーザー要望によってコードはどんどん追加される
で、そのユーザーを満足さえるためにコードを変更するって事は仕様追加だけでなくて、既存仕様の担保も同時に必要になるんだよ
密結合されたコードは修正時の影響範囲が大きく、容易に変更する事が出来ない
何より変更後の既存仕様の担保っていう点で言えば、全てを保証するためには膨大なテストが必要になる
単体テストを『ちゃんと』作ると、プログラムは自然と疎結合になっていく(なぜならそうしないとテスト自体が書けないので)
更に仕様変更後も単体テストを動かす事で、少なくとも単体テストを実装している個所については
変更前後の動きを担保する事が出来る
もし抜けがあれば追加すれば良い、そうすれば次からはそこは抜け落ちない
つまり最初の工数こそかかるが、リリース後の保守/仕様変更に強いプログラムが出来上がる
これは長期的に見ればユーザーにも開発者にとっても大きな利点
お前はリリースした後の長期的な観点が抜け落ちてるからこそ、単体テストを軽視してるんだろ
ウォーターフォール式の開発で技術者寄せ集めてでプロジェクト終わったさー解散、ってやってるような奴だなとしか思えん
……というか調べたけど、テスラのロケットがシミュレーション止めたっていう話自体全然出てこないんだが…… >>239
単体テストは基本設計者がやるから
自動化環境の導入は片手間じゃなかなか難しいからうちは専任の部隊がいる
一旦入れれば次からはそんなに苦労しないんだけど最初のハードルはちょい高めやね
>>242
NGしとけ というかユーザーは単体テストを見ない、だから単体テストは不要
っていうのは恐ろしいほどの暴論だぞ
ユーザーが必要としている領域と、開発側で必要としている領域は一致しない部分が出てくるんだから
全く理由になって無いぞ >>253
密結合wwww疎結合wwwwいかにも10年前の本に書いてそうなことだなwwwwww
単体テストがないから設計ができないなら設計力が足りてないわ
単体テストしてる場合じゃないプロダクトと向き合えユーザと向き合え
単体テストでパソコンと向き合ってんじゃねえwwwww >>256
じゃあ単体テスト不要の根拠になるソース出して?
>>154辺りの本が古いのであれば、当然当たらしいやつがあるんだよな?
ソースが無けりゃただの妄言だぞ >>253
密結合されたコードの破壊力はヤバいね。
何がやばいかって、最悪、1から作り直しになるから。
そして、そんなコードを作る人達がリファクタリングしたり再設計させたところで同じことを繰り返すから。
俺の会社の過去最高のクソプロジェクト案件が脳裏に浮かんだよ。
まぁ、あんたの言うとおりだわな。
>>255
> ユーザーが必要としている領域と、開発側で必要としている領域は一致しない部分が出てくるんだから
> 全く理由になって無いぞ
全くそのとおりだ。 >>257
まともな会社で仕事してみ
総合テスト > 結合テスト >>>>>>>>>>>>>>>>>>> 単体テスト
品質を左右する優先度はこれ 単体テストはコーダの自己満を超えられないのよ
もっと広い視野でプロダクト全体を見渡さないとよいプロダクトは作れない
プロダクト売るのはコーダじゃないから気にしたことないだろうけど
分析してみるとユーザの満足度に単体テストレベルの些末なことは一切関与しない たとえカバレッジ120%であってもユーザビリティが低ければ使われない
ユーザの満足度とコーダの満足度は違うもの
UIを洗練させ機能を洗練させユーザが本当に求めてるのは何かと
考え続けることがプロダクトの品質を高めることに繋がる
それがユーザと向き合うってこと、パソコンと向き合ってるだけじゃダメ ソースは明かせないが、信頼できるとある専門から聞いたという話では
単体テストをやればやるほど売上が下がることが明らかになったそうだ
な?そういうことなんだよ >>262
たとえカバレッジ120%であってもユーザビリティが低ければ使われない
それなら
たとえカバレッジ120%であってもユーザビリティを高くすればいいだけでは? 目的はユーザを満足させることであり単体テストはその手段として
使われるのだけれども単体テスト頑張ってもユーザの満足度あがらんね
それはどうしてだろうプロダクトの品質があがるわけじゃないからだってのが
20年前〜10年前まで単体テストを頑張って得られた結論
いまは結合テスト、総合テストを自動化して品質を高めるのが主流 10年前の知識で頑張ってるお前らは俺を煽ることでどうにか今の技術を聞き出そうとしてる情けない人たち 本を読んでPCと向き合うとことしかしてこなかったお前らの限界
ユーザと向き合うことを避けてきた根暗なコミュ障に開発の最先端は無理 なんかヤベー奴沸いてるからこれ貼っとくわ。
詭弁の特徴のガイドライン
1.事実に対して仮定を持ち出す
2.ごくまれな反例をとりあげる
3.自分に有利な将来像を予想する
4.主観で決め付ける
5.資料を示さず自論が支持されていると思わせる
6.一見関係ありそうで関係ない話を始める
7.陰謀であると力説する
8.知能障害を起こす
9.自分の見解を述べずに人格批判をする
10.ありえない解決策を図る
11.レッテル貼りをする
12.決着した話を経緯を無視して蒸し返す
13.勝利宣言をする
14.細かい部分のミスを指摘し相手を無知と認識させる
15.新しい概念が全て正しいのだとミスリードする
16.全てか無かで途中を認めないか、あえて無視する
17.勝手に極論化して、結論の正当性に疑問を呈する
18.自分で話をずらしておいて、「話をずらすな」と相手を批難する
19.権威主義に陥って話を聞かなくなる >>259
まともな会社ってどこ?
お前の勤める自宅警備会社? >>268
昨日の昼間からム板に張り付いている人に言われても説得力ねぇわ。
そしてそれと同じくらい、お前の50を超えるレスに説得力ねぇわ。
ツッコミを入れる周囲の人達の発言のほうが説得力があるね。
もう少し自分を疑うことをおすすめするよ。 >>259
はい、ソース無し
というか単体テストすらまともに実装出来ない会社の間違いじゃないの? >>266
> 目的はユーザを満足させることであり単体テストはその手段として
> 使われるのだけれども単体テスト頑張ってもユーザの満足度あがらんね
だから両方やればいいだけでしょ? マジで無能な働き者感半端なさ過ぎて洒落にならんな>ID:IgGP+BQU
あんまり煽るのは趣味じゃないが、流石にここまで酷いと思わんかった
>いまは結合テスト、総合テストを自動化して品質を高めるのが主流
本当に聞きかじりばっかだなお前
結合テスト/総合テストの自動化は開発の最終盤(UI含めてほぼ構成が固まった段階)に辺りからやるもんだぞ
さらに大前提として結合/総合時に自動化に耐えうるレベルでバグを潰しておく必要がある
つまり、単体テストで予めて一通りの品質が担保出来てなきゃ、自動化なんざ夢のまた夢だぞ >>266
> 目的はユーザーを満足させることであり単体テストはその手段として使われるのだけれど
最終的にはそうなるかもしれないが、あくまでも単体テストの目的は詳細設計の妥当性確認では?
お前、>>253のツッコミをミスリードしてないかw?
時代遅れとか以前に、単体テストが何を目的とするのかすらわかってないじゃん。
>>273の言うとおり、両方やればいいだけだよ。そして、両方やる必要がある時点で他のテストとは目的が違うんだよ?理解してる? 更に言うと、実行時間って言う面においては自動化を含めても
単体テスト>>結合テスト>>>>>総合テストっていう絶対に崩せない不等式がある
(総合テストはseleniu辺りを使ったものを自動化を想定してる)
単体テストはフィードバック速度が段違いに早いんだよ、だからアジャイル開発やTDDにおいても重要なファクターとなる
あとずーーーーーーと引っかかってたんだけどさ
単体テスト、結合テスト、総合テストは仕様通りに動くかどうかであって、ユーザー満足度とは何も関係無いぞ
仕様通る作成できている=ユーザーも大満足する、にならないからウォーターフォールだとダメって風潮になってるんやん
(ユーザーの声が最後の最後にしか出てこないから、フィードバックを反映するのが困難なため)
ユーザーが満足するか、使いやすいかっていう判断をするのはユーザービリティテストっていう
評価観点が全く異なるテストを実施しないといかんのだぞ
流石に二日待っても『ユーザービリティテスト』って言葉が一回も出てこないから本気で心配してるんだぞこっちは >>276
結合テストの段階でユーザも巻き込んでやるだろ
お前のとこやってないの? それアジャイルじゃないよ
ただのウォーターフォールだよ、どうりで単体テスト重視してるわけだわな
ユーザと会うことさえない下っ端仕事しかしてないんだろ アジャイルとはユーザと一体化して共同でプロダクトを作り上げるものだ パソコンと向き合ってれば良い仕事って気楽でいいなwwww
プロダクトの品質気にしなくていいし顧客満足も気にしなくて良いもんな
うらやましいわwwwwww 10年前の本実践してイキってれば良いもんなwwwwwwwほんまええなーwwwwww こんなにム板の住人多数から集中砲火を受けてもレスできる図太さに驚きが隠せない。 >>277
け、結合テストにユーザーを巻き込むwwwwwwwwww
ちょっと想像の斜め上どころの解答じゃなかったな
アジャイル開発でもそんなクレイジーな事せんわ
なんで結合テストしてない代物をユーザーと一緒にテストするなんて言うトチ狂った発想が出てくるんだよ
お前の開発環境クレイジーすぎるだろ…… >>282
アジャイルでは次の優先度でテストをやります
総合テスト > 結合テスト >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 単体テスト
ちなみにお前がアジャイルやったことないのは明らかで
盛大に勘違いしてそうだから老婆心で教えてやるけど
アジャイルでは総合テストを結合テストよりも先にやるからな
総合的に使い物にならないものを詳細までテストするのは時間と金の無駄だから
ウォータフォールと真逆のことをやってユーザの満足度を最優先にしてプロダクトに反映する
これを全体最適化と言う ガラパゴスジャパンのものづくりにはその俯瞰的な視点が抜けてるから欧米にはまだまだ追いつけない
過去の慣習からいまだに抜け出せずに10年前の本をありがたがっている人もいるくらい残念な状況 >>283
>ちなみにお前がアジャイルやったことないのは明らかで
お前のことだろ。 そう、いうなればいまだに単体テストを頑張ってるプログラマはさながらハンコ議員連盟みたいなもの
時代遅れの技術にいつまでもしがみついて進歩を遅らせてるってこと
愚鈍で低能な人間は日本の未来を暗くするだけ、ノロマの罪で逮捕して冷たい牢獄で一生を過ごして欲しいくらいだわ >>286
それじゃいまだにログを目視で頑張って眺めてそれっぽい値ならOKなんて言ってるやつはどうなるの? 単体テスト(自動テスト)で正しい値と比較 vs 目視確認でそれっぽい値かどうかチェック
って話だったの忘れたのかな?w >>288
そんなことしてたらユーザビリティテストする時間なくなるやんw >>289
結局最後に頼れるのは人間の目だからな
何のために目が付いてるか考えろ
ログを見るためだろうが しかもそれっぽい値かどうかしか確認しないからバグだったとしてもわからんし
正しい答えがわからないからログに記録されているのがバグだったとしても
それっぽい値ならOKにするんでしたっけ?w >>286
その理屈だとプロジェクト作成時にテストコード記載場所を用意するAndroid Studioは時代遅れってことになるな。
つまり、Androidは時代遅れと。 >>291
見てどうするの?
お前に見張り番頼んだら、盗まれていくのを見てましたって言いそうw 訂正
>>291
ログ見てどうするの?
お前に見張り番頼んだら、盗まれていくのを見てましたって言いそうw >>283
>総合テスト > 結合テスト >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 単体テスト
はーまたソース無し
IPA辺りの資料だけど、アジャイル開発の進め方見てみ?
https://www.ipa.go.jp/files/000065606.pdf
9ページにはTDDを基本にするって書いてあるやろ?
つまり単体テストを避けて通れないの
あと先進的な設計・検証技術の適用事例報告書 2015 年度版の資料
https://www.ipa.go.jp/files/000049403.pdf
ここに単体テストの有用性を検証した結果出てるぞ、15ページな
それっぽい言葉で誤魔化してるつもりかもしれんが
何ども言うがソースが無いなら一切妄言と変わらんからな >>296
そうするか、NG登録しよ。
荒らしとしてBANされることを祈ろう。 まあ、なんとなく言うこともわからないでもない
結局、単体テストのチェック項目は言うほど明確にならないってことだな
浮動小数点の変数1つとっても厳密にやると恐ろしく時間がかかる
彼も全くなんのチェックもしないわけではないだろう
ただ、リリース毎に走らせるような仕組みなんか無駄なコストだと思う
もちろん動かないなんてのは言語道断だがそれは従来のテストで不十分か?と言えばそんなことはないと思う
それよりは結合で出る他のモジュールとの不整合や
総合で出る使い勝手の悪さの修正などに時間をかけた方がいいと思う
さらに言えばリリースしたあともユーザが使ってないような機能なんていっそ小規模な不具合があってもほっといてもいいのではないか?とは俺も思う
もちろん動かないなんてのは言語道断だが
部品のテストをいくら頑張ってもロケットは飛ばないというのは正しいと思う
まあ、これで悩むのは請けた仕事がそこまで判断するような広範囲な仕事だけだが おい、ためしにlgGP+BQUは何か書き込んでみろ(原爆投下)。 >>299
>結局、単体テストのチェック項目は言うほど明確にならないってことだな
>浮動小数点の変数1つとっても厳密にやると恐ろしく時間がかかる
一回仕様決めてテスト書いたら
後はもう1関数辺り数秒にも満たない実行時間しか無いぞ……
つか浮動小数点のテストなんてそこれそユニットテストで良くやるやつやん なんの作戦もなく単体テストの自動化を勧めてくるペテン師に引っかかってはならないというのはガチだと思う
・自動化Scriptの作成コストはでかい
・単体テストよりもうちょっと上の階層のテストの自動化の方がよくないか?
・そんなに何度も単体テストしないし
・かけたコストに対するリターンが小さそう?