「単体テストを手動で行いエビデンス取る」の破壊力

**デフォルトの名無しさん** · 2020/09/23(水) 12:29:11.02

単体テストは自動化するものだと思っていたから
一瞬何を言っているのかわからなかった

**デフォルトの名無しさん** · 2020/10/09(金) 11:43:22.54

>>613
> 単体テストは一般的にもIPA的にも機能性にフォーカスしたテストだからその記述は誤り
理由は

単体テストは、機能性にフォーカスしたテストであり
プログラムの内部設計書に基づいてホワイトボックステストを実施し、要求性能を満たしているかの確認を行います。

間違ってないよね？

**デフォルトの名無しさん** · 2020/10/09(金) 11:47:34.84

個性あふれる文化の前には定義など無意味。
単体テスト＝コードレビューという場所だってあるんだぜ。

**デフォルトの名無しさん** · 2020/10/09(金) 11:56:10.47

>>615
その場所がどこか言えるなら、一般的な定義と言えるだろう

企業秘密だから言えるわけないとかいう話なら
それは一般的な定義じゃないだろう

**デフォルトの名無しさん** · 2020/10/09(金) 12:36:02.83

>>613
試験勉強に毒されて正しいとされる回答を妄信するパターンだね
社会人になって治る人と治らない人がいるんだけど
治らない人は自分で考える力がないので総じて使えない

**デフォルトの名無しさん** · 2020/10/09(金) 12:40:07.10

>>617
正しい回答とは限らないから、間違ってんだという
根拠をまったく言わずに否定するパターンだね
根拠がないなら主張するのやめたら？

**デフォルトの名無しさん** · 2020/10/09(金) 12:43:02.32

この手の議論をする時は国家資格や有名なベンダー資格等で扱う言葉で議論するべき。

そもそも、企業勤めで資格取る奴は経験も十分に積んでるよ。
資格なんて大学受験に比べれば楽すぎる。
なんで、たったの数千円でとれる資格を取らないの？

言葉が共有できない猿が議論に参加すると邪魔だから消えてほしいね。

**デフォルトの名無しさん** · 2020/10/09(金) 12:46:14.62

なんで資格を取らないのかって議論にすり替えるのやめてほしい

**デフォルトの名無しさん** · 2020/10/09(金) 12:48:03.07

>>616
一般的な定義かどうかを議論するのやめてほしい

**デフォルトの名無しさん** · 2020/10/09(金) 12:48:25.97

>>617　←こいつが始めた話だろう。
それ以前にも似たような発言がある。
なぜ、そっちに突っ込まない。同一人物か？

**デフォルトの名無しさん** · 2020/10/09(金) 12:48:37.58

資格を取らなくてもいいよ。
ただし世間一般の常識を知らないと潰しが効かなくなる

**デフォルトの名無しさん** · 2020/10/09(金) 12:49:44.16

>>621
> 一般的な定義かどうかを議論するのやめてほしい

なぜ？一般的な定義で話をするのは当たり前でしょ？
そうでないなら○○の定義ではってちゃんと言うこと
一部でしか使われない定義をいっても通じるわけがないんだから

**デフォルトの名無しさん** · 2020/10/09(金) 12:51:35.65

>>505
>パフォーマンスの性能のことだとすれば、性能以外は確認しない感じの文章になる
>
>普通に間違いっぽいね

仮定を置いて間違いが導かれるなら仮定が誤りだと結論できる

**デフォルトの名無しさん** · 2020/10/09(金) 12:53:40.49

>>624
普通は通じるよ、語用論でググってみ、概念と単語を同じものだと思ってるから理解できないんだよ
君のコミュニケーションにおける相手の言葉への不寛容さはアスペと呼ばれてもおかしくないよ

**デフォルトの名無しさん** · 2020/10/09(金) 12:56:26.55

言葉の一部を切り取って騒ぐマスコミとやってることは変わらん
文脈からどういう意味で使ってるのが類推して理解するのが普通の人のコミュニケーション
言葉の定義がー定義がーなんてリアルな会話ではやらないでしょ？
それをやったら会話にならないと思われるから

**デフォルトの名無しさん** · 2020/10/09(金) 12:56:54.88

>>626
その普通が通じないから、こんな話になっているってことになぜ気が付かない。

**デフォルトの名無しさん** · 2020/10/09(金) 12:59:02.45

5chはアスペに寛容なコミュニティとも言えるかな

**デフォルトの名無しさん** · 2020/10/09(金) 13:00:31.33

昼休みに話の通じない馬鹿に遭遇するとは思わなかった。
話さえ通じれば何でもいいが、駄目だなこりゃ。
厶板にが過疎化する理由がよくわかったよ。

二度とこの板に来ないほうがいいな。
知的障害者との会話は疲れる。

**デフォルトの名無しさん** · 2020/10/09(金) 13:01:02.93

>>626
そんな話はしてない。通じるかどうかじゃなくて
"別の意味として"間違って通じてしまっては意味がないから
一般的な定義の話しようと言ってるだけ

**デフォルトの名無しさん** · 2020/10/09(金) 13:03:06.66

>>627
> 言葉の定義がー定義がーなんてリアルな会話ではやらないでしょ？

そりゃそうだろｗ
リアルな会話で「俺の会社では」なんて話をしないんだからｗ

**デフォルトの名無しさん** · 2020/10/09(金) 13:20:26.77

>>631
通じるわけがないって言ってましたよね、そんなことないですよってこと

>>632
リアルではしないんだ

**デフォルトの名無しさん** · 2020/10/09(金) 13:47:09.26

で、その会社文化とやらのテスト分類定義を採用すると、
IPAのテスト分類定義を採用するのに比べてどんなメリットがあるんだい？

**デフォルトの名無しさん** · 2020/10/10(土) 05:20:40.98

何でこんなスレが伸びてるんだと思ったらあからさまな釣りに釣られてるやつが多かっただけか

**デフォルトの名無しさん** · 2020/10/11(日) 00:58:37.49

たんたい‐テスト【単体テスト】の解説
《unit test》ソフトウエアテストの一。動作対象を小さな単位に分割してテストすることを指す。→結合テスト →ビッグバンテスト

**デフォルトの名無しさん** · 2020/10/11(日) 01:00:37.45

言葉の定義は設計書の付録についてくるでしょ
リアルな会話でやらない人は上流工程に参加してないだけ

**デフォルトの名無しさん** · 2020/10/11(日) 01:02:41.18

ソフトウェアの最小単位は画面やページやろ？
どうやって1つの関数でテストできるっていうんだ？

**デフォルトの名無しさん** · 2020/10/11(日) 11:16:33.93

そうなんだよ
小さい単位だとしか定義されていない
画面は論外としても関数だとは誰も言ってない

昔は暗黙の了解で
単体テスト＝関数だった

推測だが
CUIアプリの場合：単体テスト＝関数
GUIアプリの場合：単体テスト＝1機能を実現する為の最小コンポーネント群
という風になってしまったんじゃないだろうか

要するにCUIのC言語アプリなら関数を最小単位にするのは直感的で
GUIのVBアプリならテキストボックス＋ボタンのセットを最小単位とするのが直感的だった

だから自然と2つの意味が併存してしまい
しかも実施時には違和感を感じなかった

**デフォルトの名無しさん** · 2020/10/11(日) 11:39:31.27

結論

無能は関数単位でテストする方法がわからない
その方法が存在することを知らない
だから実行ファイルを使ってテストすることしかできない

**デフォルトの名無しさん** · 2020/10/11(日) 11:41:06.19

>>639
> CUIアプリの場合：単体テスト＝関数

無能の場合CUIアプリのテストとは
実行ファイルを実行してテストする

例えばgitの場合、gitのすべてのコマンドを実行してテストする
git initをしたらどういうファイルが作成されるかをチェックしている

**デフォルトの名無しさん** · 2020/10/11(日) 11:53:56.56

対象になってる粒度次第

**デフォルトの名無しさん** · 2020/10/11(日) 11:54:31.15

>>641
https://github.com/git/git/tree/master/t

gitにgitのユニットテスト乗ってるけど半端ないよなこれ
シェルバッチで全部テストしてる

**デフォルトの名無しさん** · 2020/10/11(日) 12:00:01.38

無能ほど無駄な仕事を多くやろうとする

コマンドごとにテストできることをわざわざ関数ごとにテストして膨大な工数を無駄にする
しかも関数のテストをしたってコマンドが正しく動作する保証にはならないから関数のテストは意味がない

バグが混入しにくい堅牢なコードを書くことに労力をかけて
テストはある程度大きな粒度でやったほうがいい
最小限のテストで最大の効果を得ることを考えろ

暇を持て余した学生のお遊びじゃないんだ
業務では工数は限られてる

**デフォルトの名無しさん** · 2020/10/11(日) 12:14:15.39

また業務ガイジ湧いてて草

**デフォルトの名無しさん** · 2020/10/11(日) 12:24:51.84

無職ガイジ

**デフォルトの名無しさん** · 2020/10/11(日) 12:26:59.56

>>641
CUIとCLIは別やで
gitはCLI

**デフォルトの名無しさん** · 2020/10/11(日) 13:19:41.83

納品の為のテスト
トラブル対応の時間を減らす為のテスト
損害賠償を回避する為のテスト

同じように見えるテストでも目的は色々
目的が変われば手段も変わる

**デフォルトの名無しさん** · 2020/10/11(日) 18:23:47.93

なるほどな
仕様を満たしているか確認するためのテストはしなくていい現場ってのがあるわけだ

**デフォルトの名無しさん** · 2020/10/11(日) 19:39:47.33

その種のテストはなぜか手動でやれとか言い出すのがSIerやで

**デフォルトの名無しさん** · 2020/10/11(日) 19:47:52.34

自動テストはダメなの→自動テストが正しい事はどうやって担保するのか→人間のほうが信用できない→自動テスト作ってるのも人間→ふぁ？

人類はこうやって無駄を繰り返してきた

そもそも自動テストは繰り返し何度も行う前提
ウォーターフォールであるおまえらの現場では自動テストは相性が悪い

**デフォルトの名無しさん** · 2020/10/11(日) 19:49:19.76

>>651
根本的にわかってないだろｗ

> そもそも自動テストは繰り返し何度も行う前提
テストが一回で終わることなんてありえないよ
バグを修正するたびに全部テストやり直しだからね
1つでも見つかったら全部やり直し

**デフォルトの名無しさん** · 2020/10/11(日) 20:08:06.89

バグはコンパイラに探させたほうがいい
だから関数型がいいんだ
関数型はテストもシンプルで少なくて済む

**デフォルトの名無しさん** · 2020/10/11(日) 20:27:18.34

関数型で状態があるテストはどうやってやるの？

**デフォルトの名無しさん** · 2020/10/11(日) 20:28:39.68

そんなものはない

**デフォルトの名無しさん** · 2020/10/11(日) 20:51:40.01

？

ゲームで設定から言語を
英語から日本語に変更したら
日本語で表示されるでしょ？

関数型でも同じことなんだが

**デフォルトの名無しさん** · 2020/10/11(日) 20:54:28.98

英語を入力して、日本語が出力されるのを確認、じゃないの

**デフォルトの名無しさん** · 2020/10/11(日) 21:07:29.17

ナウなヤングはステートを持たないコーディングがバカウケでしょ？
DBに持たせてアプリケーションサーバには持たせない

**デフォルトの名無しさん** · 2020/10/11(日) 23:34:04.06

言語変更の問題なら、
すべきテストは異なる環境を網羅した横展開のテストだけど、
>>1の指摘なら、全く同じ環境なのに手動で1000回試行しろと命じられる縦に掘っていくテスト

**デフォルトの名無しさん** · 2020/10/13(火) 19:03:34.58

>>656
純粋に関数型を突き詰めるなら状態が必要な部分は全部引数に追い出すのが正解じゃないかな
多言語対応必要なラベルは言語コンフィグ参照なんかせずに毎度文字列を受け取れってことだ
まあ流石にそれはきついだろうから文字列そのものじゃなく文字列を吐くモナドを受け取る形でもいいと思うけど

**デフォルトの名無しさん** · 2020/10/15(木) 12:59:52.75

自動テストは効果がありませんって言われてるぞ
https://hypothesis.works/

**デフォルトの名無しさん** · 2020/10/15(木) 16:45:53.96

>>661
ちゃんと読めよ
自動化してもテストケースは人間が作ってるから
テストケースも自動化しようぜ！っていうのがHypothesisっていうツールの役目だろ？
だから自動テスト自体を否定してるもんじゃないぞ

https://github.com/HypothesisWorks/hypothesis

**デフォルトの名無しさん** · 2020/10/15(木) 21:45:30.14

老眼だからタイトル以外読めなかったんだよ

**デフォルトの名無しさん** · 2020/10/16(金) 05:14:11.22

× 自動テストは効果がありません
○ テストケースを自動化することは効果がありません
https://hypothesis.works/

**デフォルトの名無しさん** · 2020/10/16(金) 08:32:18.61

>>664
むしろ、従来の自動化程度では甘い。もっと自動化しようぜとしか読めないのだが。
てか、あんた、中学レベルの英語を読めないの？

**デフォルトの名無しさん** · 2020/10/16(金) 09:32:48.76

ニンゲンに金銭を注入することで自動的に作業させてます。

**デフォルトの名無しさん** · 2020/10/16(金) 12:10:17.32

自動テストを実現できていれば
中身を他の言語で書き直しても
簡単に動作確認が取れるよな

**デフォルトの名無しさん** · 2020/10/16(金) 12:12:12.88

開発環境言語とテスト環境言語は一緒でも良いけど
開発環境とテスト環境は一緒にしてると移行しにくいな

ソースにテスト埋め込めます(キリッ
っていう言語多いけどさ

**デフォルトの名無しさん** · 2020/10/16(金) 18:51:33.46

全自動になったとしてさ
ルールは与えないといけないわけでしょ？
そのルールのデバッグできないの？

**デフォルトの名無しさん** · 2020/10/16(金) 20:57:43.76

>>669
仕様書を数式で書けば可能だが

**デフォルトの名無しさん** · 2020/10/16(金) 21:42:50.76

仕様書に書いてあることだけチェックすりゃいいわけで
仕様書の項目以上増えることはない

**デフォルトの名無しさん** · 2020/10/17(土) 10:32:40.48

仕様書からコード自動生成すればテスト不要説

**デフォルトの名無しさん** · 2020/10/17(土) 10:42:01.97

>>672
発想が貧弱

**デフォルトの名無しさん** · 2020/10/17(土) 11:55:44.81

>>672
CASEツールやらUMLコード生成やらもう何十年も前からそういったアプローチがあるけど全くスタンダードになってない。
唯一Matlab+Simulinkが自動車業界で流行ってるぐらいかな？
開発言語の進化こそあるにせよ結局仕様書の曖昧さを具体化するのはソースコードのみであるという事実は何も変わってない。

**デフォルトの名無しさん** · 2020/10/17(土) 12:29:10.51

仕様書は結構曖昧に書かれている
その曖昧な仕様書をよんで、ここが曖昧ですと指摘できるAIが
実現できないと仕様書からコードは自動生成できるようにはならない

しかし曖昧な文章を理解できてかつ、曖昧な文章を曖昧だと指摘できるAIは作れるのかね？

**デフォルトの名無しさん** · 2020/10/17(土) 12:35:18.94

仕様書が曖昧でも別に俺らは困らないよな
割と曖昧に組むこともできるし

会社の経営者層と俺らって一線引いてあること多いし
セキュリティが緩かったですなんて完全に他人事
客先常駐だったらそもそも仕様を決めたクソったれが悪いし
請負だったら出された要件を満たす項目だけ組むだけ
要件に最強のセキュリティとか書いてあったらできませんと返すことになるだろうが

**デフォルトの名無しさん** · 2020/10/17(土) 12:37:17.41

アスペ型AI最強説

**デフォルトの名無しさん** · 2020/10/17(土) 12:55:58.45

仕様書から生成されたコードの動きをテストするのは
仕様の曖昧さとは関係ない
仕様に曖昧さがなくてもテストは必要

**デフォルトの名無しさん** · 2020/10/17(土) 13:02:44.32

>>676
> 仕様書が曖昧でも別に俺らは困らないよな

プログラムに直すときに修正しているからね
コンピュータ（AI含む）はそれができないから
仕様書からのコードの自動生成なんて不可能

**デフォルトの名無しさん** · 2020/10/17(土) 13:23:25.28

無知って怖いね

**デフォルトの名無しさん** · 2020/10/17(土) 13:31:34.30

世の中には仕様記述言語というのがあってだな

**デフォルトの名無しさん** · 2020/10/17(土) 15:10:30.11

ところが誰も使ったことがないのである

**デフォルトの名無しさん** · 2020/10/17(土) 16:23:53.28

>仕様記述言語

rubyのことですねわかります

**デフォルトの名無しさん** · 2020/10/18(日) 11:43:25.20

ﾗｳﾞｨ

**デフォルトの名無しさん** · 2020/10/20(火) 00:14:22.29

ﾃｰﾃﾃｰﾃﾃｯﾃｯﾃｯ

**デフォルトの名無しさん** · 2021/03/13(土) 18:15:37.05

草の数は知能の低さと比例する

**デフォルトの名無しさん** · 2021/05/04(火) 11:11:34.18

俺は単体テスト煽りの意見を支持する
単体テストは杓子定規な方便だよ
ネクタイと革靴の有無で大人度を判断するような本質からズレたまま根付いたスタンダード
まるで無駄とは言わんが、なくなった方が世界が少しシンプルになるやつだ

**デフォルトの名無しさん** · 2021/05/04(火) 14:42:17.48

テスト書いてないとかお前それ@t_wadaの前でも同じ事言えんの？(AA略

**デフォルトの名無しさん** · 2021/08/22(日) 09:13:05.54

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 は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 10:26:58.06

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 は我々に教えてくれます

**デフォルトの名無しさん** · 2021/09/30(木) 00:33:23.23

きれいなテストが書けるやつのコードは読みやすいよ
テストに工数がかかるし意味ないって言ってるやつはCLEANなコードが書けていないだけ

**デフォルトの名無しさん** · 2022/01/25(火) 07:14:27.74

おまえらテストいちいち自動化してんの？
マジでえらいな
おれ時間勿体無いしそんな時間あったらネットしたりしてたいから
手動でぱぱっと終わらして
仕様変更来ても関係なさそうな部分だったらテストしないわ

**デフォルトの名無しさん** · 2022/01/25(火) 09:51:11.69

>>692
> テストしてんの？テストしないわ

までよんだ

**デフォルトの名無しさん** · 2022/02/23(水) 22:50:38.23

なんだか２０年くらい前にユースケース図が流行ったときに
全く役立たない棒人形ばかり仕様書に書いていた事を思い出した。
テストプログラムもユースケースと同じように書いてる本人も意味が分かっていないかも？

**デフォルトの名無しさん** · 2022/02/24(木) 05:17:14.07

テストプログラムがなんのことか知らないけど、
よく使われている有名なオープンソースソフトウェアには
かならずテストコードがありますよね？

テストコードの重要性は否定できないのでは？
ユースケースは殆ど見かけないけど

**デフォルトの名無しさん** · 2022/02/24(木) 09:59:05.05

>>695
ユースケース図のコピペと同じで
常にパスするテストコードばかりのプロジェクトも見たことある。

関係ないがその会社は他にも難があり

VisualSourceSafe（当時）みたいな履歴管理システムは分かりにくいから使うな。
クラスはトレースが困難だから使うのはやめるように
JavaのInterfece宣言がプライベードメソッドにだけされている。
DBでSelectした場合は必ずInsertした順序で出るから・・・

今でもこんなところがありそうなので怖い。

**デフォルトの名無しさん** · 2022/02/26(土) 11:15:18.32

え？ユースケース図は今は書かないの？
要件定義ではいつも書いてるけど

**デフォルトの名無しさん** · 2022/09/23(金) 05:40:13.22

このスレ加齢臭すごいな
汎用系→WEB系に転職したけど
まさに汎用系の現場にいたようなやつらばかりだね

どうせアレだろ？「スクリプト言語は簡単！バカでも出来る！！」信仰なんだろ？
一生COBOLでPERFORM文でも書いとけや
金になるからって若手に変な仕事押し付けないでください。

**デフォルトの名無しさん** · 2022/10/23(日) 22:13:04.99

スクショパシャパシャを強いられて辛い

**デフォルトの名無しさん** · 2022/11/11(金) 10:21:17.49

工数を埋めるため

**デフォルトの名無しさん** · 2022/11/17(木) 14:21:47.08

これ「単体テストをしてるフリをするBOT」の需要あるだろ

**デフォルトの名無しさん** · 2022/11/17(木) 15:17:22.85

ユニットテストにエクセル生成のライブラリをくっつけたやつが有れば便利なんじゃないかと思ってる

**デフォルトの名無しさん** · 2022/12/10(土) 16:45:59.33

TDD楽しいからな

**デフォルトの名無しさん** · 2023/04/05(水) 20:50:28.08

なんかAIがテストコードを生成してもおかしくない時代になってきたな

**デフォルトの名無しさん** · 2023/04/18(火) 08:37:01.78

単体テストって改修した部分のコードをexcelに貼り付けて確認表を埋めるんだろ。知ってる。

**デフォルトの名無しさん** · 2023/08/29(火) 14:52:38.70

単体テストの結果がおかしかったので修正しておきました！(テスト結果を)

**デフォルトの名無しさん** · 2023/10/01(日) 14:23:05.16

>>704
テストパラメータをズラズラ並べる時なんかはcopilotの補完がかなり利くね
テストデータを外出しにすると逆に補完が利きづらいから外出ししたくなくなるw

**デフォルトの名無しさん** · 2024/06/19(水) 18:51:58.17

ユニットテスト≠単体テスト

**デフォルトの名無しさん** · 2024/06/21(金) 06:13:37.92

ユニットテストの日本語訳が単体テストなんですが…