「単体テストを手動で行いエビデンス取る」の破壊力
単体テストは自動化するものだと思っていたから
一瞬何を言っているのかわからなかった >>53
> だから>>6でもいいんだよな?
>>6には固定値が書かれてないから駄目だって言ってんだろ
理解できますか?
あ、そう。理解できない。
↓こうしろって言ってるだけなのに、理解できないのか?終わってるな
int S=sumAtoF(1,2,3,4,5,6);
int chkS=21;
if(S!=chkS)
{
エラー
} >>55
え?じゃあどうやって21って出したの?
こんなの固定値のわけないじゃん > え?じゃあどうやって21って出したの?
最初に関数を実装するんじゃやなくて
仕様を定義しましょうと言ってる
お前は仕様を決めずにいきなり関数書いて、その関数の実行結果を出力して
俺がコードにバグを入れるなんてありえない。だから21が正しい!と言ってるだけ。
テストを全くしてない >>57
それで?
どうやって21を出したの?
ここが品質のすべてを担保してるのにどうでもいいわけないだろアホか >>58
> どうやって21を出したの?
「例:1,2,3,4,5,6を引数に渡したら21を返す関数が欲しい」
という要件
最初は関数(コード)は存在しない
最初に関数(コード)を実装してはいけない
実装した関数(コード)で出してはいけない
実装する前に決める話
どうやって21を出したの?
それはその関数が欲しい人に聞け >>59
ええ?A+B+C+D+E+Fなんだけど? >>60
それは実装
最初に実装を書くなと何度もいわせるな なんか荒れてんな。
単体テストって固定された仕様に対して実装者次第で変化するロジックをテストするものだろ。
例題があまりにも単純コードだからロジックと実装が一致するなんて現象が起きるのであって、考え方はテスト仕様を満たしているかどうかが重要。
だと思うんだぜ。 >>64
> 例題があまりにも単純コードだからロジックと実装が一致するなんて現象が起きるのであって、
ロジック(実装内容)とテストコードの間違い >>65
そこじゃないよ。
あのアホは「足し算をすることで21になるかどうかわからない」から
コードを書いてそのコードの出力ログで21とでたからOKOK。
21になるかどうかわからないけどログにそう出てるからOKOKって言ってるわけだから 仕様からロジックを作り出すことができなくて、
ロジックを与えられて、そのロジックをコードで書いてるだけの人間なんでしょう
コーダーってやつ >>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年近く前から廃れずに続いているって察してくれると思ったんだけどなー