「単体テストを手動で行いエビデンス取る」の破壊力
客「正しく動いているというエビデンスが欲しい」 SI「正しく動いてるかどうかなんてどうやって証明したらいいかしらん テストやったというスクショ用意すりゃいいんじゃないか?」 これ そうそう、結局こういう入力(ユーザによる操作や設定ファイルも含む)に対してこう動くようにしましたよ としか言えない だからエビデンスが重要だって言ってんじゃん 21が正解かどうかは誰にもわからないんだよ もっと複雑な計算で客も式は知ってるけど 実際に計算した値はわからんようなのだったらどうやって出すよ? PG「大丈夫、エクセルで数式でこのように出した値と一致しています!」 客「は?なんでそれが正しいの?」 PG「え?」 みたいになるやつはここの理解が足りない どこまで突き詰めても究極的にはわからない わからないものを説明しなければならない > 21が正解かどうかは誰にもわからないんだよ じゃあログ出す意味ないじゃんw どうせ文字化け出力してても正解かどうかわからないだろ > もっと複雑な計算で客も式は知ってるけど > 実際に計算した値はわからんようなのだったらどうやって出すよ? 計算式は神が作り出したものとか、いきなり湧いて出てきたって思ってそうw 高校レベルの数学はそうだね。計算式は覚えるもの だけどな、本当は計算式っていうのは、ある値を出したいと思って 「計算式を作る」ものなんだよ。作るのは計算式。それがコード ゲームの当たり判定でも、あれとこれがぶつかったのは どう計算すれば導き出されるんだ?って悩んで ぶつかったという答えを出す計算式を作り出すものなんだが 本を読んで計算式をみて、ぶつかったかどうか? この計算式を使えばぶつかったという答えが出るんだよ みたいに思ってるんだろう。 自分でアルゴリズムを考えたことがないから 計算式ググって、そのとおり計算して なるほど、これが計算した答えか。 答えなんて計算しないとわからんな。と言ってる 計算式を作り出したことがない 内部にジェネレータとかIOとかを持ってて、冪等じゃない関数のテストってどうやったらいいの? そういうのは単体テストの対象外? >>45 1つぐらい何か言い返せよw お前がやってるそれが遠吠えじゃねーかw >>46 冪等性がなんで出てくるのか知らんが 与えられたデータ(引数だけじゃなくてすべての状態)が 同じであればその結果も同じになる テストというのは、固定のデータを使って固定の結果と比較するもの 固定のデータが用意するのが難しいのであれば その部分にスタブ(モック)を利用する 十分、単体テストの対象内 というか単体テストができないなら、その他のテストもできないだろ >>47 だからなんの意味もねーってそれ お前がエクセルで計算した値だろw >>41 >そうそう、結局こういう入力(ユーザによる操作や設定ファイルも含む)に対してこう動くようにしましたよ >としか言えない 考え方が間違ってる 入力に対する出力が要求仕様通りになることをこういうテストケースで確認しましたよと言えればいい 21が正解かどうかは要求仕様による テストケースを作る能力の有無の前に 要件定義がまともにできてることが必要 できてなければデスマーチ確定 >>49 だからそう言ってるじゃん >>41 にそう書いてあるだろ >>48 > お前がエクセルで計算した値だろw 何で計算するとかどうでもいい話だろ 何をする関数を作りたいのか? 作りたい関数は「何を入力とし、何を出力とするのか」 その仕様を決めてから関数を実装する。そして正しく実装されてるかテストする お前は仕様を決めずに、関数を実装して その関数が出力する答えが正しい!バグなんてない!って言ってんのか? 繰り返すぞ 仕様を決めてないのに関数を実装してんのか? 関数なんかフィーリングでつくるだろうふつう 関数の設計?関数仕様書みたいのをいちいち書かせるタイプのアフォなんか? >>51 ホントだ どうでもいいなw だから>>6 でもいいんだよな? >>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年近く前から廃れずに続いているって察してくれると思ったんだけどなー >>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に書き込む値を概ねで済まそうと思ってたのか……(驚愕) バグ出た時の影響範囲がやべーぞ >>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の作成コストはでかい ・単体テストよりもうちょっと上の階層のテストの自動化の方がよくないか? ・そんなに何度も単体テストしないし ・かけたコストに対するリターンが小さそう? >>303 すげー大変じゃん 仕様を定義するやつも 小数点いくつで四捨五入なのか切り捨てなのか全部考えないと でもそんなことしなくてもプログラムって動くし んでこういうのって会社で一旦やるって定義されちゃうと全部やらないといけなくなっちゃう でも大半は必要ない >>304 >・自動化Scriptの作成コストはでかい それは正しいが、テスト自動化の作成/修正コストは 総合>>結合>>単体テストの関係になる (必要な構成、モジュールが総合テストに近づくほど増えて影響範囲がどうしても増えるので) >・単体テストよりもうちょっと上の階層のテストの自動化の方がよくないか? 総合/結合テストの自動化はバグを発見するのが目的ではなく 既存機能が壊れてないを確認するために使うんだぞ? 勘違いしてる人が要るかもしれんが、総合/結合テストでバグが頻発すると テストが失敗した原因の調査〜修正の作業に無視できない工数がかかるから、 作成コストが少ない単体テストが整備出来てなきゃ宝の持ち腐れだぞ >・そんなに何度も単体テストしないし それは単純にサボってるだけ 継続的デリバリーとか継続的インテグレーションっていうスタンスで立つ場合 CIツール、例えばJenkins辺りで構築する場合 ソースをコミットしたタイミングで、コード解析、自動ユニットテスト、ビルドまで一連でやるようにする だから一番動かすのはむしろ単体テストになる https://www.techmatrix.co.jp/product/cisolution/service/index.html https://tracpath.com/works/devops/continuous-integration/ >・かけたコストに対するリターンが小さそう? んな事ない 上記の例も合わせてリターンは大きい 自演成りすましかとも思ったが本物だった 幼稚過ぎるやろ >>307 自動テストは単体が一番作るの大変だと思うけどなw 結合や総合はモジュールや機材のセッティングは大変だけど 作るのは簡単やろ だってUWSCで画面のボタンをポチって押すだけやろ 少なくとも俺はそんなイメージだけど? >>309 >作るのは簡単やろ >だってUWSCで画面のボタンをポチって押すだけやろ それは考えが甘すぎだわwwwwwwwwww それだと操作しかしてないやん UI周りの自動テストを実装する場合 ・テストシナリオ(どういう操作をするのか) ・テストの判定基準 (想定通りの画面に遷移しているのか、表示されるメッセージが正しいか、データ登録が絡むならその結果も正しいのかなど) ・テスト結果の判別方法 (これはテストシナリオによって変わってくる、登録データをそのまま引っ張り出すならDB接続して想定値との乖離が無いかチェックする ものによっては画面キャプチャで画像差分を見るってやり方もあるけど個人的には好きじゃない) 最低でもこの辺を意識して作らんといかんから、 そんな画面ポチポチ終わりーでいかんぞ…・… 特にUIの自動化は変更に弱い認識だから、本当に最後の最後で実装しないと地獄を見るし >>307 単体テストのモジュールってさ 上流で変更があると枝葉って変更じゃなくて消滅と生成のが多くない? そうなると実ははじめの一回目しか実は見てないんじゃない?って俺は思っちゃうんだよね 枝葉をくっつける本流の方が間違ってるときってそれそもそも自動化以前にテストやっとるのかと? 俺は単体テストの自動化テストはヒット数(実際にバグを捕まえた数)は少ないと思ってる 苦労した割には Ruby on Rails のRSpec で有名な、ソニックガーデンの伊藤淳一とか、 Serverspec の作者・宮下剛輔とか、有名 YouTube で有名な、雑食系エンジニア・KENTA は、 初心者のRailsポートフォリオに、CircleCI まで入れれば、有利と言ってるし 有名は人は皆、BDD の鬼! >>312 単体テストでバグの発見数は正直重要じゃないな というかそんなん集計とるか? 普通は単体テストが成功してからコミットするし、テストコード無しでコミットしようとしたらプログラマー〆るだろ ……というか仕様変更の度に関数が消滅と生成が起きるって それはどっちかと言うとプロジェクトの問題では……? >>311 総合や結合の結果の判別なんか ログの最後の出力がCompleteだったぐらいでええやろ 機材がクソってるのにログにCompleteって出てるならそれってテストScriptのせいじゃなくてそもそもログ出力腐ってるやろ? >>314 きっちりメソッドが分けられず 他の機能と融合してるから 変更が多いんやろ 普通は上流の変更があったら枝葉のメソッドは生成と消滅が多い >>306 そこは仕様によるし、あと責務の分割とかそういう発想でプログラムを組めばいい 超簡単な例として、電卓を上げるぞ win10の電卓を叩くと 10/3 = 3.3333333333333333333333333333333 20/3 = 6.6666666666666666666666666666667 っていう感じで小数点31桁で出てくる この結果から以下の仕様が読み取れる ・計算した結果が無限小数の場合、小数点は31桁まで表示する ・小数点31桁目は四捨五入して表示する っていう仕様が予測できる と言う事は、最低限の実装方針としては以下のようにすると、楽に単体テストが実装できる ・計算ロジック側は小数点31桁よりも大きい桁数でユニットテストは判定すれば良い、単体テストは可能だし、変更も簡単にチェックできる ・画面表示をする際に小数点31桁として出力するように四捨五入するメソッドを実装してかませればいい、このメソッドも単体テストが可能になる ようは必ずしもすべての計算結果の小数点桁を指定する必要は無い、基本的には余裕のある実装にしておけば早々壊れない >>315 それはテストツールによるとしか言えん ちゃんとしたGUIテストツール使って、シナリオも確認してるのであれば もちろんばログレベルの確認で良い ただUWSCって名前が出たからついな あれは自動操作用の目的だし、そもそも今開発止まってるから使うべきツールではない >>314 テストコードコミットしたらぶっ殺すわw 仕事しろと 複数の下流工程を管理する際、テストコードの無い成果物を渡されても、そのソフトウェアモジュールを製品に組み込んでもいいのか判断に困る。 そもそも、単体テストが済んでいるということは、そのソフトウェアモジュールはテスト仕様の範囲では正しく動くことが保証されているわけだ。 だから、完璧な単体テストさえ行っておけば、完璧なモジュールを組み合わせて完璧な製品が出来上がるから、理論上完璧な単体テストができれば結合試験すらいらないんじゃないなって思う。(流石に大胆発言か?) ※顧客満足のチェックまでは無理だが。 ※ここで言う完璧なモジュールというのは組み合わせれば理想な製品ができるモジュールのこと。(前提条件がシュールすぎる?) まぁ、現実的に人が設計をする以上、仮に一つ一つのモジュールがテスト仕様書を満たしたところで組み合わせても上手くいく保証はないから結合テストもやるんだが...。 単体テストについては、こんなイメージだな。 プロならテストコード書かなくても動くコード書くのが普通 単体テスト書くことが目的化してしまってるのがマナー講師と呼ばれる所以 >>321 単体テストは時間の無駄だから 単体テストのテストコード見て判断する木偶の坊が管理してるとかそのプロジェクト破綻してるだろwwwwwwwwwwww 大局を見ろよ、設計として正しいかどうかで判断しろ、単体テストのテストコード見てどうするんだバカwwwwwwwwwwwwwww wwwwwwwwwwwwwwww笑い死にさせる気かwwwwwwwwwwwwwww なんか、さっそく、あぼーんされている奴が沸いてるんだけど。 ごめんね。俺のブラウザだと、NGが共有されるから、読めないや。 「単体テストのコードがあるな、よし!」とか言ってるのかwwwwwww wwwwwww現場猫かよバカがwwwwwwwwwwwwwwwww wwwwwwwwwwwwwwwwwwwwwww >>324 見てるくせにwwwwwNG解除してみてるくせにwwwwwwwwwwwww wwwwwwwwwwwwwwwwwwwハゲワロwwwwwwwwwwwwww wwwwwwwwwwwwwwwwwwwwwwwwww お前ら笑いの才能だけはあるよなwwwwwwwwww wwwwwwwwwすげーわ単体テストのテストコード見て管理した気になってるとかwwwwwwww wwwwwwwwww次元が違うわwwwwwwwwwwww >>328 ロクなテストしてないな、やっぱ単体テスト無駄だわ、そのテストなくても問題ない いいよなーオープンソースは気楽でよー、人件費なんて無限に湧いて出るようなもんだもんなー お前のようなアホが実績欲しさに無駄なコード書いてくれるもんなーいいなーうらやましいなー 無駄なテストコード書いて時間つぶして居られるなんて幸せものだなー 無駄なコードでも大変だから仕事した気になれるんだろうなーやりがいはありそうだよねーwwwww wwwwwwww一銭の価値もないけどwwwwwwwwwwwwww お前ら授業中に真面目にノート取って先生に褒められて勉強できる気になってそうwwwwww >>328 有名どころのテストコードを見たことが無かったけど、思ったより普通だった。 でも、まぁ、勉強になる。 >>329 >ロクなテストしてないな、やっぱ単体テスト無駄だわ、そのテストなくても問題ない 「この単体テストは無駄、不要」っていう判断を下すには以下を知って無きゃいけない ・テスト対象のコード仕様 ・テストコードの内容 先に言っておくが、無駄なテストコードっていうのはもちろん存在するぜ テストカバレッジを水増しするようなコードとかな あんたは3分足らずで言語仕様も異なる二つのフレームワークのソースを見て コードの仕様とテストコードを理解して文句を付けてるわけだ いやー、すごいすごい、単体テスト不要派なのにめちゃくちゃ詳しいんですねー あ、ちなみにだけどさ『2020年』のWeb調査で 次に学ぶべきWebフレームワークの人気ランキングで Djangoは3位、Springは7位につけてるぐらい人気があるフレームワークなんで https://info.hackerrank.com/rs/487-WAY-049/images/HackerRank-2020-Developer-Skills-Report.pdf PythonのテストフレームワークでPyTestっていうのがあるんだけど サンプルコードが少ないっていう問題があるんだが その時はPyTestのgithubを見ると良い https://github.com/pytest-dev/pytest/tree/master/testing なんとPytestはPytestでテストしてるから、これを読み込むのが一番良かった 何より分かりやすい 日本では、この2人がBDD の鬼! Ruby on Rails のRSpec で有名な、ソニックガーデンの伊藤淳一は、 RSpec の本、Everyday Rails も翻訳してるし、 Serverspec の作者・宮下剛輔も、有名 結局オープンソースとか有名プロジェクトは 単体テストを行うのは最低限の常識レベルになってるんだな あ、もちろん単体テストを自動テストするって話ね 手動だったら単体テストやってるなんてこと外部からわからないから当然かw 手動テストの問題はコストがかかること 人海戦術でやるという発想でコスト意識がないのだろう だいたいこういう所は客が金を出してる。つまり自分の懐は傷まないw コストがかかる手動テストのプロジェクトでのコスト削減の発想はテストが必要なることをやらないこと ソースコードを修正するとテストが必要になる。つまり極力ソースコードを修正しない。 こういうところは未だにIEじゃないと対応してませんとかやってる。 作って検証ができないからユーザビリティも悪い Google map https://github.com/googlemaps/android-maps-utils/blob/master/library/src/test/java/com/google/maps/android/PolyUtilTest.java#L7 調べると事例なんて腐るほどあるな。 ただ、いまいち自動化という言葉の意味がわからない(ただの無知)。 有償のテストツールを使ったことないけど...自動化とは言えど、テストコードを記述してビルドして実行することには変わりがないのだろう? 無知故の疑問だが、自動化と非自動化の差って何だ? >>342 「ちゃんとテストしたのか?」 ・自動化 「はい、ここにテストした内容が書いてあります。これを実行しました。 テストに通ったことはテストの実行結果から判断できます。 もう一回やってみろって?コマンドを実行するだけですのですぐ終わります。」 ・非自動化 「はい、ここにテストした証拠のスクショがあります。手順通りに実行してOKっぽかったからチェックを入れました。 テストに通ったかどうか?手順通りにやりましたよ!スクショがあるんだから信じてください。 もう一回やってみろって?全部ですか!?何時間、いえ何日かかると思ってるんですか!」 >>344 あなたがもう一回実行すればいい あなたもすぐにテストを実行したというエビデンスを作ることができる >>345 じゃあ、作業未完了だね 納品物にエビデンスって書いてあるじゃん >>346 実行した姿をビデオカメラに写しておけばいいだけでは? このテスト、私が実行しましたってwww それ以外に何が欲しいんですかねぇ エビデンスが要求される粒度のテストのためにエビデンス生成フレームワーク作っとくと便利よ もちろん1番大事なのは自動テストの性質に合わせたエビデンスの形態を定義して、客に受け入れさせる営業力だが 日曜だから市場で買ったカニの出汁を濃縮してるわ、冷凍してとっとくんだ これがホントのカニdense >>349 テスト自動化のほうが安くなります。 手動で作業したらその分時間がかかります。 スクショとったらその分時間がかかります。 しかもそのとったスクショ、あなた全部検収するんですか? みたいにいえばOK 金と手間がかかる問題を客に押し付ければ意見は通る UIの自動テストはスクショもログ+スクショ自動生成までやってくれるから 本当にエクセルに張り付ける作業は不要なんだよな スクショ張り付け作業をこれやらされる新人はマジで悲惨 しまいにゃ手動でやれば、バグがあって金がかかろうとも、丁寧な作業をしてると客を騙しはじめるのだろうな ていうか自動化にエビデンス入ってねぇのかよ 客に出せるレポートなんか出んだろフツー エビデンスは手作業で取るもの。自動で撮って誰が確認するというんだ? 客はエビデンスがあることを見てるだけで内容までは確認しないものだぞ エビデンス撮った本人が、よくわからんが、まあバグっぽくない画面で動いてるからヨシ!ってやって やっとエビデンスの意味があるというものだろう ログが正しく動いてることを証明するエビデンスが必要 そのエビデンスが正しいことを証明するエビデンスが必要 さらにそのエビデンスが正しい・・・ >>357 ログはたんなる実行結果に過ぎないから正しく動く証明にはなることはないよ ログを正しく動く証明にするには方法は2つ 1. ログを取った担当者が、それをみて判断する 2. ログを取った人と別の人が担当者が、それをみて判断する どちらが判断するにしても、正しい答えを知らなければ正しく動くと証明することはできない だから上の方で言っていた正しい答えなんか事前にわかるわけ無いだろ!それっぽい値ならそれでいいだろ! なんてのは問題外なわけ。正しく動く証明をしてないわけだから スクショなんかも、取ったってそれみて後から検証なんかしないでしょ? 今からスクショみてバグが表示されてないか見ますなんてしないでしょ? あれは仕事サボってないかとかいう作業完了報告書だったり、なにか問題が 起きたときにちゃんとやったのかという責任追及をするための道具に過ぎないよ かろうじてバグがあったという証明ができるぐらい。正しく動く証明ではなくバグが有ったという証明ね まあつまりログとっただけでは何の証明にもならないって話 ログと正しい答えを目視で比較する vs コンピュータでログを自動的に比較する(それが自動テスト)の違いよ 人力で比較してりゃ時間もかかるしミスもある。何もいいことはないね ログって言葉が独り歩きしてるけど 基本的に自動テストって ・想定通り動いた=OK出力(グリーン) ・想定通り動いていない=NG出力(レッド) の2観点しかない 自動テストは結果判定もしてるから、実行だけ成功=OKには絶対にならん (そんなテストを実装してたらぶっ殺されるわ) で、自動テストのログが当てにならないっていう人って 無意識に以下のパターンを想定してるんだよね ・想定通りに動いて無いにも関わらず、OK出力(グリーン)が出ている可能性がある つまりテスト側の不具合を懸念して、それでバグを取りこぼす危険性を考えているわけだ 結論的に言うと、そういうのはテスト作り方の問題になるし 発生するとのは相当なレアケースになる というかこれが頻発してるなら、自動テスト組んだプログラマはクビにしろ 正しくOK/NGが判定できない自動テストならそりゃテストになってねえ 万が一、このレアケース発生しても修正をすればいいだけの話で、クリティカルな問題に発展する事はほぼ無い (むしろ人間によるチェックの方が、判定の曖昧さ、ミス隠し、スクショ偽造とか色々やってくるから個人的に信頼出来ん) >>361 ログ出力のテストって何? ログの話は「ログ見て人力で目視比較してそれっぽい値ならOK」ってやつでしょ ログに出力した後に人力比較があるんだよ >>363 ログ出力だって機能の一つなんだからテストするでしょ? ちゃんと指定通りのフォーマットで出てるかどうか? 日時、種別、内容などなどね しないの? するわけねえわwwwユーザと関係ないだろうがバカがwwwww 何のためのテストだよwwwwww 意味のないテストやって尺稼ぎしてんじゃねえぞ経営者目線で仕事しろ ユーザと関係ないところで一生懸命頑張っても誰も認めねえからな 売上に一ミリも寄与しないこと頑張ってどうするんだwwwwwwwww wwwwユーザから目をそらすために関係ないこと頑張ってるんだろwwwwww パソコンが好きなだけじゃ会社は成り立たねえんだよwwwwwwwww >>364 > ログ出力だって機能の一つなんだからテストするでしょ? わざとかもしれないけど(笑)話がすり替わってる ログ出力機能のテストの話じゃなくて ○○機能のテストをするとき、その機能の結果をログに出力して その出力を目視で人力比較してテストするのはアホという話をしてる 単体テストのテストコード書くほうが100倍アホだからwwwwww wwwwwwwそこんとこ忘れんといてよwwwwwwwwwwwwww 自動テストでも実行結果をログに出力できるわけで コンピュータで「比較」までやるか、人力で「比較」するか 誰が「比較」するのか?が違う所なんだよね なんかよくわからないところに噛み付いてるのでスルー これの話だからな 289 自分:デフォルトの名無しさん[sage] 投稿日:2020/09/26(土) 20:50:49.34 ID:c/9EiqGf [4/8] 単体テスト(自動テスト)で正しい値と比較 vs 目視確認でそれっぽい値かどうかチェック って話だったの忘れたのかな?w 291 返信:デフォルトの名無しさん[] 投稿日:2020/09/26(土) 20:52:18.62 ID:IgGP+BQU [29/30] >>289 結局最後に頼れるのは人間の目だからな 何のために目が付いてるか考えろ ログを見るためだろうが 関数の入力仕様と出力仕様が明確なら ログ出力関数のテストは簡単 でもログ出力関数を使う処理が正しくログ出力してるかどうかのテストはそう簡単ではない なぜならログ出力の正しさを判定するためにはログ出力以外の結果は正しいということが事前にわかってなければいけないから つまりログ出力だけでは処理の正しさを証明することは出来ない テストで「正しいと証明できる」という考え自体がある種の幻想 このスレ見てると一体どういう自動テストを実装してて どういうログを流してるのか本当に気になるわ そんな突き抜けバグ(不具合起きてるのに何故か正常終了扱いになってる状態)を抱えた自動テストばっかり使ってるの? 本当にどういう自動テストを想定してるのか分からん まさかログに値だけ出して、後でその値が正しいのか人間がチェックしてるのか? それ自動テストじゃなくて、ただの自動実行だよ テストっていうならグリーン/レッド判定まで実装してなきゃ使いもんにならん > 本当にどういう自動テストを想定してるのか分からん > まさかログに値だけ出して、後でその値が正しいのか人間がチェックしてるのか? ログに値だけだして〜って言ってる人は、自動テストしてないよ ログに値だけだして目視確認する手動テストでいいって言ってる なぜなら正しい結果がわからないから これ↓ね。こいつの言ってる意味がわからんと思うけど、意味不明だと俺も思うw 28 名前:デフォルトの名無しさん[sage] 投稿日:2020/09/23(水) 20:17:23.00 ID:cCwBtdaA [9/11] テストと言いつつできるのは計算過程と処理結果を残すだけだと思ってるよ俺は 長年考えた結果 正しい値なんてのは実は物理的に誰も知りえないということを理解した なのでテストで重視するのは俺は組んだコードのエビデンスの方 どんな処理書いてどんなログ出したか 自動テストは結局同じやつが作ってる以上同じ不具合入ってるだろうなって思ってるw そろそろレス古事記に構うのをやめようか… テストはバカだという証明はできるけど、いくら指摘しても修正しない限りバカはバカのままだし エビデンスとはテストを端折らずに実行しましたと言う証拠であって 動作の正しさやテスト手順の正しさを証明する証拠ではない エビデンスという名の作業ログ 自社開発ならエビデンスは要らんよ しょせん対外的な作業証明でしかないからな それよりテストコード、テスト可能なコードを書いてくれや 細かいことで揉めるから、 >>1 のような提案をする空気だけは読めるバカが出世して管理職になんだな。この業界は >>378 そのとおり バグっている場合は、そのバグの様子をスクショしてるだろうからバグがあるというエビデンスにはなるだろう しかしバグがないというエビデンスにはならない。これは自動テストでも同じだが、大きな違いは バグってないというスクショをとっても、正しくテストを実行したというエビデンスにはならないという点 スクショ取るだけではテストケースは書いてあっても、そのテストどおりにテストをしたという証拠にはならない 最終結果だけでなく一連の動作を動画で撮影してるならまだわかるが、間違って手順でテストしたかもしれない つまりエビデンスというのは(手順が間違ってるかもしれないけど)ちゃんと作業しましたという意味にしかならない どういう手順でテストを実行したかという記録が含まれていない 自動テストの場合は最終結果だけでなくどういう手順でテストを実行したかが記録されている。 必要なら再実行もできる。だからこれこそが本当のエビデンスになる。 スクショには正しい手順でテストを実行したかが記録されていないのだから 作業をしましたという報告でしかない。 バグのスクショは意味があるが、正しく動きましたというスクショは必要ない だからこれは本来この項目をテストOKでしたとチェックリストにチェックつけるだけで十分 チェックリストにOKでしたというチェックをつければ十分なことに スクショを必要とするのは、単に作業者の報告を信用してないという意味でしかない 単体テスト書いとけば改修しても自動で既存機能が壊れてないことが確認できる ゆえに機能の改修を心置きなくできる テストがないと気軽に既存機能に手を入れるわけにはいかなくなる (あたりまえ) 自動テストがないと手動テストをしないといけない それは膨大な作業量となる だからバグのないコードを書け、作ったら改修はするな!と叫ぶ バグがあったときのことまで考えてない 仕様に変更があったときのことまで考えてない 一旦書いたら終わりという前提でいるやつがいる そのほうがビジネスとしては美味しんだ テクニカルな面で優れた手法がビジネスでも優れた手法であるとは限らない >>385 単にビジネスが下手なだけだろ? 内部は楽をして、外部に対してこんなに頑張ってるんですよーってアピールすればいいだけ 外部に頑張りをアピールするために、実際に内部でも無駄に頑張る必要はない >>382 >バグのスクショは意味があるが、正しく動きましたというスクショは必要ない 正しく動いてたと思っていたものに後から不具合が見つかった場合 前回テスト時のスクショがあると調査が効率的にできる それは自動でも手動でも同じ >スクショを必要とするのは、単に作業者の報告を信用してないという意味でしかない 個人への信用に依存したシステムはミスがあれば個人を責めることになるのですぐブラック化する 典型的なマネジメント能力不足の例 > 正しく動いてたと思っていたものに後から不具合が見つかった場合 > 前回テスト時のスクショがあると調査が効率的にできる 不具合があると既に分かった後の話ですよね? スクショがあると、どう効率的に調査できるんですか? >>387 > 個人への信用に依存したシステムはミスがあれば個人を責めることになるのですぐブラック化する だから自動テストでコードにするんですよね。他の人がテスト内容をレビューできるように スクショだと、実際どういう手順でテストしたのかが記録されてないから ちゃんとテストしてないだろ!って個人を責めることにつながる 手動テストで問題なのが、前やったときのテストと完全に同じ状態が作れないということ 作業の順番でも状態が変わってくるから前後にやったテストによって成功したり失敗したりする だから改めて同じと思った手順でテストしたら失敗することがある スクショを取っていても「お前この前ちゃんとやってなかっただろ!」と責められる >>388 自分で考えて >>389 自動か手動かには関係ない 自動化したUIテストでスクショ取らないのかな? >>391 UIテストってわざわざ書いたってことは それ以外には当てはまらないって自覚してるのかなw 自動化したUIのテストでスクショを撮るというのはおかしな表現で "テスト"を自動化していれば、当然自動的にテストされるわけよ スクショはいらない >>391 が言ってることのほんとうの意味は UIのスクショを自動で撮っているだけで UIのテストは人が目で見てやってる手動テストだろう? それとも違うんか? UIのテストを人が目で見ず本当に自動化してるんか? でもいい感じにお高いツールはUIテスト時のスクショも自動で撮ってくれるからねw ないからっていらないやいって悔し涙流さなくていいぜ 別に高くなくても取ってくれるやろw 論点はそこじゃない 取った後どうするのかだろ 高いツール使ってるんだぜ悔しいだろ みたいな意味かな? >>395 撮ったあとどうするもこうするもお高いツールはクリックすればすぐ見れるんだよ 手動でエクセルに貼る作業とかないから ただ・・・ (実はあんまり手間減らないんだけどな) 自動化は人間が楽をするために自動化してるだけなんだからログでもスクショでも何でも良いけど、テスト結果がグリーンであってもエビデンスは人間の目で検証しないとダメだよ。自動化の利点は、手動テストやってる要員や係るリソースを他のことに回せるってだけ。 自動テストがプログラマの自己満と言われる所以はテストパターンを無限に作成できるからだよ。sumAtoFで引数を6個取るなら0,0,0,0,0,0から9,9,9,9,9,9の範囲や、マイナス値とか小数点とかnull値を含めていくらでもテストパターンが作れる。しかも再実施も簡単。手動テストじゃそうはいかないからね。 >>400 手動テストでもテストパターンは無限に作れると思うが?w >>399 > テスト結果がグリーンであってもエビデンスは人間の目で検証しないとダメだよ。 え?なんで?愛情がどうとかどうでもいい話だよw >>399 あ、初めて自動化したときだけエビデンスの検証してねってこと。次の改修では追加・変更したテストパターンのエビデンスを検証する。それ以外の既存のテストパターンは結果がグリーンであればそれでデグレとしての証明は担保できてると思うよ >>403 PGした人がテストパターンも作ってたら同じ不具合が混入する可能性があるでしょ >>402 手動テストでも無限に作れるけど人海戦術しないとテストしきれないでしょ。テストの規模とプロジェクトによってはそんなの現実的じゃない。だから自動化のが簡単。 >>400 >自動テストがプログラマの自己満と言われる所以はテストパターンを無限に作成できるからだよ。sumAtoFで引数を6個取るなら0,0,0,0,0,0から9,9,9,9,9,9の範囲や、マイナス値とか小数点とかnull値を含めていくらでもテストパターンが作れる。しかも再実施も簡単。手動テストじゃそうはいかないからね。 流石にテストパターンの洗い出しすら考えないのは頭おかしいやろ 自動テストの実装コストもタダじゃないし というか不要なテストパターン(重複してるテストパターン)は消すぞ普通…… というかテスト自動化で無限にテストが出来るって思ってる奴もいるのかよおおおもう あれだな、デジタル庁も作られるんだし 品質管理の観点として、テストに関してちゃんとガイドラインと共通規格決めてくれ 頭痛くなってきた >>408 理論上は可能だよねって話をしただけだよ。現場ではそんな無意味なテストしてないから発狂しないでよw テストパターン考えるときに大丈夫だとは分かっていても不安だから盛り込むパターンも少しくらいはあるよねってこと。人間だもん。ちょっと多めにテストして安心したいよね。 無限に作るとか、藻舞ら、境界値テストを知らんのか?w 例えば、正常範囲を10〜20 と決めたら、論理的に、9, 10, 20, 21 だけでOK のはずw -1, 0 も、9と同じ。 11, 19 も、10, 20 と同じ 100 も、21 と同じ こういうのを論理的思考と言う。 どれとどれが、同じグループですか? と言う問題 >>405 > PGした人がテストパターンも作ってたら同じ不具合が混入する可能性があるでしょ え?なんで?w テストパターンってお前コードから生成すんのか? そもそも最初に、入力決めて、出力決めて、 そうなるように作るというのに意味がわからん >>410 そうやって自動テストでもテストする値を決めるよね 無限に自動テストできるわけじゃないんだからさぁw >>411 テストパターンを基にテストコードを書くよ。 最初に入力を決めて次に出力を決めてそうなるようにテストコードを書くよ。 テストを実行したら全部グリーンでもテストコードのコーレビューをするよ。 >>413 > テストパターンを基にテストコードを書くよ。 そのテストパターンが間違っていたらどうするんだ! まあそういう事はあるよねw テストそのものが間違ってるってこと でもPGがテストパターンを作ると間違えるってのが意味がわからない PGが作ってもPG以外が作っても、テストパターンを間違える可能性は変わらない > テストを実行したら全部グリーンでもテストコードのコーレビューをするよ。 手動テストの場合どうするんだろうね。テストコードに相当するのはテスト手順なわけで テスト手順もレビューも必要なんだが、手動テストだとテストパターンのレビューしかしてなさそうw テストパターンはあってるけどテスト手順が間違っていて意味のないテストをしてたりしてな テストするときは先にデータを初期化して、この手順でデータ作ってからやらないとだめじゃないですか!みたいな >>413 > 最初に入力を決めて次に出力を決めてそうなるようにテストコードを書くよ。 ここは言葉が間違ってるね × 入力を決めて次に出力を決めてそうなるようにテストコードを書くよ。 ○ 入力を与えて出力が決めたとおりになってるかを確認するテストコードを書くよ TDDではそのあとに、テストに通るように実装コードを書く >>410 9.9999999999999999や20.000000000000001は? 境界値分析+同値分割は基本だけど 型の境界も意識しないとそのうちバグるよ >>414 >PGが作ってもPG以外が作っても、テストパターンを間違える可能性は変わらない コードを書いた人とそれに対するテストコードを書いた人が同じなら 同じ勘違いや同じ観点不足が発生するリスクは高まるよ 例えば>>410 が書いた例で整数値以外の入力という観点が欠落してれば コードでもその対応を書かないしテストの必要性にも考えが及ばない ただだからといって必ず違う人が書いたほうがいいというわけじゃない 低減できるリスクと作業効率とを考えて判断するもの >>414 ・PG組んだ人が一番思い込みが強いから、もしかしたら他の有識者と認識が乖離しているかもしれない。まぁレビュアがしっかりしてれば大丈夫。 ・手動テストの場合は、テスト条件を満たしていることが担保できるようなスクショを取得するよ。テスト条件どおりに実施してくれたかどうかは実施者を信用するしかないね。エビデンスに細工されたら誰も気づかないと思う。 ちゃんと実施してるつもりでも実際は細かい操作とか大事な操作をミスっちゃってて、それでもたまたま予想結果と一致しちゃう事もあるかもしれない。だけどそんな偶然は滅多に起きない。後でアドホックテストもするし、結合試験や統合試験で発見できればok。 ・エビデンスとテスト手順とパターンを見比べて「これは何のテストをなんだ?」って思うことは稀によくあるね。 ・手動テストでテストデータが必要な場合は事前準備としてそういうデータを用意してからテスト開始するよ。 >>417 > 例えば>>410 が書いた例で整数値以外の入力という観点が欠落してれば > コードでもその対応を書かないしテストの必要性にも考えが及ばない だからそれ、コード書かない人でも 整数値以外の入力という観点が欠落することあるじゃんって言ってる むしろコードを書かない人のほうが、テストの必要性に考えが呼ばないことのほうが多い 「数値入れたらこういう計算してくださいね」 → 文字入れたら?え?文字入れた時?文字なんて入るの?そんなの想定外だよ set○○○系の値を設定するだけのメソッドってあるじゃん ケース1:resultがOKならOKとする ケース2:get○○○系メソッドを実行して値を確認する ケース3:実際にその値の変更の影響をうける処理を実行して確認する 実はもう結合まで来てんだけどどうやって確認する? あ、やってみたらget○○○系もよくわかんなかった 値取得できたけどそれが何? 何が取れると正しいの?ってのが一連の処理の流れだと取得できるべき正しい値が本気でわからん >>421 > 実はもう結合まで来てんだけどどうやって確認する? 確認する前に結合したのが悪いって話だろ? もうリリースしちゃったんだけどどうやってテストする?みたいな話だw >>422 > 値取得できたけどそれが何? 「値取得できた」 それがテスト (手動で)テストしてOKだったから何?と言われてもな 意味ないと思うなら(手動で)テストしないでいいんじゃない?w >>422 > 何が取れると正しいの? そんなに作る前からわかってる話ですよね? 作ってるなら「目的」があるはずですが あなたは一体何を作ってるんですか? あ、あれか。教科書写経してるだけだから 自分が何を作ってるかわからないとか んで作ってみて動かしたら・・・ゲームだった!みたいな事やってんの?w コンパイラ作ってるんだが、検査は自動でランダム構文生成とかしてやってるよ もちろん普通の検査もやるんだけど、それだけだとパターン数が発散して検査しきれない ランダム検査はテスト件数でいうと1000億件とかになる 不具合でるのはそのうち5件とかだったりするんだけどね >>427 だからそれを手動でやればいいんですよ! 自動化する単体テスト=関数単位のテスト エビデンスをとる単体テスト=1個の機能のテスト。例えば入力欄1個など > エビデンスをとる単体テスト=1個の機能のテスト。例えば入力欄1個など その"エビデンス"でどうやって入力欄1個の機能がOKだと証明するの? 入力欄1個の機能がOKであると、誰もが認られるようなエビデンスとはどんなものが知りたい そこに入力欄の画像が1個あったって、機能が満たされてるかなんてわからんしね >>430 機能がOKだと証明するわけではない 「テスト項目の通り実行したらこの通りの画面になった」 つまり、テストを行ったという事を証明しているにすぎない だから入力ミスや、テスト実行者の勘違いまではフォローしきれない 機能の証明ではなくテスト実行の証明だから わざわざエビデンスに日時が入るように撮影することを要件としている 機能がOKだという証明だけであれば日時は不要だろう 実際、自動テストはテスト実行日時など重視していないはずだ (デバッグの為に日時を保存しているにすぎない) エビデンスに日時を入れるという行為があるかどうか それだけでもテストの性格がわかるというものだ テスト実行者を信用しないのであれば自動テストで十分だろう 自己満だろうがなんだろうが顧客が納得すりゃなんでも良い >>431 > テスト実行者を信用しないのであれば 気にすべき所はテスト実行者を信用するかどうかじゃなくて ミスなくテストしたかどうかでは? 信用できる人にだって間違えることはあるんだし 画面にせっせと入力して保存ボタン データベースに登録されてるかチェック 苦しい_(┐「ε:)_ >エビデンスに日時が入るように撮影することを要件としている 初めて聞いたわw 日付入れたところで改ざん可能なんだから日単位でファイルを上げて 履歴追えるようにしとけば十分だろ >>436 ログの位置がわかりやすいようにってだけだろそこ xUnit嫌いな人割と身近にいるわ 単体テストしない派というか >>438 仕様が決まってるテストはいいが決まっていなかったり曖昧なのは滅茶苦茶時間がかかるので嫌い テスターが仕様決めるって意味わからんw この関数は引数の全ての値を足す関数だ って決めるんか?w 俺は常に自分でテストコードを書きながら仕事をしているから、いまいち単体テスト専用のテスターという存在がよくわからん。 新人教育目的で自分の成果物に対して不足しているテストコードを修正する形で書かせることはあるけど、基本的には実装する時にはテスト仕様もできてるしなぁ...。 >>444 用語を知らないから、単体テスト=1画面のテストとか1アプリのテスト思ってるやつが居るんだよw 単体のexeファイルをテストするのが単体テスト はぁ〜〜〜〜ばか〜〜〜 小さい関数を心がければテストコードが必要なほど複雑なコードって書かなくない? テストコードを書くと必ずデータ用意しなきゃならないけどそのデータを間違って入力する確率のほうが高い >>445 俺さ、まさにリアルタイムでスマホアプリ開発しててテストコードを書いてるんだけど、お前、頭大丈夫? iOS、android、Windows対応のアプリ作ってるけど、こんなこと言う奴初めてみたよ。 JavaとかでJUnitとか聞いたことない? C#でプロジェクトファイルを作るとき、Unit testというテンプレート見たことない? お前、Windows開発すらしたことないだろ。 俺は別に1画面がどうのこうの言ってないし、そもそもexe単体とか論外だわ。 まず、単体テストについてググれカス。 >>447 日本語圏内で言う単位テストは普通は画面、帳票、バッチ、ようは要件定義に書いた機能ごとのテストだよ xUnitとかJUnitのようなもののことを言いたい場合には、ユニットテスト、あるいは自動テストと言ったほうがいい 日本ではユニットテスト≠単位テスト 1からのやり取りを見てもそんなこと言えるの? あと、ググるとまっさきに出るのが「単体(ユニットテスト)とは」なのだが。 そして、俺もその認識なのだが。 >>447 おまえは文章が読めないんだなw おまえも馬鹿の一人だわw >>446 どれだけ小さい関数を作っても、テスト担当者にテスト仕様書を書いてもらないわないと 自分じゃ、テストできないアホがいる。 ログに出力してそれっぽい値ならOKとかいってるアホがいる >>450 そういうことか! うん、俺も馬鹿だったわ。 いや、本当にすまぬ...すまぬ。 ん?割とガチで単体テストを機能毎のテストとして扱う会社は多いのか? 基本情報技術者試験や応用情報技術者試験の単体テストに関わる問題とか見ると、明らかにユニットテストの意味の問題があるように見えるのだが...。 そうなると、自動化もクソも無くね? それ以前に、>>448 の言うことは本当なのか気になる。 本当なら>>448 の言う単体テストについて紹介している文献とかあると思うのだが...ソースがほしい。 >>454 大企業で仕事したらわかるよ だからエビデンス取るんやで >>455 まず、ユニットテストと単体テストを区別するというのが本当なのか怪しいが、区別しているのなら、もちろん、そのユニットテストもやってるよね? 更に聞くと、このスレはあなたが方の言う単体テストとユニットテスト...どっちについて扱うスレだと思う? テストの分類と自動化するしなは別のベクトルだ 単体テストといったら自動化と連想するのはそのあたりの区別がついてないのだろうな 役割の分割をしないでGODクラス作ってそうなタイプ >>457 手動で行ってエビデンス取るって言ってるんだからユニットテストでないことは明らかだと思う このスレでユニットテストの話をしてる人は社会経験のない木偶の坊だと思ってる まぁ、責務が曖昧なGodクラスのユニットテストなんて自動化しようがないからな。 些細な変更ですぐに仕様が変わるし。 ユニットテストで不合格になるのではなく、 ユニットテストができないから不合格になるパターンだな。 でも、恐ろしい事を思いついてしまったよ。 もしも、常に神クラスを書いていてユニットテストができない企業がいたとする。 そして、その企業があまりにもユニットテストができないからユニットテストの意味を曲解することにしていたとしたら...やばいね。 まぁ、いいや。仕事だ。しばらく席を離れるよ。 >>454 > 基本情報技術者試験や応用情報技術者試験の単体テストに関わる問題とか見ると、明らかにユニットテストの意味の問題があるように見えるのだが...。 だからそういう世間一般の用語すら知らんのだよ そして基本情報技術者試験は意味がないとか行ってたりするw ペーパーテストと現場のギャップぐらいは認識しとかないとだめでしょ それこそ実務経験を疑われる 世間的には現場の定義が優先されるからなー 試験勉強でこう習いましたなんて現場では通用せんぞ ヤクザにそれは法律違反ですと言っても意味ないだろ 警察に金庫から8000万盗めば良いと言っても通用しないだろ 社会とは現場が常に優先されるものなんだよ 鳥はお空を飛びますと本に書いてあったとしても ペンギンは鳥だから空を飛べば良いと言ってもペンギンの現場では通用しないんです >>467 現場の定義の殆どは試験勉強の定義と一致してるんだが? 違うのは現場ではベンダー定義の用語が追加で使われるぐらいのもん 試験の定義を否定するようなものはない だから今、試験での単体テストの定義と現場が違ってる= え?お前の会社って単体テストって画面のテストのこと言ってのプププ って話をしてるんだろw >>448 何を「単体」と見なすかに違いがあるだけ 面接でユニットテストは単体テストとは全然違います!ってずっと主張してたやつがいたけど その文化を共有してない会社だと単にヤバいやつ認定されるだけだからやめたほうがいい あいつマジで理想郷にでも住んでるのか? わかってて煽ってるのかと思ってたけど・・・ 単体テストと言われてxUnitのテストの結果なんてもっていったら 上位会社様にバカにされるぞ バカにされる程度で済めばいいけど他の人に代えてくれってすぐ営業に電話されるよ 商流の末端企業は上位会社様にあわせるしかないんだよ 現場のベテラン「情報処理技術者試験なんて意味がない」 おまえら「↑みたいな奴がいるから情報処理技術者試験がもっと普及したほうがいい」 現場のベテラン「現場が正。↑は経験積め。やはり情報処理技術者試験は意味がない」 このループが無限に続くだけ 無限ループって怖いね IPAのいう単体テストがユニットテストのことだからな これが違っていたら、もう常識がわかってないとしか言えないw >>472 どこの現場のベテランがいってんの?w 現場のベテランというか、ちゃんと情報技術を学んでいる人は 単体テスト=ユニットテストになってる 英語と日本語の違いでしかないからね 上流なのな下流のチェックしない会社とかどこの没落企業だよ。気持ち悪い。 国家資格すら取れない三流エンジニアは言うことが違いますね。 国家資格なんておやつ感覚で取るもの。なんで国家資格ごときで必死なんだ。 基本情報技術者試験くらい取れよ。そうすれば単体テストとユニットテストは違うなんて恥ずかしいことは言わなくなるから。 あ、これ大企業の話な。 大企業の話を妄想で持ち出す馬鹿がいるから警告しとくわ。 あと、権威主義に陥るのやめろ。 ふむ。さすが正しいことを言ってるな https://www.fe-siken.com/kakomon/16_aki/q53.html モジュール単体テストに関する記述として,最も適切なものはどれか。 単体テストは、プログラムがモジュール単位で正常に動作するかを確かめるテスト工程です。 プログラムの内部設計書に基づいてホワイトボックステストを実施し、要求性能を満たしているかの確認を行います。 間違い 通常はコーディングを行ったプログラマではなく,専任のテスト要員がテストケースを作成し,実行する。 →正解 単体テストは、コーディングを行ったプログラマ自身が実施します。 間違い モジュール間インタフェースは,モジュール単体ではテストできないので,単体テストの対象外となる。 → 正解 実際にモジュールの結合を行うのは結合テストですが、モジュール仕様書に記述されたインタフェースが適切に実装されているかの検証は単体テストの対象です。 間違い モジュール設計書は,正しいことが検証済みであるので,テスト結果に問題があるときは,テストケース又はモジュールに誤りがある。 → 正解 モジュール設計書が誤っている可能性もあります。 正しい モジュール設計書を見ながら,原則としてすべてのロジックパスを一度は通るようなテストケースによって,検証を行う。 → 正しい。単体テストでは、プログラムの内部構造に基づいて、内部仕様がモジュール仕様書通りに作成されているかを検証します。 >>476 気にしすぎでしょwww大企業ですまんなwwwww >>470 良いこと言うね! 自然言語は文脈依存だから同じ語句であっても文脈に応じて意味が変わるからね それを理解せずに自分の定義でしか言葉を解釈しない人はコミュニケーション能力が不足してるってことになるよね IPAって経産省の手先団体だろ、なんでそんなところを頼ってるんだwww 職員がお仕事中に児童ポルノダウンロードしてウイルス感染したところじゃねえかwwwww wwwwお前らwwwwwマジかwwwwww >>480 文脈を明らかにしろ。どの会社での話なのか、世間一般の話なのかはっきり区別しろ 俺は世間一般の定義の話をしている それ以外なら特定の会社名を言うようにw >>478 >要求性能を満たしているかの確認を行います。 ここでの「要求性能」ってどういう意味? 間違いじゃなくて一般的な使われ方? >>484 文脈を察しろ常に俺が正しいと考えていただきたい 俺が言ってることが正しくなるように解釈することを心がければ 俺の文脈を知ることができます、俺が中心です 児童ポルノウイルス団体を頼りにするとはwwwww お前らも所詮経産省の掌の上で弄ばれてるだけかwwwww >>485 性能は性質と能力のことなので ・要求される性質がありますか ・要求される能力がありますか ってことを確認するってことじゃろう 一般的に伝わると考えて差し支えない >>485 「プログラムの内部設計書に基づいてホワイトボックステストを実施し」と書いてあるだろ >>485 単体テストは内部設計におけるテストだから、内部設計がある程度まともかどうかって意味では。 そのある程度のラインはテスト仕様次第だが。 プログラムの内部設計書に基づいてテストするんだから プログラムの内部設計書に書いてあることが要求 ○○に基づいてテストを実施すると書いてあるわけで そこで○○に書いてないことを確認するわけがないのは当たり前の話 それはそう 「満たしている」の主語は「プログラムが」 テストの確認を行うのはテストレビューだからね 単体テストの説明としてふさわしくない >>492 内部設計がある程度まともかどうかをどうやってテストするのかわからないけど それって単体テストとは一般的には呼ばなくない? >>493 ひっかかるのは「要求」じゃなく「性能」のほう 時間効率・資源効率的ないわゆるパフォーマンスの意味ではなさそうだし 機能+非機能要求全部込みの「性質+能力」の意味だとすると単体の範囲を超える それにホワイトボックスでもなくなる >>495 テストレビューは、テストが妥当かどうかは判断するレビューであって プログラムの内部設計に基づいたテストのことじゃない プログラムの内部設計に基づいたテスト・・・になってるかどうかを判断するのがテストレビュー >>496 > ひっかかるのは「要求」じゃなく「性能」のほう 内部設計にパフォーマンスが書いてあれば そのとおりかテストするのも単体テスト 訂正 内部設計に性能が書いてあれば そのとおりかテストするのも単体テスト 正しく動いていても、性能を満たしていない例なんて いくらでもある。遅い。メモリ消費量が多い >>496 > 内部設計がある程度まともかどうかをどうやってテストするのかわからないけど > それって単体テストとは一般的には呼ばなくない? 内部設計をテストするのが単体テストなんだけど。逆に、何をテストするものだと思っているんだ? >>478 の基本情報技術者試験の解説にコーディングを行ったプログラマ自身がテストしますって書いてあるでしょう? 単体テストをやったことある人なら、これを見たときにピンとくる。 というか、具体例を考えればいいんだよ。 Stackというコンテナライブラリを貴方が作ったとして、そのStackライブラリが絶対大丈夫であることを保証するためには何をする?って話。 画面、ウェブ業界なら1ページ これより小さい単位を知らんでしょう 関数を自分で作ることをしない ボタンをクリックとかしたらフレームワークが 関数を呼び出すから、その関数の中身を書くだけ その結果は画面に表示されるから どうやってテストするのかわからない 見て判断するしかないじゃないか! と言っている webかー。 そもそも、それ、単体テストではなくUIテストでは? 誤って送信してしまった... UIテストって言葉は俺らローカルかもしれないのに...。まぁ、言い訳を考えさせてくれ。 >>502 UIテストだからエビデンス(スクショ)でテスト とかいうわけのわからない理屈が出てくるw スクショ見て、よくわからんけどちゃんと動いてるっぽいなヨシッ! これがテストw >>498 「プログラムの内部設計書に基づいてホワイトボックステストを実施し、要求性能を満たしているかの確認を行います。」 パフォーマンスの性能のことだとすれば、性能以外は確認しない感じの文章になる 普通に間違いっぽいね >>505 > パフォーマンスの性能のことだとすれば、性能以外は確認しない感じの文章になる お前が言ってる性能以外とは? まずそれを言わないと、お前の文章に説得力はないよね 説得力と言うよりか、議論の対象にすらならないと言うべきか 基本的にWeb開発と同じくネイティブアプリ開発者もUIは作る。それがHTMLではないだけで、成果物の全体を見ると同じ。 ネイティブアプリ(iOS,android,Windows)を作るとき、必ずやるのがロジックとUIの分離。 UIにUIが使いまわし出来なくなるような処理を書かないようにするのが原則で、基本的にはUIと切り離れたロジックの部分を単体テストする。 ...で、ここからが問題で、じゃあ、UIはどうやってテストするの?って話か...。 俺はこれを別工程として扱っているけど、その解釈が一般的かと言われると...うーん。 そして、webフロントエンドはロジックを記述すること自体殆ど無いからな...。webフロントエンドは殺風景なhtmlが組める程度のニワカ知識しかないが...。 ちなみに、自分はUI専用のテストコードを書いてそこだけ手作業でやってるわ...。 合否判定は自動的に出力するようにしてるけど。 で、それをwebでどうやるのかだと?ごめん、わからん。 > ...で、ここからが問題で、じゃあ、UIはどうやってテストするの?って話か...。 いや、そんな話してないw 単体テストの話をしてるのに、エビデンス?手動?スクショがテスト??? アホじゃねwwwって話をしてる マジレスすると自動で行う単体テストだってエビデンスの為にスクショ取るし 自動でやるのが非効率なら手動の場合もあるよね xUnitテストの結果をエクセルに貼り付けるのもいいけど やっぱ信用性を考えるとスクショのほうがテンション高い > エビデンスの為にスクショ取るし テストのためにスクショ取る じゃないところが重要な点だなw 結局の所、ただの作業報告書でしかない > xUnitテストの結果をエクセルに貼り付けるのもいいけど え?なんのために? 標準のXMLでいいだろ ああ、作業報告書ね(苦笑) とこうなる どことは言わないが、未だにテスト結果をすべて印刷してスタンプラリーしてバインダーに格納してる大手電機メーカーがあるんだよ。 その時にXMLじゃ分からないって押印してくれなかったり。 まぁ、スクショ貼る会社はあると思う。 お役所と仕事していると面倒な完成図書(紙媒体)も求められるし。 こんなテスト結果、あなた達が貰ってどうするの?って奴まで求められるし。でも、まぁ、彼らにとっては意味があるから仕方ないね。 ただ、誰もエビデンスを求めていないのにマニュアルに従いやれって言われると少し残念な気分になる。 利害関係者次第だな。 >>515 いやそれも含めてテスト工程。 他にそれを含められる工程がない。 >>514 それ間違っていても絶対分からないから 手抜きし放題になるのでは >>516 じゃあお前の所は納品作業は何工程になるの? まともにプロセス定義していれば、 受注プロセス→開発プロセス→納入プロセス であって、 開発プロセスの中が設計だの製造だのテストといった工程定義が されているはず。 そんなことも知らないというのは、かなりまずい。 テスト結果を納入する作業は テスト工程なんですよとか言いそうだよなw >>469 だから現場を知ってからそういうこといいなよ でかい案件ではどこもほとんど確実に単体テスト≒画面のテストだよ メソッド単位で単位テストなんて言い張ってたらいつまでたっても終わらない プロジェクトをすすめるには画面を単位と言うしかない ちっぽけな案件だったら教科書的な定義にしたがって優等生気取りながら仕事することもできるけどな > でかい案件ではどこもほとんど確実に単体テスト≒画面のテストだよ そういわれても検証できないんで、 でかいオープンソースプロジェクトの話でもしてくれませんかね? 狭い世界の話をされてこ困ります。 オープンソースwwww 日本の大規模案件でオープンソースなんて激レアだろ そんなの見たってなんの参考にもならん 現場を知りたけりゃ現場に潜り込む それしかねえんだよ >>519 おいおい それでいくと納入プロセスまで客は何も目にしない事になるぞ? > 日本の大規模案件でオープンソースなんて激レアだろ じゃあ小規模案件でもいいですが 今の論点は、狭い世界かどうかの話ですよ? 広い世界の話をしなきゃ意味がないでしょうw 単体テストって言葉を作った大手がそもそも単体テスト=画面テストで使ってるという皮肉な現状がね >>524 請負ってそういうものだよ。 みたけりゃ中間納品でも設定すればいいだけ。 現実にはそんな法定義に杓子定規に運用してたらリスクしかないから どこも工程完了基準みたいなのを設けて移行判定を顧客に委ねたりしてるでしょ。 >>526 大手が日本の会社だと思ってる? https://employment.en-japan.com/engineerhub/entry/2019/10/03/103000 「単体テスト」という言葉が初めて世に出てくるのは、 1970年の『Managing the Development of Large Software Systems』という論文に遡ります1。 >>526 今までの話を聞いてた? 単体テスト=画面のテストは違うだろ。 そもそも単体テストの意味を盛大に勘違いしているのは君だけでしょ。 国家資格の基本情報技術者試験の件はどう反論するんだ? >>511 小保方さんは研究ノートをろくに取ってなかったから批判されたんやで そこんとこよーく考えた方がお前のため >>528 なんで英語論文に単体テストって日本語が出てくんだ? いいかげん単体テストとUnit Testを区別したらどうだ ここは日本だから日本の習慣に習うべきだ >>530 国家資格は児童ポルノウイルス試験でしか無いってことだと思います! >>532 Unitは単体って意味なんよ Unitを日本語で書くと単体なの 英語勉強して >>532 ユニットテストを翻訳したものが単体テストです それ以外の定義はありません TDDはアスペ用のものだしなー 健康な人が水素吸入しても健康にならないようなもので まともなプログラマにUnit Testは要らんのですわ 英語にびびったアホジャップがUnit Testはスゴイものだと思い込んだだけで 実際のところUnit Testやってもやらなくてもシステムの品質は変わらんから コストかかるぶんマイナスなんよねー >>535 そうでもないやで 大企業で仕事してみ、単体テストはintergration testingの意味ですから Unit Test -> 単体テスト これはわかる 単体テスト -> Unit Test これは成り立たない >>537 大企業が間違ってることぐらい知ってますよ(笑) 会社がでかいだけで、ソフトウェア開発の専門じゃないですからね 大規模の意味はソフトウェアの規模が大きいんじゃなくて 単に作業員が多いだけだったりするしwwww マイクロソフトは世界最大規模のソフトウェア会社の 1つだって言っても納得しないでしょ? >>532 国家資格である基本情報技術者試験は日本の風習から乖離していると。 そんな馬鹿な。 むしろ、単体テストという言葉がUnit testと乖離している日本独自の風習があるのなら、参考文献を貼り付けてくれないかな。 調べても単体テスト=ユニットテストの解釈での説明しか出てこないのだが。 あと、一部、共有NGであぼーんされている人がいるけど、その人の回答ではなく貴方の意見が知りたいな。 >>538 > 単体テスト -> Unit Test > これは成り立たない おまえん中ではなwww >>539 おいおいお前、一部上場の前でなんてこと言うんだ >>542 もしかし会社がでかいと、ソフトウェア専門会社だとおもっちゃった口ですか?w >>541 俺 = 一部上場のITゼネコン大企業 一部上場のITゼネコン大企業 = 日本のIT よって俺の常識は日本ITの常識 >>544 え? どういう意味? ちょっと何いってんのかわからない >>547 日本は広いよ、日本語話者の国全域に及んでますからね ここは日本だ、日本の常識で話しをしよう、単体テストとはIntergration Testingのことなり! Intergration Testingだからエビデンスを取るわけ Unit Testでエビデンス取るわけ無いだろwww常識で考えろよwwww スレタイ見て出直せよwwwwwwなんでUnit Testなんだよあれは認知障害者が使うもの 自分で 一部上場のITゼネコン大企業特有の話とか言っておいて 日本の常識にすり替えるなよ 基本情報技術者試験の方がよっぽど日本の常識だ >>549 × Intergration Testingだからエビデンスを取るわけ ○ テスト作業を行ったいう証拠を提出しないといけないから、テストしたというエビデンスを取るわけ ちゃんと書こうね >>550 >>545 でこれ以上なくはっきりと論理展開してみせましたけど 基本情報とか噴飯ものだわwwwwwwペドロリの資格とって経産省に認められてどうするんだwwwwwwww すまんな俺は環境省の味方だから俺は環境省の味方です >>551 同じことですよ、相互に排他的な事柄ではないです 研究者が研究を行った証拠を示すのが研究ノートのみであるように プログラマがテストを行った証拠もやはりエビデンスのみなわけです エビちゃん大事 >>552 論理展開じゃなくて単なる主張w それが「論理展開」だっていうのなら、これも成り立つ お前 = 一部上場のITゼネコン大企業 一部上場のITゼネコン大企業 ≠ 日本のIT よってお前の常識は日本ITの常識ではない >>534 直訳すりゃいいってもんじゃない とくにテクニカルタームはそう >>553 > 研究者が研究を行った証拠を示すのが研究ノートのみであるように 研究ノートは他の人がそれだけをみて再現できることが条件です その条件を満たしてないから小保方のやつは研究ノートとは認められなかったわけです。 >>554 > 一部上場のITゼネコン大企業 ≠ 日本のIT ここが間違ってるので成り立たないのは明らかですよん 日本のITを仕切ってるからゼネコンと呼ばれるわけ ゼネコンの意味を調べたが良い、ゼネコンはすごいんだぞ >>556 じゃあなんですか!? 超訳しろとでも言うんですか? 小保方氏ようやく「実験ノート」公開するも… 専門家「理科の観察日誌?」「ものすごい破壊力」 https://www.j-cast.com/2014/05/08204189.html > 理化学研究所の小保方晴子氏が記した実験ノートの一部が、代理人弁護士らによって2014年5月7日、 > 公開された。小保方氏は「ちゃんと実験していることを示したい」として公開に踏み切ったと報じられている。 > > ところが、具体的な実験条件などが不足した内容に、研究者や識者からは疑問の声が噴出している。 > > 「陽性かくにん!よかった。」 まさにエビデンスそのものw 「テストOKだった。よかった。」 >>559 UnitTestを正確に表現する日本語は今のところ、無い UnitTestはUnitTestと言うしかない 単体テストと言ったらUnitTestとは別の意味になる >>557 再現するための手順はプロトコル・・・ 研究ノートは研究を行ったエビデンスなんよ エビがいい加減だったからよろしくなかったのは事実だけどね >>558 > ここが間違ってるので成り立たないのは明らかですよん 間違ってないですよ これがお前の言う「論理展開」ですからね。 それともお前自身の「論理展開」に根拠が書かれてないってことに気づきましたかね?w > 研究ノートは研究を行ったエビデンスなんよ 今日は研究をした。陽性確認した。良かった。研究ちゃんとした。エビデンス。 >>560 せやろ、エビデンスを軽視するものには天の裁きがくだされるわけではないけれども エビデンス大事だよねってことですよね >>565 エビデンスが大事って? 大事なのはソフトウェアが正しく動くことだろ >>528 海外を参考に「単体テスト」って言葉を作ったんだよ 外国人が「タンタイテストゥ」とか言ってるわけないでしょ、アホかw 国内大手ベンダーが先行してIPAが後追いで追認してきたのが今までの歴史でしょ >>530 ソフ開持ちなので試験に出てくる意味での単体テストは完全に把握してるぞ あれはあれ、これはこれ >>561 別の意味ってどういう意味なんですか? にんじんを野菜と言っても良いようにUnit Testはテストと言っていいし単体テストと言って問題ないでしょう やってることだけ見れば認知テストとかでも良いかもしれないですね >>567 ____ / \ / ─ ─\ / ⌒ ⌒ \ ハハッワロス | ,ノ(、_, )ヽ | \ トェェェイ / / _ ヽニソ, く エビデンス=納品物 ソフトウェアが正しく動く事=納品物ではない どっちが大事かは明らか >>570 ほらみんな、この程度のレベルだって分かったろ?w >>572 どっかの大会社はスクショをの納品して 動くソフトウェアを納品ないらしいねw しかしマジでエビデンスを納品して ソフトウェアを納品しない会社があるとはねw 顧客が本当に欲しかったものはエビデンスだったんですよー このスレでもソースは? 文献は? ってしきりに聞く人がいるでしょ エビデンスっていうのは万人に共通する価値基準でありアイデンティティの強化する アイテムとしてやはりIT業界の顧客にはそういう人があれですねー Unit Testがプログラマの自己満足であるのに対して Integration Testは顧客満足なんです プロダクトとしてどちらを重視すべきかは明らかですね >>568 む。そうか。 NGが働く前に変なやつのレスを見たからミスリードしたかな。 納品日に持っていくのは大量に印刷したエビデンス そしてマニュアル あと仕様書だか設計書だかそんな感じのタイトルも覚えてないような書類 そして一番大事なソフトウェアはCD-Rに書き込んで、自社のロゴ入りの紙袋に入れて数人で運び出しうやうやしく納品 客もマジメな顔して印刷物をみて「ここの文字が間違ってる」とか言ってる そしていつの日か時間がたち、ふとCD-Rを見てみると新品 そう、書き込みするのを忘れていたのだ!! 素直になれよ本当は俺様のレスが見たいんだろwwwww 俺様の知性あふれるレスポンスに心がふるえて恋しちゃってるんだろwwwwww wwwwwwお友達から始めよう >>584 COBOL系の仕事でその伝説は聞いたことがある >>581 > プロダクトとしてどちらを重視すべきかは明らかですね ああ、どちらか一方だと思ってるのか 両方だろ こりゃだめだwww >>567 いつも正しく動いたら誰も苦労しないんやで。 必ずしも正しく動かないからこそ責任逃れのためのエビデンスが必要なんやで。 >>587 プログラマの自己満足を重視してどうすんだハゲwwwwダメなのはお前の頭だwwwww Unit Testは認知能力に欠陥のある人間のために考案されたエクササイズ的な位置づけなわけ Unit Testが発明されたアメリカのITの歴史を見れば火を見るよりあきらか Unit Testを発明した人間がいまどうなってるか調べて見ると良い >>588 エビデンスで責任逃れはできます みなさんも数兆円を動かすような重責を担う仕事についたらエビデンス残すと良いよ 一部上場のITゼネコンでバリバリ仕事こなしてる俺からのアドバイス 頭の片隅に置いて困ったときに思い出したら良いよ 責任は負えば良いってものじゃないリスクヘッジ大事、エビデンス大事、いざというときの保険 ソフトが動くかどうかなんて些細な問題であって業務が動き続けばいいんだよ 不具合が出るのがわかってたら客に 「印刷ボタン押したらバグるので、こっちのPDFボタン押してから印刷してください」 って通達しときゃいい もしオペレーターが間違えたら、高菜を食べた客をラーメン屋が咎めるような口調で 「どうして印刷ボタンなんて押したんですか!」って言えばいい オペレーターだって安くない給料貰ってるんだから、手順書更新したらちゃんとその通り動かしてくれるよ 君たちがバカにしてるエビちゃんも仕事を円滑に回すための一つのツールなんですねー >>588 前提条件を満たしていればいつも正しく動くものを作るためにテストするんやぞ >>594 前提条件満たした状態ではちゃんと動いていたことを証明するのがエビデンスやでぇ。 想定外のことをされてバグっても「バグが出た前提条件のテスト項目がないのに承認した貴方にも責任がある」と言うためのエビデンスやで。 「テストの時は動いてたんですけどねー」 「ログ出力を設定してちょっと様子みてみましょうか」 「再発した時の手順書を追加しておきますね」 >>597 これは有能なプロジェクトマネージャ 無能な奴は客の言うなりになってシステムを肥大化させて赤字にする >>588 せやな。現実はそういう証拠も要求されるよな。自己主張ばかりしていないでエビデンスを要求する人の立場と気持ちを考えればいい。 利害関係者はプログラマーだけじゃないだろうに。 >>592 そういう不具合を防ぐための単体テスト 単体テスト的には些細な問題と言い切るべきではないと思う。 設計が糞すぎてコードの修正に時間が掛かるのが理由だとしたら、ますます単体テストで安定するコードの設計を促せなかった罪は大きい。 ドカタ vs ドカタのマウンティンスレになったな 中身が無さ過ぎて泣ける >>600 わいは一応製品開発部部長だからどちらかというと1級建築士ですかね 社内で実験や研究はやったがUnit Testはユーザ満足度をあげるほど製品品質を左右しないんよねー 現代の開発は統合開発環境や静的検査、動的検査が整備されてコーディングミスはほとんど起きないってことと 単純にうちの社員が優秀ってのもあるだろうが、コーダが書くUnit Testに意味はないとうちの部署では結論した システムテストが良い、あれはシステムの品質も社員の質も上がる 業務要件もシステムのアーキテクチャも理解してないと観点出しもテストケース作ることさえできないから システムテストはおすすめ、社員の実力が底上げされる ガチガチに後方互換性を守りたい場合はUnitTestしてもいいかもね ライブラリメーカーとかならいいんじゃないの > ガチガチに後方互換性 言い方がおかしい。たいていはバージョンが有るようなものじゃないんだからさ この場合は、何らかの理由で修正を入れたときに、エンバグしないように ガチガチにテストするということだろ 修正なんてどうしてもはいるんだからさ、ガチガチにテストしておかないとだめやろ? 修正したときのエンバグ防止を、ガチガチな後方互換性と言ってるなら わからなくもないけどさ。エンバグしないってことは、ガチガチな後方互換性とも言えるからね いまさらどうでも良い話だが 手動か自動かなんて本質とは何の関係も無いぞ 信頼性はテストケースを網羅出来てるか出来てないかだけだ EdLJXccd kZm+fu8v IgGP+BQU ycF3TYue 4yJ9ltzt このスレが盛り上がった原因は主にこいつらか。 厶板にも隔離病棟が必要な気がしてきた。 テストをしなくてもいいぐらい小さく簡潔なプログラムブロックを作り組み合わせる 組み合わせで間違いが起こらないように関数型の知見を応用する これだけでいい これができてればバグなんて入りようがないから、テストほとんど意味ない 大の大人が10時から21時までずっと書き込みをしてるのを見ると悲しくなる >>505 単体テストは一般的にもIPA的にも機能性にフォーカスしたテストだからその記述は誤り ここはそんな基本的なことも知らない奴らが一日中無意味な雑談をするスレなのでまともな回答を期待してはいけない >>613 > 単体テストは一般的にもIPA的にも機能性にフォーカスしたテストだからその記述は誤り 理由は 単体テストは、機能性にフォーカスしたテストであり プログラムの内部設計書に基づいてホワイトボックステストを実施し、要求性能を満たしているかの確認を行います。 間違ってないよね? 個性あふれる文化の前には定義など無意味。 単体テスト=コードレビューという場所だってあるんだぜ。 >>615 その場所がどこか言えるなら、一般的な定義と言えるだろう 企業秘密だから言えるわけないとかいう話なら それは一般的な定義じゃないだろう >>613 試験勉強に毒されて正しいとされる回答を妄信するパターンだね 社会人になって治る人と治らない人がいるんだけど 治らない人は自分で考える力がないので総じて使えない >>617 正しい回答とは限らないから、間違ってんだという 根拠をまったく言わずに否定するパターンだね 根拠がないなら主張するのやめたら? この手の議論をする時は国家資格や有名なベンダー資格等で扱う言葉で議論するべき。 そもそも、企業勤めで資格取る奴は経験も十分に積んでるよ。 資格なんて大学受験に比べれば楽すぎる。 なんで、たったの数千円でとれる資格を取らないの? 言葉が共有できない猿が議論に参加すると邪魔だから消えてほしいね。 なんで資格を取らないのかって議論にすり替えるのやめてほしい >>616 一般的な定義かどうかを議論するのやめてほしい >>617 ←こいつが始めた話だろう。 それ以前にも似たような発言がある。 なぜ、そっちに突っ込まない。同一人物か? 資格を取らなくてもいいよ。 ただし世間一般の常識を知らないと潰しが効かなくなる >>621 > 一般的な定義かどうかを議論するのやめてほしい なぜ?一般的な定義で話をするのは当たり前でしょ? そうでないなら○○の定義ではってちゃんと言うこと 一部でしか使われない定義をいっても通じるわけがないんだから >>505 >パフォーマンスの性能のことだとすれば、性能以外は確認しない感じの文章になる > >普通に間違いっぽいね 仮定を置いて間違いが導かれるなら仮定が誤りだと結論できる >>624 普通は通じるよ、語用論でググってみ、概念と単語を同じものだと思ってるから理解できないんだよ 君のコミュニケーションにおける相手の言葉への不寛容さはアスペと呼ばれてもおかしくないよ 言葉の一部を切り取って騒ぐマスコミとやってることは変わらん 文脈からどういう意味で使ってるのが類推して理解するのが普通の人のコミュニケーション 言葉の定義がー定義がーなんてリアルな会話ではやらないでしょ? それをやったら会話にならないと思われるから >>626 その普通が通じないから、こんな話になっているってことになぜ気が付かない。 昼休みに話の通じない馬鹿に遭遇するとは思わなかった。 話さえ通じれば何でもいいが、駄目だなこりゃ。 厶板にが過疎化する理由がよくわかったよ。 二度とこの板に来ないほうがいいな。 知的障害者との会話は疲れる。 >>626 そんな話はしてない。通じるかどうかじゃなくて "別の意味として"間違って通じてしまっては意味がないから 一般的な定義の話しようと言ってるだけ >>627 > 言葉の定義がー定義がーなんてリアルな会話ではやらないでしょ? そりゃそうだろw リアルな会話で「俺の会社では」なんて話をしないんだからw >>631 通じるわけがないって言ってましたよね、そんなことないですよってこと >>632 リアルではしないんだ で、その会社文化とやらのテスト分類定義を採用すると、 IPAのテスト分類定義を採用するのに比べてどんなメリットがあるんだい? 何でこんなスレが伸びてるんだと思ったらあからさまな釣りに釣られてるやつが多かっただけか たんたい‐テスト【単体テスト】 の解説 《unit test》ソフトウエアテストの一。動作対象を小さな単位に分割してテストすることを指す。→結合テスト →ビッグバンテスト 言葉の定義は設計書の付録についてくるでしょ リアルな会話でやらない人は上流工程に参加してないだけ ソフトウェアの最小単位は画面やページやろ? どうやって1つの関数でテストできるっていうんだ? そうなんだよ 小さい単位だとしか定義されていない 画面は論外としても関数だとは誰も言ってない 昔は暗黙の了解で 単体テスト=関数だった 推測だが CUIアプリの場合:単体テスト=関数 GUIアプリの場合:単体テスト=1機能を実現する為の最小コンポーネント群 という風になってしまったんじゃないだろうか 要するにCUIのC言語アプリなら関数を最小単位にするのは直感的で GUIのVBアプリならテキストボックス+ボタンのセットを最小単位とするのが直感的だった だから自然と2つの意味が併存してしまい しかも実施時には違和感を感じなかった 結論 無能は関数単位でテストする方法がわからない その方法が存在することを知らない だから実行ファイルを使ってテストすることしかできない >>639 > CUIアプリの場合:単体テスト=関数 無能の場合CUIアプリのテストとは 実行ファイルを実行してテストする 例えばgitの場合、gitのすべてのコマンドを実行してテストする git initをしたらどういうファイルが作成されるかをチェックしている >>641 https://github.com/git/git/tree/master/t gitにgitのユニットテスト乗ってるけど半端ないよなこれ シェルバッチで全部テストしてる 無能ほど無駄な仕事を多くやろうとする コマンドごとにテストできることをわざわざ関数ごとにテストして膨大な工数を無駄にする しかも関数のテストをしたってコマンドが正しく動作する保証にはならないから関数のテストは意味がない バグが混入しにくい堅牢なコードを書くことに労力をかけて テストはある程度大きな粒度でやったほうがいい 最小限のテストで最大の効果を得ることを考えろ 暇を持て余した学生のお遊びじゃないんだ 業務では工数は限られてる >>641 CUIとCLIは別やで gitはCLI 納品の為のテスト トラブル対応の時間を減らす為のテスト 損害賠償を回避する為のテスト 同じように見えるテストでも目的は色々 目的が変われば手段も変わる なるほどな 仕様を満たしているか確認するためのテストはしなくていい現場ってのがあるわけだ その種のテストはなぜか手動でやれとか言い出すのがSIerやで 自動テストはダメなの→自動テストが正しい事はどうやって担保するのか→人間のほうが信用できない→自動テスト作ってるのも人間→ふぁ? 人類はこうやって無駄を繰り返してきた そもそも自動テストは繰り返し何度も行う前提 ウォーターフォールであるおまえらの現場では自動テストは相性が悪い >>651 根本的にわかってないだろw > そもそも自動テストは繰り返し何度も行う前提 テストが一回で終わることなんてありえないよ バグを修正するたびに全部テストやり直しだからね 1つでも見つかったら全部やり直し バグはコンパイラに探させたほうがいい だから関数型がいいんだ 関数型はテストもシンプルで少なくて済む ? ゲームで設定から言語を 英語から日本語に変更したら 日本語で表示されるでしょ? 関数型でも同じことなんだが 英語を入力して、日本語が出力されるのを確認、じゃないの ナウなヤングはステートを持たないコーディングがバカウケでしょ? DBに持たせてアプリケーションサーバには持たせない 言語変更の問題なら、 すべきテストは異なる環境を網羅した横展開のテストだけど、 >>1 の指摘なら、全く同じ環境なのに手動で1000回試行しろと命じられる縦に掘っていくテスト >>656 純粋に関数型を突き詰めるなら状態が必要な部分は全部引数に追い出すのが正解じゃないかな 多言語対応必要なラベルは言語コンフィグ参照なんかせずに毎度文字列を受け取れってことだ まあ流石にそれはきついだろうから文字列そのものじゃなく文字列を吐くモナドを受け取る形でもいいと思うけど >>661 ちゃんと読めよ 自動化してもテストケースは人間が作ってるから テストケースも自動化しようぜ!っていうのがHypothesisっていうツールの役目だろ? だから自動テスト自体を否定してるもんじゃないぞ https://github.com/HypothesisWorks/hypothesis × 自動テストは効果がありません ○ テストケースを自動化することは効果がありません https://hypothesis.works/ >>664 むしろ、従来の自動化程度では甘い。もっと自動化しようぜとしか読めないのだが。 てか、あんた、中学レベルの英語を読めないの? ニンゲンに金銭を注入することで自動的に作業させてます。 自動テストを実現できていれば 中身を他の言語で書き直しても 簡単に動作確認が取れるよな 開発環境言語とテスト環境言語は一緒でも良いけど 開発環境とテスト環境は一緒にしてると移行しにくいな ソースにテスト埋め込めます(キリッ っていう言語多いけどさ 全自動になったとしてさ ルールは与えないといけないわけでしょ? そのルールのデバッグできないの? 仕様書に書いてあることだけチェックすりゃいいわけで 仕様書の項目以上増えることはない >>672 CASEツールやらUMLコード生成やらもう何十年も前からそういったアプローチがあるけど全くスタンダードになってない。 唯一Matlab+Simulinkが自動車業界で流行ってるぐらいかな? 開発言語の進化こそあるにせよ結局仕様書の曖昧さを具体化するのはソースコードのみであるという事実は何も変わってない。 仕様書は結構曖昧に書かれている その曖昧な仕様書をよんで、ここが曖昧ですと指摘できるAIが 実現できないと仕様書からコードは自動生成できるようにはならない しかし曖昧な文章を理解できてかつ、曖昧な文章を曖昧だと指摘できるAIは作れるのかね? 仕様書が曖昧でも別に俺らは困らないよな 割と曖昧に組むこともできるし 会社の経営者層と俺らって一線引いてあること多いし セキュリティが緩かったですなんて完全に他人事 客先常駐だったらそもそも仕様を決めたクソったれが悪いし 請負だったら出された要件を満たす項目だけ組むだけ 要件に最強のセキュリティとか書いてあったらできませんと返すことになるだろうが 仕様書から生成されたコードの動きをテストするのは 仕様の曖昧さとは関係ない 仕様に曖昧さがなくてもテストは必要 >>676 > 仕様書が曖昧でも別に俺らは困らないよな プログラムに直すときに修正しているからね コンピュータ(AI含む)はそれができないから 仕様書からのコードの自動生成なんて不可能 俺は単体テスト煽りの意見を支持する 単体テストは杓子定規な方便だよ ネクタイと革靴の有無で大人度を判断するような本質からズレたまま根付いたスタンダード まるで無駄とは言わんが、なくなった方が世界が少しシンプルになるやつだ テスト書いてないとかお前それ@t_wadaの前でも同じ事言えんの?(AA略 Rustのメモリ安全性はボローチェッカーによって担保されているが、 Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、 GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ 限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか? Nimの実験的特徴 バージョン1.5.1 http://nim-lang.github.io/Nim/manual_experimental.html 第二プログラミング言語として Rust はオススメしません Nim をやるのです https://wolfbash.hateblo.jp/entry/2017/07/30/193412 Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ!」と言うとても大事な事を Nim は我々に教えてくれます Rustのメモリ安全性はボローチェッカーによって担保されているが、 Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、 GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ 限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか? Nimの実験的特徴 バージョン1.5.1 http://nim-lang.github.io/Nim/manual_experimental.html 第二プログラミング言語として Rust はオススメしません Nim をやるのです https://wolfbash.hateblo.jp/entry/2017/07/30/193412 Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ!」と言うとても大事な事を Nim は我々に教えてくれます きれいなテストが書けるやつのコードは読みやすいよ テストに工数がかかるし意味ないって言ってるやつはCLEANなコードが書けていないだけ おまえらテストいちいち自動化してんの? マジでえらいな おれ時間勿体無いしそんな時間あったらネットしたりしてたいから 手動でぱぱっと終わらして 仕様変更来ても関係なさそうな部分だったらテストしないわ >>692 > テストしてんの?テストしないわ までよんだ なんだか20年くらい前にユースケース図が流行ったときに 全く役立たない棒人形ばかり仕様書に書いていた事を思い出した。 テストプログラムもユースケースと同じように書いてる本人も意味が分かっていないかも? テストプログラムがなんのことか知らないけど、 よく使われている有名なオープンソースソフトウェアには かならずテストコードがありますよね? テストコードの重要性は否定できないのでは? ユースケースは殆ど見かけないけど >>695 ユースケース図のコピペと同じで 常にパスするテストコードばかりのプロジェクトも見たことある。 関係ないがその会社は他にも難があり VisualSourceSafe(当時)みたいな履歴管理システムは分かりにくいから使うな。 クラスはトレースが困難だから使うのはやめるように JavaのInterfece宣言がプライベードメソッドにだけされている。 DBでSelectした場合は必ずInsertした順序で出るから・・・ 今でもこんなところがありそうなので怖い。 え?ユースケース図は今は書かないの? 要件定義ではいつも書いてるけど このスレ加齢臭すごいな 汎用系→WEB系に転職したけど まさに汎用系の現場にいたようなやつらばかりだね どうせアレだろ?「スクリプト言語は簡単!バカでも出来る!!」信仰なんだろ? 一生COBOLでPERFORM文でも書いとけや 金になるからって若手に変な仕事押し付けないでください。 これ「単体テストをしてるフリをするBOT」の需要あるだろ ユニットテストにエクセル生成のライブラリをくっつけたやつが有れば便利なんじゃないかと思ってる なんかAIがテストコードを生成してもおかしくない時代になってきたな 単体テストって改修した部分のコードをexcelに貼り付けて確認表を埋めるんだろ。知ってる。 単体テストの結果がおかしかったので修正しておきました!(テスト結果を) >>704 テストパラメータをズラズラ並べる時なんかはcopilotの補完がかなり利くね テストデータを外出しにすると逆に補完が利きづらいから外出ししたくなくなるw read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる