「単体テストを手動で行いエビデンス取る」の破壊力
単体テストは自動化するものだと思っていたから 一瞬何を言っているのかわからなかった 仕様からロジックを作り出すことができなくて、 ロジックを与えられて、そのロジックをコードで書いてるだけの人間なんでしょう コーダーってやつ >>66 ほう、それじゃ君はどうやって21を出すんだい? 偉そうなこと言ってるんだから誰もが納得できる解答をもっているんだよね? >>68 納得できてないの、お前だけみたいだぞ。 キョロキョロ見回してみなw ちなみに俺は答えを持っているぜ お前ら雑魚といっしょにするな お前らは正しいかどうかわからない自動テスト(笑)をずっと動かしていればいいよ なんだかなぁ...。 sumAtoFって名前からして引数のAからFを足したやつを吐き出すのが仕様なんだろ? じゃあ、その仕様に合ったテストコードを書けばいいじゃん。 って話なのだが...まぁ、それ以前に、だ。 うん?単体テストをする上でテスト対象のメソッドの仕様がわかりませんってやばくね? >>71 テストコードを書くには、関数の計算結果がわかっていなければいけない だが関数を実装しなければ、計算結果は求められない 関数を実装するまで、計算結果はわからない などと言ってるやつだからなぁ どうしようもないよw >>70 ほう、それじゃ君はどうやってログに21がでてて安心するんだい? アホの相手飽きたから質問w BDDとTDDとATDD について 調べてみるとBDDは受け入れテストのような説明がされていて これってATDD(Acceptance Test Driven Development)のことだと思うだけど ・・・正確に言えば受け入れテスト駆動開発と言うべきか・・・はいいとして、 でもrspecってBDDと名乗っているけど、どうてみてATDDではないように思えるんだよな 開発者のためのテストが主だし。 cucumberは明らかに受け入れテストだと思う。rspecにturnipを組み合わせても 受け入れテストになると思う。でも素のrspecはBDD(ATDD)ではなくTDDだと思う さらにググるとBDDを取り入れたTDDと書いてあるのも見つけた rspecってBDDを名乗ってるけど正確な言い方ではないってことなのか? さらにrspecの言うBDDと同じ意味で使ってるテストフレームワークが多い気がするけど 最初から受け入れテストとして作られたものは本来(?)の意味こそがBDDだみたいな感じで BDDという用語を使ってる気がする という認識はあってる? 和田さんのいう「誰のためのテストか」っていうのが これらの用語の使い分けとして一番しっくり来るんだよな ただこういう観点で使い分けられてないという事実があるわけで困る BDD は、rspec, jest みたいに、describe, it を使うもの >>77 俺もそう思っていたんだが、どうも違うんだよな 人それぞれで言ってる意味が微妙に異なってる たぶん、この意見は正解。2つの意味がある。 https://ukstudio.jp/posts/2011/07/02/bdd/ > BDDにはふたつの種類がある > 1. TDDの言い換えのBDD(開発寄り) > 2. ATDD(受け入れテスト)でのBDD(ユーザ寄り) 2つの意味があるのは、まあよくある話なんだけど 1.界隈では何の説明もなくBDDはTDDの言い換えとして使っており 2.界隈では何の説明もなくBDDはATDD前提で語っており 各解説を見ると、この2つの種類がまるでなかったような書き方がされてる それぞれの専門家は、どちらかの用語として使っていて こういうそれほど有名でない人だけが違いに気づいているという感じがする あ、和田さんは有名だけどねw BDDはTDDの言い換えとして広まっちゃってるけど BDDのオリジナルは多分受け入れテストの方だと思う だからrspecのBDDは本来のBDDではない!と専門家が批判記事でも 出していればまだ良かったんだけど、それがないから困惑してる rspecがBDDを名乗っており誰も批判してないからrspecはBDDである。 それを真似たjestなどもBDDである。共通する特徴はdescribe, itである。 これが開発者の間で広まってる認識・・・だと思うんだけど受け入れテスト業界では rspecのBDDを否定せずに、それでいてBDDはATDDであるという前提で語るから困る ちなみにATDDっていうのはcucumberみたいなものね RSpec と言えば、ソニックガーデンの伊藤淳一。 Read Everyday Rails も翻訳してる 「伊藤淳一 rspec」で検索! 色々な記事を書いてる > RSpec と言えば、ソニックガーデンの伊藤淳一。 その人ぐらいしかいないから名前が知られてるだけで 特別参考になることは言ってないかな 大幅に間違ってないってだけで、大多数の人と同じレベル TDDやBDDじゃなくて、 xBehaveとxSpecで検索すべきだった おそらくrspecはxSpec系と呼ぶのが適切なのだろう 伊藤淳一は、YouTube の動画もある 他には、Serverspec の作者、宮下剛輔もいる > 伊藤淳一は、YouTube の動画もある あれやめて欲しい せめて文字に起こせと Ruby のYouTube 動画で、Dean DeHart というマニアックな香具師がいる テスト書き始めるとオブジェクト指向おじさんから関数型おじさんになってしまう Javaでも全部staticメソッド ユニットテスト全く書いたことないのか?っていうレスが最初の方で飛び交っててやべーな それどころかテストケースの洗い出しとかその辺の事全く知らなそう >>86 テスターに任せるだけだから気にしなくていい なんでもかんでも自分でやろうとするな 組織は集団の力を使えるから強いんだ テストはテストの専門家に任せるべきだ 単体テストを頑張っても品質はあがらない 結合テスト、総合テストを頑張るべきだ >>89 >単体テストを頑張っても品質はあがらない >結合テスト、総合テストを頑張るべきだ 単体テストの重要性を知らんのか レガシーコード三部作を買って読んで来い >>91 例えばチェックする値の理論値が12.375だったとするじゃん? でも計算結果は 12.37499999999998 だったんよ お前、これどうすんの? >>92 精度付きで比較する テストフレームワークがそういう機能を用意してる >>89 > 結合テスト、総合テストを頑張るべきだ 手戻りが大きくて時間がかかりすぎる >>94 お前ならどうするのか言ってみ もしかしてログにでていてそれっぽい値だからOKって 目を凝らして何百個も判断するのか?w >>96 いや、得に仕様は出てないんでテキトーに判定して欲しいんですが >>88 テストの専門家というのは、テスト技術の専門家であって テスト作業の専門家なんていねーぞw それは単なるテスター。テスト作業してるだけで専門家じゃない ひどい場合は仕様も何も知らないやつが手動でテストしてしてたりするからな テストの効率化?人増やして人海戦術でやることだなみたいに思ってるやつ >>97 テキトーに判定って 12.37499 という間違った 計算結果になってる場合でも場合OKにするってこと? >>94 一つ一つ指定しない方法もあるよ そういうのもテストフレームワークに用意されてる >>101 だから、間違った計算結果でも 概ね当たり感出てるからOKにするってことですよね? って聞いてるんですが >>100 どんな設定よ? 0.99999999999998みたいなのを概ね1.0お判定してくれそう? >>103 > 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 だった場合は? 概ね当たり感わかんねーんだよな自動テスト作ってるやつバカだから >>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スレ荒してた奴だらお前 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる