意味がないテストをするな。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/09(土) 16:54:48.95

どっかユーザの目に入るところにバージョンでるなら意味あるんじゃね？

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

その前に意味のないコードを入れるな
意味があるならその意味に沿ってちゃんとテストすべき

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

その前に意味のないスレを立てるな

**デフォルトの名無しさん** · 2017/09/09(土) 20:49:02.98

意味がないテストっていうのは他にも有るな。
例えばテンプレートの適用結果をテストするとかな

HTML生成のためのテンプレートがあって、
テンプレートファイルを手書きして（ここまでは普通）
そのテンプレートに値を入れたHTMLをテストとして手書きする（アホ）

**デフォルトの名無しさん** · 2017/09/09(土) 21:17:51.67

正規表現バリデーションのテストも大概意味がない。
正規表現がものすごく複雑っていうのなら話は別だが、
/^[0-9]+$/ みたいに書いてあるものに対して
数字以外入れたらエラーになることを確かめるテストはいらない

**デフォルトの名無しさん** · 2017/09/09(土) 21:23:57.43

まあ正規表現バリデーションのテストに関して言えば、
正規表現を直接書くのではなく、numonlyなどというメソッドを作るべき。
そのnumonlyのテストを書くのは少しは意味がある。

だけど、このフィールドはnumonlyになっているか？という
確実にテストは必要ない。

SQLのスキーマのテストしてるようなもんだよ。

SQLのcreate table文で、priceの項目をintegerと書いて
そのテストコードで、create table文のpriceがintegerであること
とテストすることに何の意味があるのだろうか

**デフォルトの名無しさん** · 2017/09/09(土) 23:25:06.47

あー、関係ない所でアイデア思いついたわ

一部でテストのことをスペックと呼ぶ文化が有るだろ？
変数の型とかバリデーションとか
コードに書かないでスペックに書けば良いんじゃね？

**デフォルトの名無しさん** · 2017/09/10(日) 02:59:20.70

>>1
>function getVersion() { return '1.1.0' }
>expect(app.getVersion()).to.be '1.1.0'

バージョンアップのたびにテストコードを変更してメンテするのは微妙すぎるだろ
そうじゃなく、そのバージョン用のテストスイートを書いてるのであればその種のテストにも十分意味がある
(例えば1.0系のテストと1.1系のテストを並列でメンテしてる場合)

今は単純文字列を返す実装だから無意味に感じるのだろうが
リファクタして設定ファイルからバージョンを取得するようにしたり
DBからバージョンを取得するようになったりしても
仕様を満たしてるかどうかを確認できる

テストが不要なくらい明白な実装かどうかを
毎回判断しながらテストケースを管理することのほうが意味がない

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

>>6
バリデーションのテストは
「ある項目に数字以外を入れたらエラーになる」という
仕様を満たしているかどうかのテストであって正規表現のテストをするわけではない
実装が正規表現である必要もない

**デフォルトの名無しさん** · 2017/09/10(日) 03:16:10.29

>>5
それはテンプレートエンジンのテスト
テンプレートエンジンのバージョンなんかが変わっても同じ結果を取得できてるねってやつ
3rdパーティライブラリのテストだから自分の書いてるアプリのテストとは種類が違う

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

>>9
> 今は単純文字列を返す実装だから無意味に感じるのだろうが
> リファクタして設定ファイルからバージョンを取得するようにしたり
> DBからバージョンを取得するようになったりしても
> 仕様を満たしてるかどうかを確認できる

重要なのはなにをテストしているのかをきっちり理解することですよ

バージョン番号が書いてあるところがファイルでも変数でも関係ないですが、
1.0.0と書いたものが、1.0.0であることをテストしたいのか？
それとも、バージョン番号が正しく取得できることをテストしたいのか？

1.0.0と書いたものが1.0.0であることとかアホらしいですよねｗ
そう書いたんだから、そう取得できるのは当たり前
これは単なるデータの二重管理に過ぎません。

重要なのは、バージョン番号が正しく取得できることなのですよ。
具体的なデータ（バージョン番号）はダミーデータで十分です。

まずテストコードでそのダミーデータ（例えば0.0.1）を
変数なり、ファイルなり、DBなりに格納します。
そしてそれがgetVersion()で正しく取得できることテストするのです。

そうすりゃ、getVersion() == 1.0.0
あ゛～、バージョンが上がっちまったー、VERSIONファイルと
テストコードの両方を1.1.0に修正しなきゃーなんて
アホなメンテは必要なくなるなるわけです。

**1 == 12** · 2017/09/10(日) 08:38:12.02

>>12の考え方はすごく重要で、これを理解していないために
無意味なテストをしていることが多い。

ロジックではなくデータをテストしている。
書いたものがそう書いてあるか？だけを調べている
無意味なテストが極めて多い。

**デフォルトの名無しさん** · 2017/09/10(日) 08:38:50.50

つまりテストを書くときはダミーデータを使うということですね。

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

ダミーだこりゃ

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

>>10
> バリデーションのテストは
> 「ある項目に数字以外を入れたらエラーになる」という
> 仕様を満たしているかどうかのテストであって正規表現のテストをするわけではない
> 実装が正規表現である必要もない

はい、そのとおりですね。

処理をしているのが正規表現であるかそれ以外のコードであるかは関係ない。
だからここでやるべきことはnumberOnlyという関数を作ること
そしてそのnumberOnlyが仕様を満たしているかどうか？のテストです。
これは入念にテストする必要があるでしょう。

もしてテストしなければいけない（？）項目はもう一つ残っていますね？
numberOnlyのバリデーションが設定されている項目はpriceだけではなく
sizeやcountなどもいくつもあるでしょう。

それらの数値項目が10個あったとき、10個全てに
numberOnlyでやったのと同じ入念なテストは必要ないのですよ。

まあやるとしたとしても「ある項目のバリデーションがnumberOnlyであること」
ぐらいでしょうが、これもまさに項目のバリデーションにnumberOnlyと
書いたんだから当然numberOnlyに決まってるだろという
データの二重管理にすぎない問題になるわけですよ。

自分で定義したものが（書いたものが）、自分で定義した（書いた）とおりに
なっているかなんて意味がないテストです

**デフォルトの名無しさん** · 2017/09/10(日) 11:30:43.35

> 自分で定義したものが（書いたものが）、自分で定義した（書いた）とおりに

勘違いされそうだから補足しておくと、
書いたものが書いたとおりになるっていうのはデータの話な
プログラマによる処理が一切なく、加工されずに
そのまま結果となるようなもの

書いたコードが書いた通り動くという話はもちろんしてない。
Aと書いたんだから、Aに決まってるだろ。レベルの話。

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

>>11
> それはテンプレートエンジンのテスト
> 3rdパーティライブラリのテストだから自分の書いてるアプリのテストとは種類が違う

テンプレートエンジン自身のテストは
テンプレートエンジン開発側で行ってる

自作のテンプレートエンジンの話は別
「3rdパーティライブラリのテスト」と書いてあるから
その点は同意取れていると思うが

俺が言ってるのは具体例を出すと以下のようなテンプレートファイルがあった時
<html>
　<head>
　　<title>{{title}}</title>
　</head>
<body>
　　数十行のコード
　</body>
</html>

テストコードの中に、このテンプレートにtitleの値を埋め込んだ、以下のようなテストを書く意味は無いってこと

expect(template('file.tmpl.html', {title: 'タイトル'})).to.be "<html>\n　<head>\n　　<title>タイトル</title>\n～"

さすがににそんなことやってるやつはいないと思うがねｗ

**デフォルトの名無しさん** · 2017/09/10(日) 11:42:21.70

> テンプレートエンジンのバージョンなんかが変わっても同じ結果を取得できてるねってやつ

これは自分の書いたコードのテストではなく互換性のテスト。

互換性のテストは通常サードパーティ側でやってるはずだが
信じられないのであれば自分でやる必要があるかもしれない。
だがその場合でも>>18のようなテストは不要

なぜならダミーデータでテストすればいいからだ。
この場合 {{ }} の仕様に互換性があることをテストするために
テンプレートファイルの中身は {{title}} この一行で良い
>>18のような長ったらしいHTMLテンプレートファイルを使って
互換性テストをやる必要はない。

{{title}} の部分は、書いた文字そのまま返ってくるわけではなく
加工される部分だから互換性テストを行う必要はある。
だが {{title}}以外の部分は書いた文字がそのまま
返ってきているだけなのでテストする必要はない。

**デフォルトの名無しさん** · 2017/09/10(日) 13:28:42.54

設計書書けよ

**デフォルトの名無しさん** · 2017/09/10(日) 14:12:07.70

>>16
>まあやるとしたとしても「ある項目のバリデーションがnumberOnlyであること」

分かってる風で分かってないね
「ある項目のバリデーションがnumberOnlyであること」ってのは仕様じゃなく実装方法
その区別がついてないから中身の無い長文を量産するんだよ

>expect(template('file.tmpl.html', {title: 'タイトル'})).to.be "<html>¥n　<head>¥n　　<title>タイトル</title>¥n～"

このコードはテスト方法よりもテストの意図が全く伝わらないほうが大きな問題
悪い例として書いてるけど、仕様と実装の区別がついてないからこそ
議論の焦点がテストの仕様ではなくテストの実装に当たってる

**デフォルトの名無しさん** · 2017/09/10(日) 16:08:22.02

>>21
だから、そういうのが意味がないテストだと言ってる

コードを実装して、その実装したコードを
テストコードから実行すれば
テストOKとかやってるやつが多い

何をテストしているのか全くわからない

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

>>21
> 「ある項目のバリデーションがnumberOnlyであること」ってのは仕様じゃなく実装方法
> その区別がついてないから中身の無い長文を量産するんだよ

あんたは「それは違う」とだけ書いて理由を何も書いていない。

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

つーかテストの仕様ってなんだ？
それをいうならアプリの仕様だろ

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

あとVERSIONの話は反論なしかｗ

**デフォルトの名無しさん** · 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と書いてある事。とね。