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

2017/09/09(土) 15:31:54.82ID:al+wrNfN
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.95ID:hfmQ7RMB
どっかユーザの目に入るところにバージョンでるなら意味あるんじゃね?
2017/09/09(土) 17:25:35.09ID:5TYgeUeA
その前に意味のないコードを入れるな
意味があるならその意味に沿ってちゃんとテストすべき
2017/09/09(土) 20:10:39.54ID:GB2h7YGf
その前に意味のないスレを立てるな
5デフォルトの名無しさん
垢版 |
2017/09/09(土) 20:49:02.98ID:al+wrNfN
意味がないテストっていうのは他にも有るな。
例えばテンプレートの適用結果をテストするとかな

HTML生成のためのテンプレートがあって、
テンプレートファイルを手書きして(ここまでは普通)
そのテンプレートに値を入れたHTMLをテストとして手書きする(アホ)
2017/09/09(土) 21:17:51.67ID:al+wrNfN
正規表現バリデーションのテストも大概意味がない。
正規表現がものすごく複雑っていうのなら話は別だが、
/^[0-9]+$/ みたいに書いてあるものに対して
数字以外入れたらエラーになることを確かめるテストはいらない
2017/09/09(土) 21:23:57.43ID:al+wrNfN
まあ正規表現バリデーションのテストに関して言えば、
正規表現を直接書くのではなく、numonlyなどというメソッドを作るべき。
そのnumonlyのテストを書くのは少しは意味がある。

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

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

SQLのcreate table文で、priceの項目をintegerと書いて
そのテストコードで、create table文のpriceがintegerであること
とテストすることに何の意味があるのだろうか
2017/09/09(土) 23:25:06.47ID:al+wrNfN
あー、関係ない所でアイデア思いついたわ

一部でテストのことをスペックと呼ぶ文化が有るだろ?
変数の型とかバリデーションとか
コードに書かないでスペックに書けば良いんじゃね?
2017/09/10(日) 02:59:20.70ID:CfAD8p5O
>>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.77ID:CfAD8p5O
>>6
バリデーションのテストは
「ある項目に数字以外を入れたらエラーになる」という
仕様を満たしているかどうかのテストであって正規表現のテストをするわけではない
実装が正規表現である必要もない
2017/09/10(日) 03:16:10.29ID:CfAD8p5O
>>5
それはテンプレートエンジンのテスト
テンプレートエンジンのバージョンなんかが変わっても同じ結果を取得できてるねってやつ
3rdパーティライブラリのテストだから自分の書いてるアプリのテストとは種類が違う
2017/09/10(日) 08:18:10.38ID:G4ZVCKWZ
>>9
> 今は単純文字列を返す実装だから無意味に感じるのだろうが
> リファクタして設定ファイルからバージョンを取得するようにしたり
> DBからバージョンを取得するようになったりしても
> 仕様を満たしてるかどうかを確認できる

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

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

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

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

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

そうすりゃ、getVersion() == 1.0.0
あ゛〜、バージョンが上がっちまったー、VERSIONファイルと
テストコードの両方を1.1.0に修正しなきゃーなんて
アホなメンテは必要なくなるなるわけです。
131 == 12
垢版 |
2017/09/10(日) 08:38:12.02ID:G4ZVCKWZ
>>12の考え方はすごく重要で、これを理解していないために
無意味なテストをしていることが多い。

ロジックではなくデータをテストしている。
書いたものがそう書いてあるか?だけを調べている
無意味なテストが極めて多い。
2017/09/10(日) 08:38:50.50ID:G4ZVCKWZ
つまりテストを書くときはダミーデータを使うということですね。
2017/09/10(日) 10:49:50.23ID:1MFrqOnc
ダミーだこりゃ
2017/09/10(日) 10:56:13.13ID:G4ZVCKWZ
>>10
> バリデーションのテストは
> 「ある項目に数字以外を入れたらエラーになる」という
> 仕様を満たしているかどうかのテストであって正規表現のテストをするわけではない
> 実装が正規表現である必要もない

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

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

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

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

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

自分で定義したものが(書いたものが)、自分で定義した(書いた)とおりに
なっているかなんて意味がないテストです
2017/09/10(日) 11:30:43.35ID:G4ZVCKWZ
> 自分で定義したものが(書いたものが)、自分で定義した(書いた)とおりに

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

書いたコードが書いた通り動くという話はもちろんしてない。
Aと書いたんだから、Aに決まってるだろ。レベルの話。
2017/09/10(日) 11:37:19.05ID:G4ZVCKWZ
>>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〜"

さすがににそんなことやってるやつはいないと思うがねw
2017/09/10(日) 11:42:21.70ID:G4ZVCKWZ
> テンプレートエンジンのバージョンなんかが変わっても同じ結果を取得できてるねってやつ

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

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

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

{{title}} の部分は、書いた文字そのまま返ってくるわけではなく
加工される部分だから互換性テストを行う必要はある。
だが {{title}}以外の部分は書いた文字がそのまま
返ってきているだけなのでテストする必要はない。
2017/09/10(日) 13:28:42.54ID:ZKxYrqVl
設計書書けよ
2017/09/10(日) 14:12:07.70ID:CfAD8p5O
>>16
>まあやるとしたとしても「ある項目のバリデーションがnumberOnlyであること」

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

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

このコードはテスト方法よりもテストの意図が全く伝わらないほうが大きな問題
悪い例として書いてるけど、仕様と実装の区別がついてないからこそ
議論の焦点がテストの仕様ではなくテストの実装に当たってる
2017/09/10(日) 16:08:22.02ID:G4ZVCKWZ
>>21
だから、そういうのが意味がないテストだと言ってる

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

何をテストしているのか全くわからない
2017/09/10(日) 16:09:56.35ID:G4ZVCKWZ
>>21
> 「ある項目のバリデーションがnumberOnlyであること」ってのは仕様じゃなく実装方法
> その区別がついてないから中身の無い長文を量産するんだよ

あんたは「それは違う」とだけ書いて理由を何も書いていない。
2017/09/10(日) 16:10:45.25ID:G4ZVCKWZ
つーかテストの仕様ってなんだ?
それをいうならアプリの仕様だろ
2017/09/10(日) 16:11:17.12ID:G4ZVCKWZ
あとVERSIONの話は反論なしかw
2017/09/10(日) 17:18:17.17ID:ZKxYrqVl
設計書書けよw
単体なら設計書通りに動くかどうかをテストしろよ
コード見てテストを決めようとするからそんな問題が出てくんだろが雑魚が
2017/09/10(日) 17:25:04.80ID:G4ZVCKWZ
こう言いかえれば良いんですかね?

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

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


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

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

画面の出力結果を目視で観察するぐらいなら
定義ファイルを目視で観察すれば良いのです。
自動化のためにテストコードを書くというのなら、
定義ファイルに書いて有ることをテストすれば良いのです。
numberOnlyと書いてある事。とね。
2017/09/10(日) 17:33:45.82ID:ZKxYrqVl
>>27
設計書がそうであればどんなにくだらないことでもテストしなければならないよな

これが普通の感覚だな
コードを見てテストの仕様を考えるからくだらないなんて話が出てくる
くだらなかろうがなんだろうが仕様または設計書通りに動かすことが俺らの仕事なんだよ
2017/09/10(日) 18:23:45.21ID:CfAD8p5O
>>25
「バージョン番号は1.1.1である」という仕様を満たすかどうかのテストと
getVersionメソッドがメソッド仕様どおりに動くかどうかのテストとは別物
俺が言ってたのは前者の話ね

後者のテストをしたいならメソッド仕様をまず明確にしようね
設計書書けってのと同じこと
2017/09/10(日) 18:29:29.72ID:CfAD8p5O
>>24
what to testがテストの仕様
how to testがテストの実装

>>27を読んでもwhat to testを理解してないのが分かる
2017/09/10(日) 21:25:57.68ID:LMpnnAyy
作った本人とか同じ部門内でテストコード作るのはテストじゃねぇよ最低限のバグ減らしというかチェックだろ
二重管理とかのレベルですらない

まともにテストするとこなら、仕様書、設計書をベースに絶対に設計部門以外でテストを作らなきゃボロクソに叩かれる
そうするとたとえバージョンチェックでも意味は出てくる
2017/09/10(日) 21:29:54.28ID:ZKxYrqVl
>>31
なんか複雑なインターフェースしてて思った値が返って来ないんだろ
2017/09/10(日) 21:31:19.11ID:LMpnnAyy
まったくもって>>26 の言うとおり
意味が無いとか言い訳して設計書すら書かないとかコード書いてから設計書作るやつとか
仕様合わせるとバグりまくりなんだよなぁ
2017/09/10(日) 21:37:38.91ID:LMpnnAyy
ま、やってるテストが意味ないと思うなら
テストのやり方を意味あるものにすれば良いのだがそれすら思いつかんと
2017/09/10(日) 21:55:28.82ID:ZKxYrqVl
もう仕事の手順が間違ってるわけで
2017/09/13(水) 09:26:04.89ID:SbfCQQCY
TDDでok
2017/09/14(木) 12:00:39.09ID:yiOvFiYP
>>31
手作業でテストするならそうだろうけど自動テストが当たり前の時代にその考え方は古すぎる
2017/09/14(木) 12:41:22.58ID:NPMvj+H/
>>31
いつの時代の話だよ
2017/09/14(木) 14:20:12.84ID:+X9KJHHB
時代の問題か?

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

プログラム組むのやめて田舎帰れよ
役に立たねぇ
2017/09/14(木) 14:28:59.77ID:1Cd2i0pl
そうじゃないんだよなあ。読解力ガイジかよ
2017/09/14(木) 20:37:17.99ID:+X9KJHHB
>>40
ゴミクズうざ
2017/09/14(木) 21:02:50.08ID:XVFgKdZv
>>41
40とは別人だが君の読解力のほうに問題があると思うぞ
もう一度読みなおしてみようか
2017/09/14(木) 21:44:39.62ID:+X9KJHHB
>>42
は?死んで
2017/09/15(金) 07:21:59.46ID:3dLbew77
作成者が自分の望んだ観点しかテスト出来ないってこういうことなんだろうな
2017/09/20(水) 08:59:37.11ID:G8o9DQ5K
>>39
作る前から完璧な設計・仕様が確定してる前提ってのがいつの時代の話だよってことじゃね?
2017/09/20(水) 09:01:51.05ID:dboA6E8g
>>45
UnitTestなんて書いたことないんだろ
2017/09/20(水) 10:14:42.96ID:59PsJZUl
>>45
作ってから何が足りないか考えさせればいいだろ
請負だろ?
途中の成果物なんて見せる必要ないで
48デフォルトの名無しさん
垢版 |
2017/09/27(水) 23:02:52.48ID:YYHqfTn1
>>1 が言ってるテストの書き方で問題なのは中の実装を見てテストを書こうとしてるところ。そんな書き方してたら意味のあるテストなんて殆ど書けない。
大事なのはテスト対象の振る舞いを決め、その通りに動作するかどうかの観点でテストを書くこと。
例えば固定のバージョンを返すメソッドでもそれが文字列なのであればフォーマットが決まってるはず。
フォーマットが決まってなければバージョンを確認して動作を変えるようなものも作れないからね。で、フォーマットが決まってるならそのフォーマット通りの文字列を返しているかどうかのテストが書ける。
逆に言えばそのバージョンが人間が異なるかどうかの確認する為の物なだけで、プログラム上から確認するためのものではないからフォーマットなんて決まってないというのであればそんなものにテストなんて書かなくていい
2017/09/28(木) 07:27:38.63ID:Q17St4K8
要はその関数の仕様が満たされているか確認できているかどうかということだろ
仕様が固定文字列を返すことなら固定文字列との比較が必要だし、特定フォーマットの文字列ならそのフォーマットか検査することが必要
2017/09/28(木) 17:12:47.59ID:5YSrcQS5
>>48
> >>1 が言ってるテストの書き方で問題なのは中の実装を見てテストを書こうとしてるところ。そんな書き方してたら意味のあるテストなんて殆ど書けない。
それ、君の思い込みだから
51デフォルトの名無しさん
垢版 |
2017/09/28(木) 19:37:57.44ID:NUvabez2
>>50
それ、君の思い込みだから
2017/09/28(木) 20:05:09.84ID:Up+E61c/
テストコード書けなくてバカにでもされたんだろ
2017/09/29(金) 10:21:20.15ID:w8XxzvHf
>>51
ほう、カバレッジという概念に全く意味が無いとでも?
2017/09/29(金) 12:01:00.21ID:d1b5e1Xh
変更したらテスト方法変えてとかコメント入れとくんだろw
2017/09/29(金) 12:31:48.88ID:gRPc6RlQ
>>48
ブラックボックステストとホワイトボックステストというのがあってだな
56デフォルトの名無しさん
垢版 |
2017/09/29(金) 13:38:50.44ID:FpNtbfv9
>>53
カバレッジはテスト対象の振る舞いの定義が足りていないかの確認の為に意味がある。
カバレッジ上げるためだけに入れられたバリデーションの無いテストコードに意味はない
2017/09/29(金) 13:56:55.95ID:w8XxzvHf
>>56
> カバレッジ上げるためだけに入れられたバリデーションの無いテストコードに意味はない
「カバレッジ上げるためだけに入れられたバリデーションの無いテストコード」ではないテストコードには
意味があるだろ

論点がよくわかってないのか?
> 問題なのは中の実装を見てテストを書こうとしてるところ。そんな書き方してたら意味のあるテストなんて殆ど書けない。
が論点だ
2017/09/29(金) 14:15:24.76ID:w8XxzvHf
てか、カバレッジがなんだかわかってないのかな?

>>56
> カバレッジはテスト対象の振る舞いの定義が足りていないかの確認の為に意味がある。
「振る舞いの定義が足りていない」コードに対して、カバレッジ100%のテストをしたとしても、「振る舞いの定義が足りていない」ことには変わりない。
つまり、カバレッジはテスト対象の振る舞いの定義が足りていないかの確認の為には使えない。
59デフォルトの名無しさん
垢版 |
2017/09/29(金) 15:12:48.25ID:FpNtbfv9
>>58
振る舞いの定義の為にテストを書いていれば自動的にカバレッジが振る舞いの定義が足りていない、もしくは無意味なコードのどちらかに絞られる。
前者であれば振る舞いを定義し、それのテストコードを書く。後者であればその無意味なコードを削除する。
”中の実装を見てテストを書く”なんて事をしていたら後者でも無意味なコードに対してテストコードを書きがち。だから意味のあるテストは殆ど書けないと言ってる。
60デフォルトの名無しさん
垢版 |
2017/09/29(金) 15:20:46.81ID:FpNtbfv9
前者でも振る舞いを考えずに単純に内部実装のテストコードを書こうとするから無意味なテストコードになっている。 >>1 がいい例
2017/09/29(金) 15:42:23.19ID:w8XxzvHf
「無意味なコードを書く」ことがあるような人とは会話できませんわ
62デフォルトの名無しさん
垢版 |
2017/09/29(金) 16:00:17.56ID:FpNtbfv9
>>61
そうだね。修正によってあるコード片が無意味なコードになったことすら無いような経験不足な相手に説明しても無駄だあね。
2017/09/29(金) 16:31:00.49ID:w8XxzvHf
>>62
そういう場合は、無意味になる前にそのコードに対するテストが存在していたはずで、「意味が無くなったから削除する」なら、プロダクトコードもテストコードも削除する
そもそもお前の主張だと、無意味なコードに対するテストは存在しないんだろ?

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

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

それにま全く同意できない
2017/09/29(金) 16:32:07.20ID:w8XxzvHf
ホワイトボックステストはしないんですかね
2017/09/29(金) 16:35:35.81ID:w8XxzvHf
おそらくTDDのようなプロセスを想定した主張なんだろうが、TDDでも実装内容に応じて三角測量のためにテストは追加する
2017/09/29(金) 16:36:42.08ID:w8XxzvHf
どのようなテスト手法でも、意味の無いテストは意味が無い、ただそれだけのことだ
2017/09/29(金) 23:50:09.53ID:7BTzW/1N
トートロジーでドヤ顔
2017/09/30(土) 00:55:55.38ID:DvjAVMUQ
>>1
app.versionの定義が1.0.0という文字列を返すことならそれで構わない
「数字.数字.数字」というフォーマットの文字列を返すのが定義ならそれを検証しなければならない
どう定義されているのかに完全に依存するので>>1の内容だけでは何とも言えない
2017/10/01(日) 08:45:27.64ID:QF3dVHO1
>>1
それでもそれやりゃ金もらえるんだから
文句言わずにやれカス
70デフォルトの名無しさん
垢版 |
2017/10/02(月) 09:50:26.11ID:6bX/hSXR
>>69
こんなんだから日本のソフトウェア産業は糞
71デフォルトの名無しさん
垢版 |
2018/01/17(水) 19:51:14.43ID:BNHtUGBq
DBのテストの場合:
(1) テストデータを乱数で生成
(2) 順列・組み合わせを応用して機械的にデータを作って食わせる
2018/02/12(月) 13:35:07.77ID:BUzgeysp
意味が無いことを確認するためにテストしてみよう(提案
2018/02/16(金) 06:00:50.23ID:W1XJdyx1
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
74デフォルトの名無しさん
垢版 |
2018/05/23(水) 20:44:34.37ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

2AQDM
75デフォルトの名無しさん
垢版 |
2018/07/05(木) 01:08:33.06ID:RfoszcD2
REB
2020/01/29(水) 17:14:35.66ID:MZiWsP4Y
新人クン「判りやすくするためにコメント付けただけだから意味の無いテストなんて不要です」

#!/usr/bin/python

###########
#!!○○処理!!
###########
#!/usr/bin/python
77デフォルトの名無しさん
垢版 |
2022/03/24(木) 00:50:39.01ID:SMpQCEvG
【画像】俺くん、字が上手すぎるwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
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
78デフォルトの名無しさん
垢版 |
2022/03/24(木) 00:51:50.74ID:MV6zBxE3
>>77
意味がないレスをするな
79デフォルトの名無しさん
垢版 |
2022/04/25(月) 18:44:01.58ID:IyR8mDVM0
アフィスレ
80デフォルトの名無しさん
垢版 |
2022/04/25(月) 18:44:38.40ID:IyR8mDVMM
てす
81デフォルトの名無しさん
垢版 |
2022/04/25(月) 18:45:04.01ID:IyR8mDVMM
てすてす
82デフォルトの名無しさん
垢版 |
2022/04/25(月) 18:46:13.33ID:IyR8mDVM
てすてすてすてすてす
83デフォルトの名無しさん
垢版 |
2023/12/06(水) 11:49:27.31ID:oM0gjrfW
意味が無いテストをしていたのか
それともテストすらしていなかったのか

全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/
2024/03/19(火) 09:58:18.84ID:rlbm+a6A
CPUの64ビット化は単にレジスターが2倍になるだけじゃなくて、コード最適化の際にパディングが挿入されてて
予想以上にメモリ食う時があるからな。
 特に移行サーバーはハードスペックもテストもコストが低く見積もられがち。
2024/11/12(火) 12:19:47.43ID:69VI/kA5
>>83
なんか他山の石としなきゃならないんだろうが詳細設計書を熟読しなきゃならない保守とかやりたくねえな
2024/11/12(火) 15:45:35.46ID:3FuqnzdR
しかも更新されて差分追いかけるとかだと死ねる
2025/04/06(日) 11:18:18.45ID:oysqtjOc
nop() {}

test_nop {
 nop(); #何もしないことを確認
}
レスを投稿する