「単体テストを手動で行いエビデンス取る」の破壊力
単体テストは自動化するものだと思っていたから 一瞬何を言っているのかわからなかった 概ね当たり感わかんねーんだよな自動テスト作ってるやつバカだから >>106 下から2番目は? 下から3番目は? 下から4番目は? 下から5番目は? 下から6番目は? 下から7番目は? 下から8番目は? 下から9番目は? 下から10番目は? 下から11番目は? 下から12番目は? 複数質問してるんだから全部答えてよw >>97 >いや、得に仕様は出てないんでテキトーに判定して欲しいんですが そういう曖昧な仕様だからバグに繋がるんだろうがwwwwwwwwwww 特に浮動小数点の計算なんてよくバグに繋がるから仕様はっきり決めてテストしなきゃダメだろ 桁数どうするかとかね あと数値系のテストってそこまでパターン無いぞ ・一般的な正常値 ・境界値 ・最大値/最小値 ・異常系(メソッドの仕様によって変わる、nullとか空白とか) テストフレームワークには網羅的なテストデータの投入と判定を一気にやってくれるし それぞれでテストコードを書く必要はないぜ >>107 > 概ね当たり感わかんねーんだよな自動テスト作ってるやつバカだから お前にその概ね当たり感を聞いてるのに、その質問に答えられないお前はバカってことになるよ 消費税計算で1円ずれてても概ねおっけー♪ トランザクションが1万件あっても1万円しかずれなーい とかいいそうなんだよなw >>92 浮動小数点の計算するなら許容誤差ぐらいは理解してからやれよ… >>112 質問に答えられなかったという結末で良いね >>110 というか「概ねオッケー」っていう考え方ってプログラミングだとめちゃくちゃ危険だからな α版とか仕様の仮決め段階だったらまだいいけど、正式リリースの時までその状態にしておくと 絶対にそこ起因のバグか仕様か分からん動きが発生してトラブルになって揉める 当時の議事録とか仕様書の調査に入って悲惨な惨状になるのが良く見える >>113 いや仕様が出てれば有効桁数いくつか指定すればいいけど 計算式しか出てないやつは直前の複雑な計算に引っ張られてる感しかないんだよなぁ >>116 引っ張られるとかイミフなこと言われても… >>95 単体テスト用意してるから実装がグダグダになるんやで 実装に集中しろ いや、突っ込んだ引数と理論値から有効桁数勝手に判断しろ 人間ならできる >>119 >単体テスト用意してるから実装がグダグダになるんやで >実装に集中しろ そうやって場当たり的な実装になるから クソみたいなコードが量産されるんだろうが…… 単体テストに時間割く方が危険 IDEや静的解析があるから単体試験で見つかるようなコーディングミスは ほとんどない、むしろバグの多くは仕様に対する認識不足によるものが多い 結合、総合テストを重視したが良い >>121 んなこたーない、単体テストもコードの一部だからバグ増やすだけ >>120 >いや、突っ込んだ引数と理論値から有効桁数勝手に判断しろ >人間ならできる あのそれ、テストした人によって合格の成否が変わりかねないっていう テストとして一番あり得ない事なんだけど理解してる? 7Payもドコモ口座も単体テストはちゃんとできてただろw 総合テストを軽視した結果があれ 単体テストはプログラマの自己満、システムの品質をあげないどころか 結合、総合テストの時間を減らしてシステムの品質下げることになってる まーた、仕様を理解しないままテストするとかほざく単体テストを理解してない馬鹿が湧いたのか。 いい加減にしろや。 >>126 そういう意味で大変って思ってるなら テストデータ流すして結果が出た後、 その桁数からparseで指定する桁数を決めてから判定すりゃ良い 2000個どころじゃねーな 変数30個ぐらいのクラス200個以上あるもんな 一個一個有効桁数の設定なんかしてらんねーよ >>122 >単体テストに時間割く方が危険 >IDEや静的解析があるから単体試験で見つかるようなコーディングミスは >ほとんどない、むしろバグの多くは仕様に対する認識不足によるものが多い >結合、総合テストを重視したが良い は……? いやいやお前は単体テストをなんだと思ってるん? そんなショボい事になんか使わんぞ 仕様を関数レベルにまで落としこんで、その振舞が正しいかを見るのに使うんだぞ むしろ仕様認識不足がバグの原因っていうなら、それこそ単体テスト書かなきゃダメだぞ 特に仕様変更とかでコード修正入れたら回帰テストする必要があるから 単体テストが無いと修正前の担保とれんやん、やべーやつだなお前 たしかに単体テストすらできないゴミプログラマーがするリファクタリングは虚無だわな。 まともに設計できないだろうし。 時間がかかるのでメソッド単位の出力値のテストはなかったことにします >>125 あれはテストの問題じゃなく仕様の問題 それも仕様のリスクは精査されてたが意思決定者がそのリスクを軽視しただけ よくある話 単体テストとかTDDとか全く分からんなら この動画が一番参考になるから見ておけ https://www.youtube.com/watch?v=Q-FJ3XmFlT8& ;list=WL&index=4&ab_channel=TDDBC-Online >>133 そもそもリファクタリングって単体テスト有りきじゃね? コードが悲惨すぎて単体テストの実装すら困難って時には リファクタリング→単体テスト→リファクタリング→再テストっていう流れになるけど 基本的には現行動作を保証するために単体テスト実装→リファクタリング→再テストが基本だし >>132 単体w 単体で仕様確認する暇あったら結合、総合で確認しろよw 単体で仕様確認できると思ってる方がやべーわwwww テスラのロケット知ってるか? 部品のテスト頑張ったらロケットが飛ぶと思ってそうだなお前 >>135 総合テストを重視してたらその仕様の問題もはっきりわかったってことだ お前のように単体テスト頑張るやつが開発者だったんだろw よくある話だな テスラではシミュレーションをなくして実地で何回もロケット打ち上げること 繰り返して洗練させていったんだよ 単体テストやるやつは所詮ホリエモンロケットなんだよwwwww 単体テストとリファクタリングを重視していたのは15年前〜8年前まで 日進月歩で進化するシステム開発の現在の常識は単体テストとリファクタリングを禁止する方向 >>136 俺の発言は皮肉で言っただけだから、あまり気にせんでくれ。 俺があげたのはまさに、コードが悲惨すぎて単体テストができない例。そういう人達の頭の中では単体テストって無意味なんだろうな(遠い目) って皮肉だから深い意味はない。 TDDはプログラミング界のマナー講師だからなwwww ありもしない偽の常識でっち上げて自分が日銭稼ぐのを目的にやってるだけだから >>137 あのな? 単体テスト、結合テスト、総合テストもどれも重要なんだよ で、単体テストで扱けるものは結合テスト、総合テストでもこけるんだよ 単体テストで拾えるレベルのものを何度も時間と手間かけて結合・総合テストやる方が気が狂ってるわ >>140 >日進月歩で進化するシステム開発の現在の常識は単体テストとリファクタリングを禁止する方向 で、どこの奴が言ってるの? 常識って言うなら少なくとも本ぐらいは出てるよねー? あ、ファクタリングと単体テストの重要性は大体この辺の本に載ってるぞ ・リーダブルコード ・リファクタリング 既存のコードを安全に改善する(第2版) ・ベタープログラマ ・テスト駆動開発 ・レガシーコード改善ガイド ・レガシーソフトウェア改善ガイド ・レガシーコードからの脱却 >>142 お前が一番マナー講師臭がプンプンするぞw しかも説明のしかたに説得力がないからかなり質の低い部類の講師だな >>143 ほらねw その本全部15年前〜8年前のものだよw 最新情報をキャッチアップできてない いま単体テストが一番レガシー >>130 2000個全部有効桁数違うのか? まあありえねーとは言わんけど残念な仕様やねw >>145 で、お前のとんでも理論が載ってるホン早く出せよw ネットでもいいぞ >>148 企業では普通に行われているよ 一般に漏れ出るのはだいたい10年後くらいじゃないかな 10年前の本読んでる時点で時代遅れだからwwwww >>144 自演?流石にこのスレにここまで頭のおかしい人が二人もいたらびびるのだが。 >>149 妄想乙 >>128 いや、突っ込んだ引数と理論値から有効桁数勝手に判断してテストすればいいじゃんw C10K問題ってしってる? あれも企業では当たり前の問題として知られていて とっくに解決策もわかってたんだけど、それが世に出て一般に知られて本がでたのは10年後だった 技術の最先端は常に企業にある >>145 ・リーダブルコード:2012/6/23 ・リファクタリング 既存のコードを安全に改善する(第2版):2019/11/29(第1版:2014/7/25) ・ベタープログラマ:2017/12/15 ・テスト駆動開発:2017/10/13 ・レガシーコード改善ガイド:2009/7/13 ・レガシーソフトウェア改善ガイド:2016/11/10 ・レガシーコードからの脱却:2019/9/19 流石にちょっとぐらいググろうぜ? 古い本から新しい本までバランスよく混ぜて 単体テストとリファクタリングっていう方針は10年近く前から廃れずに続いているって察してくれると思ったんだけどなー >>130 > 変数30個ぐらいのクラス200個以上あるもんな > 一個一個有効桁数の設定なんかしてらんねーよ 有効桁数の設定の意味がわからん。 例として一つだけやってみて いま10年前の本読んで実践してる人は最先端から20年遅れてるwww >>153 > 技術の最先端は常に企業にある C10K問題を解決した企業の名前言ってみ >>154 初版の発売日調べてみ、著者が金稼ぎのために版増やしてるだけだから お前のような情弱を釣ってるだけwwww >>158 > 初版の発売日調べてみ、著者が金稼ぎのために版増やしてるだけだから 金稼げるってことは売れてるってことだよな? お前、何がいいたいの? >>158 全部初版の日付だよwwwwwwwww お前だけ時間おかしくね? >>157 NTT NEC 日立 富士通 IBM HP Oracle Microsoft 三井住友 GE >>161 全部単体テストを行ってる会社か 最先端は単体テストだな >>160 お前が見てるのは再販の日付だろバーカ これだから情弱は・・・ お前のような情弱が買うから著者は版を増やすんですねー むしろこの流れで初版の日付書いて無かったらただのアホだぞ >>153 話題そらすの大好きだね。OOスレ荒してた奴だらお前 >>167 10年前にやめたという情報がないなら、お前は嘘つきってことだよ 嘘つきだね 10年前で時が止まった人間がIT業界でお仕事してるってうけるんですけどーwww >>170 類は友を呼ぶだけ。つまりお前とお前の周りは無能ってことだよ。 大企業は単体テストを続けてるからね >>164 へーアマゾンの日付が間違ってるのかーそうか知らんかったなー あ、オライリー本についてはここの発売日から取って来たからな https://www.oreilly.co.jp/index.shtml むしろ再販の日付の方が探すの面倒だろwwwwww 実際の本見ないと第何版の何時印刷か書いて無いし その後ゴリ押しは無理だろ その場のノリで嘘をつくから こうやって証拠出されて言い返せなくなるんやで 素直に逃げてれば、負けを感じることもなかったのにな(笑) >>168 試しに聞くけど 1.カプセル化についてどう思う? 2.オブジェクト指向についてどう思う? 3.staticおじさん大好き? >>147 そんなの把握できてるわけ無いだろ でも設定しないとチェックはできん >>177 だから1個でいいか設定とやらの例を言ってみろって >>149 ごめんね、俺5年前までHの子会社でHの仕事してたんだけど、どこでその最先端のとんでも理論を普通にやってるって? てか、企業って結構こういうものの対応遅いぞ 特に大企業は手順書とか規格とか山のように修正しないとできないし >>180 え?設定なんていらない。それっぽい値がでてればOK 1円ぐらいずれててもいいやろ って言わないの?w >>182 つまり計算結果が間違っていてもOKってスタンスなんだね >>183 わからないが正解だな 10000個近くの変数の1つ1つは無理ゲー >>184 つまり10000個近くの銀行口座があって 1つ1つ不正送金を調べるのは無理ゲーとw >>187 仕様がわからんとか下っ端の人間か? 自分で決める立場じゃないなら、上の人に仕様もらえなw >>177 把握もできずにコーディング? なんか勘違いしてると思うが計算式毎に有効桁数がここは6桁、ここは4桁とかってやるんじゃねーぞ 普通は最低限必要な有効桁数がちゃんと計算されてるかを確認するだけ ※ 計算式によっては例外あり >>189 だからよ ものによって この値はだいたいこんなもんだろってあんじゃん 3.5とか5.5ならまあそれよ でも 0.0000008596とか 0.00000052354 みたいなのが日常な変数もあんじゃん でも出力値見ればな〜んとなく まあ、あってんじゃね? ってわかるじゃん それよ >>190 今度は逃げずにレスするのか?w > 0.99999999999998みたいなのを概ね1.0お判定してくれそう? 0.99999999999998 を 概ね1.0と判定してほしいの? 0.9999999999998 だった場合は? 0.999999999998 だった場合は? 0.99999999998 だった場合は? 0.9999999998 だった場合は? 0.999999998 だった場合は? 0.99999998 だった場合は? 0.9999998 だった場合は? 0.999998 だった場合は? 0.99998 だった場合は? 0.9998 だった場合は? 0.998 だった場合は? 0.98 だった場合は? >>194 わからないなら上に聞けって、仕事できないやつだなw >>195 数の暴力に屈してしまうのです! 数の暴力に屈してしまうのです! こいつにテストさせたら、それっぽい値なので問題ないと思いましたって答えそうw >>194 すまん、単体テストをどういう風に想像してる? a:関数の返り値/実行結果のみを単体テストで確認する b:実装されてる全ての変数(ローカル変数/グローバル変数)の値を全部チェックする 一般的に単体テストってaしかやらんけどもしかしてbをやろうとしてる…・…? なんか変数が10000個っていうのを見ててふっと思ったから一応確認したい >>198 過去ログ見る限り計算結果をログに出して 目視で数字みてそれっぽければOKらしいよw これが単体テストだとさ (ぶっちゃけ浮動小数点数のテスト仕様を深く考えたことがなくて焦ってる自分がいる) >>190 > まあ、あってんじゃね? > ってわかるじゃん なるほど、ならいいんじゃね 俺には関係ないだろうしw 出力がよ ほとんどDBにぶち込む値だから メソッドの出力がほとんどチェック対象なんだよね メソッド数でいうとクラっとするけど 変数の数なら10000ぐらい 補足 >>202 が言ってるのは、その10000ぐらいのメソッドを 目視で確認するのは大変だから、もうそれっぽければOKでいいじゃん という意味です。 さらに補足すると 10000ぐらいのメソッドを全部自動化でテストするの大変じゃん! 目視でいいよ目視で という意味です。 DBに書き込む値を概ねで済まそうと思ってたのか……(驚愕) バグ出た時の影響範囲がやべーぞ read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる