意味がないテストをするな。VERSION==1.0.0 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/09/09(土) 15:31:54.82

app.version = '1.0.0'

テストコード
expect(app.version).to.be '1.0.0'

バージョン番号1.1.0に変更すっぞ！

app.version = '1.1.0' に修正
expect(app.version).to.be '1.1.0' に修正

これただのデータの重複、たんなる二重管理ですから＼(^o^)／
メンテナンス工数が二倍になるだけ

誰もそんなことやらねーよって思うかもしれないが

関数だったらやってしまうんだよね。
カバレッジがー（笑）

function getVersion() { return '1.1.0' }

expect(app.getVersion()).to.be '1.1.0'

他にも色々と、意味がないテストがある
意味がないテストしてるやつが多い。
関数の実行結果をテストコードにコピペしてテスト作るやつとかな

**デフォルトの名無しさん** · 2017/09/10(日) 17:18:17.17

設計書書けよｗ
単体なら設計書通りに動くかどうかをテストしろよ
コード見てテストを決めようとするからそんな問題が出てくんだろが雑魚が

**デフォルトの名無しさん** · 2017/09/10(日) 17:25:04.80

こう言いかえれば良いんですかね？

問題は設計書に1.0.0が返ってくることって
書くのはアホらしいって話ですな。

バージョンが上がるたびに1.1.0が返ってくる
ことなんて修正しないといけない
VERSIONファイルに1.1.0と書いてあるのだから
1.1.0が帰ってくるなんて当たり前でしょう。

また数字のみであることというテストは
項目のバリデーション定義ファイルにnumberOnlyと
書いて有ることを確認すれば良いわけですよ。

バリデーション定義ファイルにnumberOnlyと書いてあるのだから
numberOnlyであるのは当たり前。なのに項目一つづつ
numberOnlyの仕様を満たしているか？というテストをするのは無意味です。

画面の出力結果を目視で観察するぐらいなら
定義ファイルを目視で観察すれば良いのです。
自動化のためにテストコードを書くというのなら、
定義ファイルに書いて有ることをテストすれば良いのです。
numberOnlyと書いてある事。とね。

**デフォルトの名無しさん** · 2017/09/10(日) 17:33:45.82

>>27
設計書がそうであればどんなにくだらないことでもテストしなければならないよな

これが普通の感覚だな
コードを見てテストの仕様を考えるからくだらないなんて話が出てくる
くだらなかろうがなんだろうが仕様または設計書通りに動かすことが俺らの仕事なんだよ

**デフォルトの名無しさん** · 2017/09/10(日) 18:23:45.21

>>25
「バージョン番号は1.1.1である」という仕様を満たすかどうかのテストと
getVersionメソッドがメソッド仕様どおりに動くかどうかのテストとは別物
俺が言ってたのは前者の話ね

後者のテストをしたいならメソッド仕様をまず明確にしようね
設計書書けってのと同じこと

**デフォルトの名無しさん** · 2017/09/10(日) 18:29:29.72

>>24
what to testがテストの仕様
how to testがテストの実装

>>27を読んでもwhat to testを理解してないのが分かる

**デフォルトの名無しさん** · 2017/09/10(日) 21:25:57.68

作った本人とか同じ部門内でテストコード作るのはテストじゃねぇよ最低限のバグ減らしというかチェックだろ
二重管理とかのレベルですらない

まともにテストするとこなら、仕様書、設計書をベースに絶対に設計部門以外でテストを作らなきゃボロクソに叩かれる
そうするとたとえバージョンチェックでも意味は出てくる

**デフォルトの名無しさん** · 2017/09/10(日) 21:29:54.28

>>31
なんか複雑なインターフェースしてて思った値が返って来ないんだろ

**デフォルトの名無しさん** · 2017/09/10(日) 21:31:19.11

まったくもって>>26 の言うとおり
意味が無いとか言い訳して設計書すら書かないとかコード書いてから設計書作るやつとか
仕様合わせるとバグりまくりなんだよなぁ

**デフォルトの名無しさん** · 2017/09/10(日) 21:37:38.91

ま、やってるテストが意味ないと思うなら
テストのやり方を意味あるものにすれば良いのだがそれすら思いつかんと

**デフォルトの名無しさん** · 2017/09/10(日) 21:55:28.82

もう仕事の手順が間違ってるわけで

**デフォルトの名無しさん** · 2017/09/13(水) 09:26:04.89

TDDでok

**デフォルトの名無しさん** · 2017/09/14(木) 12:00:39.09

>>31
手作業でテストするならそうだろうけど自動テストが当たり前の時代にその考え方は古すぎる

**デフォルトの名無しさん** · 2017/09/14(木) 12:41:22.58

>>31
いつの時代の話だよ

**デフォルトの名無しさん** · 2017/09/14(木) 14:20:12.84

時代の問題か？

設計書通りに動くこと
仕様書通りに動くこと
が時代遅れとか
掲示板のレベル下がってるな

プログラム組むのやめて田舎帰れよ
役に立たねぇ

**デフォルトの名無しさん** · 2017/09/14(木) 14:28:59.77

そうじゃないんだよなあ。読解力ガイジかよ

**デフォルトの名無しさん** · 2017/09/14(木) 20:37:17.99

>>40
ゴミクズうざ

**デフォルトの名無しさん** · 2017/09/14(木) 21:02:50.08

>>41
40とは別人だが君の読解力のほうに問題があると思うぞ
もう一度読みなおしてみようか

**デフォルトの名無しさん** · 2017/09/14(木) 21:44:39.62

>>42
は？死んで

**デフォルトの名無しさん** · 2017/09/15(金) 07:21:59.46

作成者が自分の望んだ観点しかテスト出来ないってこういうことなんだろうな

**デフォルトの名無しさん** · 2017/09/20(水) 08:59:37.11

>>39
作る前から完璧な設計・仕様が確定してる前提ってのがいつの時代の話だよってことじゃね？

**デフォルトの名無しさん** · 2017/09/20(水) 09:01:51.05

>>45
UnitTestなんて書いたことないんだろ

**デフォルトの名無しさん** · 2017/09/20(水) 10:14:42.96

>>45
作ってから何が足りないか考えさせればいいだろ
請負だろ？
途中の成果物なんて見せる必要ないで

**デフォルトの名無しさん** · 2017/09/27(水) 23:02:52.48

>>1 が言ってるテストの書き方で問題なのは中の実装を見てテストを書こうとしてるところ。そんな書き方してたら意味のあるテストなんて殆ど書けない。
大事なのはテスト対象の振る舞いを決め、その通りに動作するかどうかの観点でテストを書くこと。
例えば固定のバージョンを返すメソッドでもそれが文字列なのであればフォーマットが決まってるはず。
フォーマットが決まってなければバージョンを確認して動作を変えるようなものも作れないからね。で、フォーマットが決まってるならそのフォーマット通りの文字列を返しているかどうかのテストが書ける。
逆に言えばそのバージョンが人間が異なるかどうかの確認する為の物なだけで、プログラム上から確認するためのものではないからフォーマットなんて決まってないというのであればそんなものにテストなんて書かなくていい

**デフォルトの名無しさん** · 2017/09/28(木) 07:27:38.63

要はその関数の仕様が満たされているか確認できているかどうかということだろ
仕様が固定文字列を返すことなら固定文字列との比較が必要だし、特定フォーマットの文字列ならそのフォーマットか検査することが必要

**デフォルトの名無しさん** · 2017/09/28(木) 17:12:47.59

>>48
> >>1 が言ってるテストの書き方で問題なのは中の実装を見てテストを書こうとしてるところ。そんな書き方してたら意味のあるテストなんて殆ど書けない。
それ、君の思い込みだから

**デフォルトの名無しさん** · 2017/09/28(木) 19:37:57.44

>>50
それ、君の思い込みだから

**デフォルトの名無しさん** · 2017/09/28(木) 20:05:09.84

テストコード書けなくてバカにでもされたんだろ

**デフォルトの名無しさん** · 2017/09/29(金) 10:21:20.15

>>51
ほう、カバレッジという概念に全く意味が無いとでも？

**デフォルトの名無しさん** · 2017/09/29(金) 12:01:00.21

変更したらテスト方法変えてとかコメント入れとくんだろｗ

**デフォルトの名無しさん** · 2017/09/29(金) 12:31:48.88

>>48
ブラックボックステストとホワイトボックステストというのがあってだな

**デフォルトの名無しさん** · 2017/09/29(金) 13:38:50.44

>>53
カバレッジはテスト対象の振る舞いの定義が足りていないかの確認の為に意味がある。
カバレッジ上げるためだけに入れられたバリデーションの無いテストコードに意味はない

**デフォルトの名無しさん** · 2017/09/29(金) 13:56:55.95

>>56
> カバレッジ上げるためだけに入れられたバリデーションの無いテストコードに意味はない
「カバレッジ上げるためだけに入れられたバリデーションの無いテストコード」ではないテストコードには
意味があるだろ

論点がよくわかってないのか？
> 問題なのは中の実装を見てテストを書こうとしてるところ。そんな書き方してたら意味のあるテストなんて殆ど書けない。
が論点だ

**デフォルトの名無しさん** · 2017/09/29(金) 14:15:24.76

てか、カバレッジがなんだかわかってないのかな？

>>56
> カバレッジはテスト対象の振る舞いの定義が足りていないかの確認の為に意味がある。
「振る舞いの定義が足りていない」コードに対して、カバレッジ100%のテストをしたとしても、「振る舞いの定義が足りていない」ことには変わりない。
つまり、カバレッジはテスト対象の振る舞いの定義が足りていないかの確認の為には使えない。

**デフォルトの名無しさん** · 2017/09/29(金) 15:12:48.25

>>58
振る舞いの定義の為にテストを書いていれば自動的にカバレッジが振る舞いの定義が足りていない、もしくは無意味なコードのどちらかに絞られる。
前者であれば振る舞いを定義し、それのテストコードを書く。後者であればその無意味なコードを削除する。
”中の実装を見てテストを書く”なんて事をしていたら後者でも無意味なコードに対してテストコードを書きがち。だから意味のあるテストは殆ど書けないと言ってる。

**デフォルトの名無しさん** · 2017/09/29(金) 15:20:46.81

前者でも振る舞いを考えずに単純に内部実装のテストコードを書こうとするから無意味なテストコードになっている。 >>1 がいい例

**デフォルトの名無しさん** · 2017/09/29(金) 15:42:23.19

「無意味なコードを書く」ことがあるような人とは会話できませんわ

**デフォルトの名無しさん** · 2017/09/29(金) 16:00:17.56

>>61
そうだね。修正によってあるコード片が無意味なコードになったことすら無いような経験不足な相手に説明しても無駄だあね。

**デフォルトの名無しさん** · 2017/09/29(金) 16:31:00.49

>>62
そういう場合は、無意味になる前にそのコードに対するテストが存在していたはずで、「意味が無くなったから削除する」なら、プロダクトコードもテストコードも削除する
そもそもお前の主張だと、無意味なコードに対するテストは存在しないんだろ？

そういう話はどうでもいい
全部が意味があるプロダクトコードに対して、その実装内容に即したテストを書くことに意味があるかどうかだ

そういう場合でも、
> ”中の実装を見てテストを書く”なんて事をしていたら後者でも無意味なコードに対してテストコードを書きがち。だから意味のあるテストは殆ど書けないと言ってる。
ってことなんだろ？

それにま全く同意できない

**デフォルトの名無しさん** · 2017/09/29(金) 16:32:07.20

ホワイトボックステストはしないんですかね

**デフォルトの名無しさん** · 2017/09/29(金) 16:35:35.81

おそらくTDDのようなプロセスを想定した主張なんだろうが、TDDでも実装内容に応じて三角測量のためにテストは追加する

**デフォルトの名無しさん** · 2017/09/29(金) 16:36:42.08

どのようなテスト手法でも、意味の無いテストは意味が無い、ただそれだけのことだ

**デフォルトの名無しさん** · 2017/09/29(金) 23:50:09.53

トートロジーでドヤ顔

**デフォルトの名無しさん** · 2017/09/30(土) 00:55:55.38

>>1
app.versionの定義が1.0.0という文字列を返すことならそれで構わない
「数字.数字.数字」というフォーマットの文字列を返すのが定義ならそれを検証しなければならない
どう定義されているのかに完全に依存するので>>1の内容だけでは何とも言えない

**デフォルトの名無しさん** · 2017/10/01(日) 08:45:27.64

>>1
それでもそれやりゃ金もらえるんだから
文句言わずにやれカス

**デフォルトの名無しさん** · 2017/10/02(月) 09:50:26.11

>>69
こんなんだから日本のソフトウェア産業は糞

**デフォルトの名無しさん** · 2018/01/17(水) 19:51:14.43

DBのテストの場合:
(1) テストデータを乱数で生成
(2) 順列・組み合わせを応用して機械的にデータを作って食わせる

**デフォルトの名無しさん** · 2018/02/12(月) 13:35:07.77

意味が無いことを確認するためにテストしてみよう（提案

**デフォルトの名無しさん** · 2018/02/16(金) 06:00:50.23

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**デフォルトの名無しさん** · 2018/05/23(水) 20:44:34.37

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

2AQDM

**デフォルトの名無しさん** · 2018/07/05(木) 01:08:33.06

REB

**デフォルトの名無しさん** · 2020/01/29(水) 17:14:35.66

新人クン「判りやすくするためにコメント付けただけだから意味の無いテストなんて不要です」

#!/usr/bin/python
↓
###########
#!!○○処理!!
###########
#!/usr/bin/python

**デフォルトの名無しさん** · 2022/03/24(木) 00:50:39.01

【画像】俺くん、字が上手すぎるｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
https://mi.5ch.net/test/read.cgi/news4vip/1648047195/
57 以下、5ちゃんねるからVIPがお送りします[] 2022/03/24(木) 00:43:13.864 ID:6YrwkZDPd
http://o.5ch.net/1xk4i.png

**デフォルトの名無しさん** · 2022/03/24(木) 00:51:50.74

>>77
意味がないレスをするな

**デフォルトの名無しさん** · 2022/04/25(月) 18:44:01.58

アフィスレ

**デフォルトの名無しさん** · 2022/04/25(月) 18:44:38.40

てす

**デフォルトの名無しさん** · 2022/04/25(月) 18:45:04.01

てすてす

**デフォルトの名無しさん** · 2022/04/25(月) 18:46:13.33

てすてすてすてすてす

**デフォルトの名無しさん** · 2023/12/06(水) 11:49:27.31

意味が無いテストをしていたのか
それともテストすらしていなかったのか

全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/

**デフォルトの名無しさん** · 2024/03/19(火) 09:58:18.84

CPUの64ビット化は単にレジスターが2倍になるだけじゃなくて、コード最適化の際にパディングが挿入されてて
予想以上にメモリ食う時があるからな。
　特に移行サーバーはハードスペックもテストもコストが低く見積もられがち。

**デフォルトの名無しさん** · 2024/11/12(火) 12:19:47.43

>>83
なんか他山の石としなきゃならないんだろうが詳細設計書を熟読しなきゃならない保守とかやりたくねえな

**デフォルトの名無しさん** · 2024/11/12(火) 15:45:35.46

しかも更新されて差分追いかけるとかだと死ねる

**デフォルトの名無しさん** · 2025/04/06(日) 11:18:18.45

nop() {}

test_nop {
　nop(); #何もしないことを確認
}