「単体テストを手動で行いエビデンス取る」の破壊力
単体テストは自動化するものだと思っていたから
一瞬何を言っているのかわからなかった >>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つでも見つかったら全部やり直し バグはコンパイラに探させたほうがいい
だから関数型がいいんだ
関数型はテストもシンプルで少なくて済む ?
ゲームで設定から言語を
英語から日本語に変更したら
日本語で表示されるでしょ?
関数型でも同じことなんだが