TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
☆★Java質問･相談スレッド181★★
関数型プログラミング言語Haskell Part31
【実験台】 Python 3.0 のお勉強 Part 1 【非互換】
Lisp Scheme Part40
ねえ、これ僕間違ってる？
くだすれDelphi(超初心者用)その57
スレ立てるまでもない質問はここで 153匹目
【魔法】リリカル☆Lisp【言語】
HelloWorld集めようぜ
Androidプログラミング質問スレ revision53
テストしにくいコードをテストする方法 その2
- 1 ：2017/01/03 〜 最終レス ：2020/06/14
- ここで言うテストっていうのは
ユニットテストみたいなものね。
人間がぽちぽち操作してやるテストじゃありません。
前スレ テストしにくいコードをテストする方法教えて下さい
http://echo.2ch.sc/test/read.cgi/tech/1334408391/
- 2 ：
- 例で考えよう。
private function numberOfFeet(動物) returns 脚の数
{
if (動物 == 人) { return 2 }
if (動物 == 犬) { return 4 }
if (動物 == 猫) { return 4 }
raise exception 知らない動物
}
っていう関数が既にあるとする。
- 3 ：
- その関数で対応する動物がもっと増えたとしよう。
private function numberOfFeet(動物) returns 脚の数
{
if (動物 == 人) { return 2 }
if (動物 == 犬) { return 4 }
if (動物 == 猿) { return 4 }
if (動物 == キジ) { return 2 }
if (動物 == 猫) { return 4 }
：
：
raise exception 知らない動物
}
いよいよ複雑になってきた。privateなnumberOfFeetをテストしたい。
となってきたら、設計が悪いって話なんだよ。
そもそもこの関数のテストはどうするか？ ↓このようにやるか？
assert( numberOfFeet(人) == 2 )
assert( numberOfFeet(犬) == 4 )
assert( numberOfFeet(猿) == 4 )
：
あほらしい。これは実行コードの内容を単純に変換してテストコードに転記したにすぎん。
新たに対応する動物が増えたら、それに対応するコードを追加するだけの単純作業
いったいなんの意味があるというのか。
そこ（実行コード）にそう書いてあるんだから関数の実行結果はあきらかではないか。
カバレッジを100%にするためには必要？
それは "設計が悪いから" こうするしかなくなってしまってるんだよ
- 4 ：
- private関数がテストしたいと思ってきたら設計が悪いという話だったね。
この場合は、このprivate function numberOfFeetを
publicにしてテストするのではなくて設計を変えるってことだよ。
もちろんやり方はいくつもある。もっともシンプルな解決方法ではないが
今回はヘルパークラスを作る方法で解決してみようか。
LookupTableクラスというものを作る。
このクラスは特定のキーを元に特定の値を返すクラスだ。
newの引数で対応するキーと値の組み合わせを渡すことができる。
lookup_table = new LookupTable({a: 1, b: 2, c: 3})
さて、このLookupTable・・・のテストを書くとき、
動物が増えたら？などということを考える必要はない。
LookupTableは汎用的なクラスなのだからそこに動物は出てこないからだ。
では使う側はどうなるか？
data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
numberOfFeet = new LookupTable(data)
こういうコードを書くだろう。
テストはどうする？ ・・・答えは "不要" だ。
なぜならばLookupTableのテストはすでに書いているからだ。
おそらくこのコードは別のテストコード時に最低1回は通るだろう。
それでカバレッジは100%になる。いくら動物が増えたとしても
そのdataというデータ定義の行は通るのでカバレッジは100%のままだ。
- 5 ：
- これを手抜きやずるいやり方だと思うか？
元の設計のテストというのはデータが増えれば対応するテストを
増やすだけという単純作業だっただろう？
こんなのそもそもやる意味がない
データが変われば、それに応じて答えは変わる。
それだけのことだろう。
こういうのは、そもそもやらなくていいんだよ。
変数aに1を入れました。これ対応する変数aは1であるか？という
テストコードを書く意味はない。
テストすべき対象は実行するコードであってデータ定義はテストしない。
LookupTableという汎用的なクラスを作ることで実行するコードの中から
データ定義を分離させることで、少ないテストパターンでカバレッジ100%にしながら
テストコードを書くことができる。それが可能な設計に変更したからだ。
ということで、 テストしたくなってしまった
private function numberOfFeetは
悪い設計を正すことで存在が消えました。
ということでおしまい。
- 6 ：
- プログラム設計の善し悪しとテスト技法は密接に関係している。
というかprivate関数をテストする言語特有の裏技的テクニックは
テスト技法ではないんだがな。
プログラム設計が悪いと、テストが難しくなったりできなくなったりする。
private関数のテストもその一つで、private関数がテストしたいほど
複雑になったら、それは設計が悪いということだよ。
こういうのはprivateのまま頑張ってテストするんじゃなくて、
単純にpublicに変えるのでもなくて、
汎用的な処理をヘルパークラスや親クラスとして抽出する
テストしづらい → 設計が悪い → 設計を直す → テストを書く
こういう流れでなくてはいけない。
話は少し変わるが、設計を直すその途中で作成するリファクタリングを
するためだけに用いる一時的なテストコードに名前をつけたいね。
本来であればテストしづらいコードであってもテストコードは
あってしかるべきなんだが、多くの場合悪い設計のコードにテストコードはない。
だから新たにテストコードを追加する。しかしこのテストコードは
リファクタリング後にすぐにメンテナンスして、違う形になる。
だから一時的なテストコードになるんだよね。
- 7 ：
- あ、そうそう
リファクタリングを行うための一時的なテストコードであれば
単純にprivateをpublicに変えたり
private関数のテストコードを書くのもありだから。
このprivate関数へのテストはリファクタリングをしたあとの
テストコードのメンテナンスでなくなるという前提であれば
一時的にprivate関数へのテストコードを書くのはあり。
- 8 ：
- https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#testing-private-code
Testing Private Code
If you change your software's internal implementation,
your tests should not break as long as the change is not observable by users.
Therefore, per the black-box testing principle, most of the time you should test your code through its public interfaces.
If you still find yourself needing to test internal implementation code, consider
if there's a better design that wouldn't require you to do so. If you absolutely
have to test non-public interface code though, you can.
プライベートコードのテスト
あなたのソフトウェアの内部実装を変更した場合、変更がユーザによって観察されない限り、
テストは中断されるべきではありません。 したがって、ブラックボックスのテストの原則に従って、
ほとんどの場合、パブリックインターフェイスを使用してコードをテストする必要があります。
依然として内部実装コードをテストする必要がある場合は、そうする必要のない
優れた設計があるかどうかを検討してください。 しかし、非公開のインターフェイスコードを
絶対にテストしなければならない場合は、できます。
- 9 ：
- 「privateだからテストしてはいけない」という意見はそもそも的外れで
テストすべきものがprivateという状態ができたら
それは設計がおかしいと気づかないといけない。
「privateだからテストしてはいけない」は単なる思考停止で
privateをテストしたいのは設計がまずいからだね、設計をなおそう。
という流れにならなければいけない。
- 10 ：
- http://higelog.brassworks.jp/1941
テストコードにもリファクタリングが必要
・昔はテストコードがメンテ対象であるという意識が薄かった
・見てすぐ分かるテストコードがよいという考えからコピペコードが非常に多かった
・テストコードがたくさんあることによって動きが取りづらくなり、変更コストも上がる
・素早く動きたいがためにTDDしているのにそんな皮肉な結果になってしまう
・たくさん書くのではなく必要十分書くことが大切
・書き散らすと「テストケース爆発」を起こす
・テストコードもメンテし続けるためにリファクタリングして行く必要がある
- 11 ：
- http://dev.classmethod.jp/testing/10_errors_about_unit_testing/
> 3.テスト対象が完璧な設計であるという勘違い
>
> ユニットテストを実践することによりプロダクションコードが
> 適切に修正されていく状態でなければなりません。
>
> ユニットテストの重要な目的のひとつに「テスト対象クラスやメソッドの
> 使用感を把握する」ことがあります。机上の設計やフィーリングだけで
> 書いたコードは、使ってみての違和感や使いにくさに気付き難いものです。
> それらの使用感は、実際に利用してみてはじめて気付きます。
> だから、テストコードを書くことで実際に利用してみます。これはサンプルコードを書く事に他なりません。
>
> サンプルコードを書くと、「これは使いにくい」と感じたり、
> 「これはこうした方が使いやすい」と感じたりします。それはユニットテストの
> 大きな効果です。もし、使いにくいと感じたならば、すぐにテスト対象を修正します。
> テスト対象が完璧な設計で変更する余地が全く無い、または変更し
- 12 ：
- これも関連する話。まずリファクタリング後にテストを変更するのは当然
まず対象のクラスに対してテストを書く。そしてリファクタリングをする。
この時、汎用的な処理をヘルパークラスや親クラスとして抽出する。
ここまででテストを変更することはないが、
次に対象のクラスにあったテストのうち、ヘルパークラスや親クラスに分離したものは、
対象のクラスのテストではなくて、ヘルパークラスや親クラスのテストとして移動する
ヘルパークラスや親クラスでテストしている内容を、
それを使用している対象クラスでもやる必要はない。
具体的に言うと、あるモデル、例えばUserモデルクラスにsaveメソッドを作ったのであれば
そのsaveメソッドのテストを書くのは当然だが、そのsaveメソッドが親クラス
（例えばRailsで言えばActiveRecord::Baseクラス）にあるものならば、
Userモデルクラスでsaveメソッドのテストをする必要はない。
こうやってヘルパークラスや親クラスに処理を移動して、それに対するテストを書くことで
それを使用している部分ではテストが不要という状態を作り上げることが重要
- 13 ：
- privateメソッドに対してテストをしたくなっったら
それはクラスが肥大化してる証拠だよ。
まず前提としてprivateメソッドなんてものは
ほとんど必要ありません。
長い処理があったとして、その中で汎用的な処理を
抜き出していったら、コードは短くなります。
短いのだからprivateな関数にするまでもありません。
それでもprivateメソッドが残ったとしたら
それはヘルパーメソッドとして別クラスに分離する。
別クラスの関数を呼ぶのだから、必然的にそのメソッドはpublicになる
そうすりゃそのメソッドだけでテストかけるだろう？
privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。
- 14 ：
- ある程度埋めないと落ちるといわれたので、
前スレのハイライト（笑）をコピペ
- 15 ：
- なめてんの？
- 16 ：
- >>13
>privateメソッドをテストしたいっていうのは、作り方が悪いんだよ。
バカ丸出し。
privateメソッドだからといって十分にunit testingしない奴は頭が悪いんだよw
privateメソッドがあるからといって設計のせいにするのは性格が歪んでんだよw
privateメソッドをテストする技術を持たないからといって
出鱈目な ”あるべき論” を捏造する奴は技術者としての道徳が欠如してるんだよw
- 17 ：
- >>16
お前日本語がわかってないなｗ
- 18 ：
- privateメソッドとテストに相関はありません
リファクタリングのスレに移動してください
- 19 ：
- >>13
馬鹿丸出し
頭固すぎ
- 20 ：
- >>9
> テストすべきものがprivateという状態ができたら
> それは設計がおかしいと気づかないといけない。
という思考停止にきづかない馬鹿pgr
- 21 ：
- 当のKentは ID:f6cee8Pv みたいな教条主義とは対極にいるんだがな。
- 22 ：
- >>21
どこが？
https://twitter.com/kentbeck/status/3579860805
2chのレスだけで知ったかぶってる、まさに半可通
この手のクズは他分野でも同様なのだろうが、
本も読まず、手も動かせない人間なんて、
職人気質なTDD実行側の人間が、一番嫌うタイプだぞ
- 23 ：
- むしろつまみ食いしかしてないくせに、拡大解釈して腐ったコード撒き散らすな
ケントベックはXPは熟練者が必要とは言ってるだけで、手法は何でも良いなんて言ってない
テストコードも、trivialな物は不要、複雑なprivateメソッドは設計が悪いと一蹴してる
これを教条主義だと言うなら、レッテル張る事しかできない屑だな
- 24 ：
- 前スレでprivateメンバーしか見ずにそれをテストしようとしたり、考え方がおかしい。
あと、Kent Beckはテストは不要だと思ったらやらない、と言うぐらい柔軟な思考の持ち主だぞ
- 25 ：
- 前スレ埋めてからやってくれ。
- 26 ：
- >>23
> 複雑なprivateメソッドは設計が悪いと一蹴してる
ソースは？
>>22のtweetがそれだとしたら、その会話の流れが設計の善し悪しであることを示す他のtweetも示せ
- 27 ：
- Kent BeckはImplementation Patternsの中でこう言ってる
* Inner Class
* Bundle locally useful code in a private class.
* Method Visibility
* Make methods as private as possible.
* Helper Method
* Create small,private methods to express the main computation more succinctly.
別に、private classやprivate methodを否定しているわけではない
- 28 ：
- 公開する必要のないprivateメンバーをpublicにしてまでテストするなんて真逆の発想なんだよなぁ
- 29 ：
- >>28
まあ、そのprivateメソッドが、所属するクラスと直交していて再利用可能な内容だった場合は
別クラスにpublicメソッドとして切りだすのもいいけど、いつでもそうとは限らないからな
- 30 ：
- ぷ
- 31 ：
- 飽きてきたので以降privateの話題禁止
- 32 ：
- >>27
レスをよく読め文盲め
言ってもいない事を言ったかのように叩くやつがあるか
- 33 ：
- >>26
勝手に追えばいいだろ
くだらない人種だな
- 34 ：
- 結局世界的有名人であるKent Beckが言ってることは
>>1がまとめたとおり。
privateメソッドをテストしようと思った時点で、
そのprivateメソッドは設計が悪いということ。
悪い設計を直す過程でpublicになる。
設計を直さなないで単にpublicに変更するのは間違い。
- 35 ：
- >>34
まだそんなこと言ってんの？ばかだなあw
- 36 ：
- そこで#define private publicですよ。え？
- 37 ：
- publicメソッドしかテストできない道具を使ってprivateメソッドをテストすることはできない。
一種のトートロジーだな。
- 38 ：
- 前スレ埋めてからやれ
こういう奴らが糞コードを放りっぱなしにしていってこっちが掃除しなくちゃならなくなるんだよ
バグ解析依頼されて見てみたら、意識だけ高いけどそのまま放置されたゾンビコードに当たったときの腹立たしさって
まあお前らのおかげでちょっといい飯が食えるんだから感謝しないといけないな
- 39 ：
- >>35
悔しいなら反論しろよｗ
- 40 ：
- 今現在を占う 2017/1/7 19:21
おみくじ 大吉 → ♌ 獅子座
. 吉 → ♈ 牡羊座 ♋ 蟹座 ♓ 魚座
. 中吉 → ♏ 蠍座
. 小吉 → ♉ 牡牛座 ♍ 乙女座 ♎ 天秤座 ♒ 水瓶座
. 末吉 → ♊ 双子座
. 凶 → ♐ 射手座
. 大凶 → ♑ 山羊座
- 41 ：
- 吉だぜ、いやっほーい
- 42 ：
- あ、昨日か.....
- 43 ：
- 今現在を占う 2017/1/9 20:16 （不定期テスト）
おみくじ 大吉 → ♍ 乙女座 ♑ 山羊座
. 吉 → ♉ 牡牛座 ♎ 天秤座 ♒ 水瓶座
. 中吉 → ♋ 蟹座
. 小吉 → ♈ 牡羊座 ♏ 蠍座
. 末吉 → ♌ 獅子座
. 凶 → ♊ 双子座 ♐ 射手座
. 大凶 → ♓ 魚座
- 44 ：
- あんまり可視性でグダグダ言っても揉め事しか起こらん印象は有る。
だからあんまりカプセル化周りの議論は好きではない。
重要なのはテストするコードの粒度じゃないかね。
3 のレベルのコードをテストするのは粒度が細かすぎる。
3のコードを呼んで何かしてるコードのテストコードを書くべきなんだろう。
- 45 ：
- 端折って網羅性が確保できなくなるのであればそもそもこのテスト自体イラネーってのあるよ
だからやるなら機械的に全部やるかそもそもやらないかのどっちかになると思う
- 46 ：
- あ、Visual Studioのユニットテスト的な話ね
- 47 ：
- >>46
2017のlive unit testのことを言ってる？
- 48 ：
- >>44
しょうがないよ、ID:f6cee8Pvの能力ではそこが限界・・・
- 49 ：
- >>48
呼んだか？
何か言いたいことがあるなら言ってみな。
今のところ俺の書き込みに論理的に反論している
文章は存在していない。
- 50 ：
- テスト
○○○●○○○○○○○○●○○○○○○○○●
○○○●○○○○○○○○●○○○○○●●●●●●●
○○○●○○○○○●●●●●●●○○●○○○○○●
○●○●○●○○○○●○○○●○○○○●●●●●○
○●○●○●○○○○●○○○●○○○○○○○●○○
○●○●○○●○○○○●○●○○○○○○○●○○○
○●○●○○●○○○○●○●○○○○●●●●●●●
●○○●○○●○○○○○●○○○○○○○○●
○○○●○○○○○○○●○●○○○○○○○●
○○○●○○○○○○●○○○●○○○○○○●
○○●●○○○○○●○○○○○●○○○○●●
○○○○○○○●○○○○○○○○○○○○○○○○●○○○○○○○○○○○○○○○○●
○○○○○○○●○○○○○○○○○○○○○○○○●○○○○○○○○○○●●●●●●●●●●●●●●
○○○○○○○●○○○○○○○○○●●●●●●●●●●●●●●●●○○●○○○○○○○○○○○○●
○○○○○○○●○○○○○○○○○○○○○●○○○○○○●○○○○○○●○○○○○○○○○○○○●
●●●●●●●●●●●●●●●●○○○○○●○○○○○○●○○○○○○○○●●●●●●●●●●
○○○○○○○●○○○○○○○○○○○○○●●○○○○●●○○○○○○○○○○○○○○○●●
○○○○○○●●●○○○○○○○○○○○○○●○○○○●○○○○○○○○○○○○○○○●●
○○○○○○●○●○○○○○○○○○○○○○●●○○●●○○○○○○○○○○○○○●●
○○○○○○●○●●○○○○○○○○○○○○○●○●●○○○○○○○●●●●●●●●●●●●●●●●
○○○○○●●○○●○○○○○○○○○○○○○○●●○○○○○○○○○○○○○○○●
○○○○○●○○○●●○○○○○○○○○○○○●●●●○○○○○○○○○○○○○○●
○○○○●●○○○○●●○○○○○○○○○○●●○○●●○○○○○○○○○○○○○●
○○○●●○○○○○○●●○○○○○○○○●●○○○○●●○○○○○○○○○○○○●
○○●●○○○○○○○○●●○○○○○●●●○○○○○○●●●○○○○○○○○○○●
●●●○○○○○○○○○○●●●○●●●○○○○○○○○○○●●●○○○○○○●●●
- 51 ：
- >>48
お前ってプログラムに限らずいつも的はずれな難癖しかつけないよな
- 52 ：
- >>49
>>27に論理的な反証があるだろw
ほんとに頭悪いのな
Kentの書いてる英語のとこだけ読み直してお前自身の矛盾に気がつけないの？
- 53 ：
- >>52
前スレでもそうだったけど、彼は都合の悪いレスは目に入らない人だから何言っても無駄
- 54 ：
- >>52
それのどこが論理的な反証？
今の話はprivateメソッドのテストの話で、
privateメソッドが良いかダメかの話はしてない
Kent Beckのどこにprivateメソッドの話が書いてあるんだ？
- 55 ：
- くすくす…
- 56 ：
- 残念な頭だな
- 57 ：
- 反論お待ちしてまーすｗ
- 58 ：
- Kentの引用読んでも矛盾に気づけない残念さ
ひとりだけ斜め上
- 59 ：
- 時間が相手勘違いされかねんから俺の意見を書いておくか
まずprivateメソッドはpublicメソッドを通してテストするもの
（この時点でprivateメソッドの存在は否定してない）
もしprivateメソッド単体でテストしたいと思ったら
それは設計がまずいということ、設計を見直したら自然にpublicになる。
（privateをpublicに変えるだけではない。それは設計変わっていない）
そうすればpublicメソッドをテストすれば良くなる。
- 60 ：
- >>58
俺の意見とどう矛盾するのか言ってみな
- 61 ：
- 脳が単純だから単純な考え方に縋っちゃうんだろうね
それがたたって物事を複雑にする
- 62 ：
- 脳が単純だとprivateメソッドのテストコードの話をしていたのに
privateメソッドを作っていいかどうかの話に
単純化（笑）されるんだろうね。
- 63 ：
- クラス自体がウンコ
最近そう思うようになった
- 64 ：
- xUnitが定番になる以前はビルトインテストも珍しくなかったわな。
つか、他人の作ったテストフレームワークを使うのが当たり前になる前はビルトインテストの方が多かったくらい。
ID:sMDuy5hJ は「製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
- 65 ：
- >>64
なんか罠張ってますぜって臭いがプンプンするなｗ
俺からなんて言葉を引き出したいのさ？
> 「製品コードにテストコードが
まず前提として「製品コード」という物の話をしてからだよな。
世の中にはソフトウェアに限らず、不具合がたくさんある不良製品もたくさんある。
テストコードが混在するか否かに関係なく
「（不良）製品コードは良くない設計だ」と言うよ。当然だろう？
それから昔のハードディスクはよく壊れたものだが、今壊れにくくなってるのは
製品を改良したからだ。より良い設計に変えた、逆に言えば昔のやり方は設計が今より悪かった。
これも言うまでもない話だよな。
それとテストコードとはなんぞやの話もしないといけない。
今話しをしてるテストコードとうのは製品で必要ないものであって
故障の場合に障害を調べる調査用端子や自己チェック機能はテストコードではない。
そういう機能をもたせるという仕様があって、その仕様を満たすためにテストコードが存在するだろう。
で、ここまでがお前の罠に引っかからないようにするための話な。
> 「（優れた）製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
あぁ、そのとおりだ。何か言いたいことがあるならどうぞ
- 66 ：
- sqliteみたいな例外はあるけど一般的にはそこまで書かない、全てのコードに対してsqlite並みにテストコード書いてたらプロジェクト終わらんよな
- 67 ：
- >> 「（優れた）製品コードにテストコードが混在するのは良くない設計だ」とでも言うだろうか。
>あぁ、そのとおりだ。何か言いたいことがあるならどうぞ
俺は、テストコードが混在するかどうかが設計の良し悪しに関係するとは思わんが、
問題はこんな単純なことですら「良い設計」の定義が一致しないということ。
そのへん曖昧なまま「privateメソッドをテストしようとするのは設計が悪い」と主張しても、
証明になってないという突っ込みする奴はいるかもしれないが、それ以上反論は
しようがないわな。
- 68 ：
- >>66
> sqliteみたいな例外はあるけど一般的にはそこまで書かない、全てのコードに対してsqlite並みにテストコード書いてたらプロジェクト終わらんよな
だから十分にテストされているライブラリやフレームワークを使い。
なるべくコードを書かないようにするのが良いぞ
自分のプロジェクト専用の処理は、自分でテストするしか無い。
しかし、その中で汎用の処理を見つけ出して、そこを外出することで
自分がテストする量を減らすことができる。
そうやってきたら、俺はpublic関数で10行前後、
private関数なんか更に短くなってしまって。
だから言うんだprivate関数をテストしたいと思ったら
設計が悪いだけだってこと。
- 69 ：
- >>68
それは汎用ライブラリーを作らない人の立場での話だな。
- 70 ：
- >>67
> 問題はこんな単純なことですら「良い設計」の定義が一致しないということ。
俺は良い設計の定義の話なんかしてないんだが？
お前が思い込んでるんじゃないか。
「世の中に出ている製品」＝「良い設計」だと
お前はそう言いたいんだろう？
俺が言ったのは「製品コードだからって良い設計ということにはならない」と
言うこととと「悪い設計」の話だけなんだがちゃんと理解できてないのか？
そういやprivate関数をテストしたくなったらそれは「悪い設計」とも言ったな。
- 71 ：
- >>69
> それは汎用ライブラリーを作らない人の立場での話だな。
汎用ライブラリを作る人の立場の君に聞きたい。
世の中でよく使われている汎用ライブラリで
sqlite並みにテストコードを書いてないライブラリはどれだ？
- 72 ：
- >>71
一杯あるとおもうけど、それを聞いてどうすんだ？
- 73 ：
- >>72
どうするんだと言われてもね。
よくテストされてる汎用ライブラリを使いましょうという
当たり前のことしか言わないよ。
- 74 ：
- えっ、話を逸らしただけ？
- 75 ：
- >>74
話をそらしたのはお前じゃね？
俺は>>68でちゃんと会話をしている。
それに対するお前のレスは中身が何もない。
中身が何もないお前にこれ以上何をいえと？
俺は話を>>68に戻しただけ。
わからないならここに>>68の内容を
コピペしてやっても良いんだぜ？
- 76 ：
- >>75
ああ、そういうことか、sqliteがどんなテストコード書いてるか見たらprivateをpublicにするとか言えないと思うんだけど、すまんねその前提で言ってたわ
- 77 ：
- みんなsqliteのテストコード見なくていいぞｗ
どうせこいつが言ってるだけのことだから。
- 78 ：
- まあ見なくて良いよ。普通のプロジェクトにとっては間違いなく過剰だから。
本体のソースコードの行数が122.9Kのところテストのコードとスクリプト含めて91596.1Kらしいから。
ちなみに内部でassertも大量に書いてる。
- 79 ：
- それが今までの話、
privateメソッドをテストしたくなったら
設計が悪いって話と何の関係があるのかな？
- 80 ：
- >>70
だから、定義してないから真偽定まらんと言ってるのだが。
>>59の主張を要約するとこうだな。
1. privateメソッドをテストしようと思ったら設計が良くない
2. テストできるようにするには2種類の方法がある
a. 設計を見直してpublicにする
b. 設計を見直さずにpublicにする
3. bではなくaにすべき
1.や3.に反論しようと思ったら設計が良い／まずいの定義に踏み込まざるを得ない。
- 81 ：
- 他人に使われるものを作ってるんだったら必要ないものまでpublicにする(外部に公開する)のは良くないよ。
なのでaもbもどっちもダメ
- 82 ：
- >>81
他人ってどういう意味？
その文脈で何故他人が出てくるの？
もしかしてpublicメソッドの話をしているのに、
一般用語のパブリック（大衆の、公共の、公衆の）と間違えちゃった？
だとしたら恥ずかしいね。
- 83 ：
- >>82
何故他人が出てきたらいけないの？
あなたは自分しか使わないものしか作らないの？
- 84 ：
- >>83
もしかして図星だった？
質問にちゃんと答えようね
もしかしてpublicメソッドの話をしているのに、
人間に対して使う用語ののパブリック（大衆の、公共の、公衆の）と間違えちゃった？
- 85 ：
- >>80
publicにしなくてもテストできるやろ
- 86 ：
- >>84
いや、間違えてないけど？
- 87 ：
- 逆に聞きたいんだが、使う人を考えてクラス設計するのがそんなに不自然か？
意味不明な解釈してると決め付けるぐらいに
- 88 ：
- じゃあ自分しか使わないものは
全部privateにするわけね。
自分っていうのは人間の話ね。
- 89 ：
- >>88
自分しかつかわないなら好きにすればいいんじゃない？それこそ全部publicでも誰も文句言わない
- 90 ：
- 自分しか使わないからprivateって、なんてクソな設計なんだろうw
- 91 ：
- むかしオブジェクト指向システムの設計ってスレで
将棋の例を出して暴れてたやつにそっくりだなｗ
- 92 ：
- むしろ自分しか使わないならpublicでええやん
- 93 ：
- 設計的な公開/非公開はpublic/privateで分ける
人に対しての公開/非公開はスコープで分ける
- 94 ：
- >>93
それって逆でもいいんじゃね？
- 95 ：
- 開発者が俺とお前の2人ならそれでも良いかもな
- 96 ：
- >>4
どれ、宿題を出しといてやるよ
動物が「バカ」だったときには「4」を返す
という仕様を実装漏れしていました。
なぜ漏れていることに気づけなかったんでしょうか？
あなたの実装漏れを知った顧客は、あなたの報告するカバレッジが100％であることに何の意味もないことを知り、あなたの報告に疑いを持つようになりました（ちゃんちゃん）
- 97 ：
- >>4じゃないけどさ
カバレッジ100%にしても実装漏れは検出できないって当たり前でしょ…
- 98 ：
- >>96
じゃあお前への宿題な
他の自動車に後ろから追突されたときはエアバッグは意味が無いことを知りました。
エアバッグによる安全性に意味が無いことを知り、あなたは安全装置をすべて外しました
そしてあなたはエアバッグで助かる事故で死にました（ちゃんちゃん）
- 99 ：
- 馬鹿・・・カバレッジが100%ということはバグがないということだ
普通・・・カバレッジが100%ということはすべての行を実行する程度のテストはしているということだ。
馬鹿は銀の弾丸があると思っている。
馬鹿はカバレッジを完璧じゃないと言おうとしているつもりが
実は馬鹿のほうこそが過大評価している。
自分の間違った考え（カバレッジ100%は完璧）を自分でそれは間違いだって
ツッコミを入れているだけである。マッチポンプ
- 100 ：
- 出題しろよ
- 101 ：
- たかがC0のカバレッジ100%を特別なことだと思ってるバカって、>>4のことだよな？
- 102 ：
- >>98
>>99
なんだ。答えられないのか。おまえクビなw
- 103 ：
- >>4の話でLookupTableクラスを分離するというのが「良い設計変更」だとして、じゃあそれを
使用するクラスの内部クラスにしたらその設計は良いままなのか、あるいは悪くなった
ことになるのか、って疑問はあるな。
- 104 ：
- >>97
動物が増えてもテスト不要と言っちゃってる >>4 に言えよ
- 105 ：
- >>4
> 動物が増えたら？などということを考える必要はない。
はたして、そうだろうか
> data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
"馬: 3"の追加が必要なのに、それを忘れていた場合にどうするんでしょうね
> テストはどうする？ ・・・答えは "不要" だ。
残念、追加し忘れを見逃しましたね
> 元の設計のテストというのはデータが増えれば対応するテストを
> 増やすだけという単純作業
をやってれば、バグを検出できたのに
> なぜならばLookupTableのテストはすでに書いているからだ。
LootupTableのテストは書いていても、data定義（初期化）行はテストできてないね
- 106 ：
- >>105
> をやってれば、バグを検出できたのに
残念。それを忘れたらバグは検出できませんね
- 107 ：
- くだらないこと言ってないでコード書けってよく言われてるんだろうな。
- 108 ：
- >>106
この場合は忘れてもカバレッジが教えてくれるだけマシだったんじゃない？コードの見やすさは知らんけど
- 109 ：
- >>106
テスト設計しないんですか？
- 110 ：
- >>106
テストが不要だということの反論に対して、テストを忘れたらバグを検出できないとか言われても困惑するのみ
- 111 ：
- > data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
こんな増えてくと予想できるリストなんかは外部ファイルにしとけよ
後は必要なら勝手にファイルに追加してねって責任を誰かに丸投げできれば重畳
テストもそいつに丸投げできる
- 112 ：
- テストしにくいコードを書くのがおかしい。
- 113 ：
- 残念ながら世間ではおかしいことがまかり通っててそれを修正する必要がある。
- 114 ：
- テストし易い部分のコードなんて誰でも書ける
- 115 ：
- >>114
矛盾
- 116 ：
- コードを選ぶようなテストフレームワークが悪い
- 117 ：
- じゃあ作ろっか
- 118 ：
- >>115
矛盾というかジレンマですな。
- 119 ：
- 要件や設計に書いてあることをただ満たせばいいのに、
何だテストしにくいコードって。
- 120 ：
- >>119
自動テストができないコード
自動テストをやろうとしたら組合せ爆発を起こして
時間がかかりすぎるコードだよ
- 121 ：
- >>119
ばーか
- 122 ：
- >>119みたいなマがいるから困る
後々の工程や運用段階でバグが見つかっても
困るのはオレじゃないから、とか考えてるんだろうな
- 123 ：
- >>119 はいきなりシステムテストレベルを行う人間なんだろうね。
それだと小さいバグ、作り上の問題に気づかない。
- 124 ：
- >>120
組み合わせ爆発は、自動テストが原因じゃないよね。
逆に組み合わせ多数でマニュアルだと時間がかかりすぎて繰り返し実行できないなら、
自動テスト化を考えたほうが良い。
- 125 ：
- 自動テスト使って開発したこと無いだろお前
組み合わせが多過ぎるなら組み合わせが減るようにバラすのが先だわ
- 126 ：
- >>125
全組み合わせだと1億通りなのを、オールペア法や直交表で100通りくらいまでに減らすのは基本
さらにその100通りをマニュアルで実行すると時間がかかるのなら、自動化すべき
ということだよ
組み合わせ爆発は、自動テストが原因じゃない
とか、こんな説明書くの疲れるわー
- 127 ：
- やっぱり分かってねえ…
テスト技法の前に設計を何とかしろ
- 128 ：
- >>127
あのねぇ・・・
俺は>>120の内容が間違ってると言いたいのだよ・・・
糞設計が原因のテスト困難性の話なんかしてないわ・・・
- 129 ：
- >>128
ほっとけよ、どうせprivateをpublicにするとか言ってた奴だろ
相手を解ってない事にして見下したいだけのやつだよ
- 130 ：
- 今時、1億通りぐらいで自動化できないとか、どれだけヘッポコなんだろw
- 131 ：
- ぼこぼこにされた>>119が噛み付いて回るスレをお楽しみください
- 132 ：
- どうした？力技でテストすればいいんじゃないのか？ｗ
- 133 ：
- お前らGUIは自動テストしてんの？
- 134 ：
- >>133
最低限
- 135 ：
- >>133
現状人の見た目でしか判断できないのは仕方ないとして、(表示されている写真の人物が最盛期の西条秀樹に間違いないとか)
GUI の状態取得関数やプロパティなんかで得られる情報ならその情報を確認できたらそれが表示できているとしてテストを組んでる。
例えばあるテキストボックスの文字色が赤というテストなら文字色プロパティが赤になっているのを確認するとか。
GUI ライブラリ自体はテストされているという前提なのでそのバグに遭遇しない限りは問題ないはず。
(稀によく遭遇するけどテスト過程で原因は判りやすいから GUI ライブラリ側に報告もできるしこちらも回避はできる)
GUI の表示ライブラリそのものを作ってるとしたらまた話は別だけど。頑張って死んでくれ。
ところで、テストコードを自動で書いてくれる便利ツール、おまえらなら何か知ってるんだろ? 教えてくれ。言語や手段は問わない。ヒントになればいい。
- 136 ：
- >>108
テスト不要だ(ｷﾘｯ 君はこれに答えろよカス
- 137 ：
- 実装コードの複雑度の客観的判定のお供に
SonarQube
設計のおすすめ書
組み込みソフトウェア開発のためのオブジェクト志向モデリング
あなたの書いたメソッドはテスト以前に単一機能の原則にマッチしていますか？テストが困難という事は設計が(ry
- 138 ：
- >>136
なんか人違いしてる気がするがテスト不要といってる奴と別人だよ。
>data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
とする設計より一つずつifで書いた方がテスト忘れてもカバレッジが教えてくれるから(コードの見やすさは別として)マシだったんじゃない？って意味だよ
- 139 ：
- 自分の管理下にない外部サービスへのログインなどの処理を行うライブラリのテストを行いたいんだけれども, ログインパスワードとかの情報ってどうやって被テスト対象に渡すべき？
- 140 ：
- age忘れ
- 141 ：
- >>138
どちらもカバレッジで教えてくれる。
1つのコード、1つのテストで、カバレッジを100%にするのも
同じ処理を複雑に書いて
100のコード、100のテストでカバレッジを100%にするのも
カバレッジ自体は同じだ。何も違いはない。
ただ、後者は面倒ってだけ。
書くものが増えれば増えるほど、ミスも増えるし
読むものも増える
- 142 ：
- >>139
外部サービスがログイン機能を正しく実装しているかっていうのは
外部サービスがテストをするべき所で、あんたがテストするところじゃない。
あんたがテストするならば、その外部サービスに対して
想定通りのパラメータを正しく送ったかどうかをテストする。
この時、実際には外部サービスは使わない。外部サービスのふりした
何か（モック）を代わりに使う。
- 143 ：
- >>142
やっぱりモックか・・・・・・
ありがとう
- 144 ：
- >>141
だから
>data = {人: 2, 犬: 4, 猿: 4, キジ: 2, 猫: 4}
という設計だと猪:4というのを追加したあとテスト忘れてもカバレッジ変わらないでしょ
ifだったらカバレッジ下がる。それだけの話だよ。
- 145 ：
- >>144
なんでカバレッジが変わる必要があるのかわからんのだが？
あんたは猪4が追加されたらカバレッジが減ってほしいと思ってるわけだよね？
それは追加した猪4に対するテストコードを書くべきだって考えてるからだよね？
では、このコードの時、追加した猪4に対するテストはどうなるわけさ？
それ以外のテストはすでに書いてあるという前提なので、
追加した猪4だけのテストはどうなるのかを答えて。
そのあとそのテストをやる意味はどれくらいあるかって話をするからさ
テストを書く時間（将来的にはメンテする時間）にだってコストは掛かるんだぜ？
- 146 ：
- >>141
そもそも、一つのテストでカバレッジ100%になったとしても、入力による結果が100種類あるなら100個テスト書かなければテストの意味がないというのは理解してる？
- 147 ：
- >>146
例えば、atoiの場合、結果は32bitCPUの場合で
4294967296種類（半分だっけ？）あるけど、
その場合のテストの数は？
- 148 ：
- >>147
そういう場合俺なら仕様を読んで、正数、負数、返す値の最小値、最大値付近とオーバーした場合、数字以外を含む、空文字、空白を付けた場合などのパターンを書くね。
心配ならintの最小値から最大値までを変換後、文字列に逆変換して文字列に戻したものが一致するかどうかのテストも書くかもね
- 149 ：
- >>147
横からだけど、atoi の場合は基本はそうだよ
でもそんなのやりきれないから境界値とか工夫するのが普通。
猪の件はどういう主張なの？
assert( numberOfFeet(人) == 2 )
assert( numberOfFeet(猿) == 4 )
assert( numberOfFeet(猫) == 4 )
assert( numberOfFeet(猪) == 4 )
みたいに増やす以外に良い方法があるってこと？
- 150 ：
- >>149
やりきれないとやりきれるの境目はどこ？
100個？ 1000個？ 1万個？
やれるなら、やれるところまでやるべきだって話なんだよね？
俺はテストする価値が無いなら、テストしない。
テストを減らすために、猪を増やした所で
テストする価値がないコードになるようにする
- 151 ：
- カバレッジ100%を目的にテスト書くんじゃなくて仕様を満たしているかを確認するためにテスト書くんだよ。
そんな考えだからintの数値の範囲のみテストするような発想になるんだ。
- 152 ：
- >>149
> みたいに増やす以外に良い方法があるってこと？
ある。ずっと上の方に書いたはずだがね
- 153 ：
- >>151
そんな当たり前のことを言われても・・・
仕様を満たしているかを確認する時の
テストの数を減らせるように
コードを工夫するって話をしてるのに
一歩前にもどるなよｗ
- 154 ：
- >>153
猪渡したら4を返すという仕様が追加されてもテスト不要って言ってるんじゃ無かったの
- 155 ：
- >>153
横からだけどそれはおかしいなぁ
テストって設計書から作成するもんでその数がコードの書き方で増減するのは基本的にはおかしい
- 156 ：
- >>154
境界値はテストするが、その間は
テストする価値がないからテストを書かないんだろ？
猪渡したら4を返すという仕様であっても、
工夫（仕様や処理を互換性がある別の形に変更）することで
テストを書く価値がないコード（猪を追加する前のテストコードだけで十分）に
することができる。
境界値のような特異なデータである猪を
境界値の間のような無害なデータにすることで
テストする価値がなくなり、テストが不要になる。
- 157 ：
- >>155
全然おかしくない。
設計書にコードに記述されていることに全てが書かれていれば
その理屈は正しいかもしれないが、実際には設計書には
コードに書かれていることの一部分しか書かれていないから。
つまり設計書に書かれていない部分に対するテストの数は増減する
- 158 ：
- >>156
仕様は猪を渡したら4を返す筈が実装を間違えて1と返ってくるバグ仕込んだ場合テストコードの追加無しに検出出来るの？
- 159 ：
- >>158
できる。
あとはテストする価値があるかどうかって話になって
俺はテストする価値が無いと思うだろうからテストは書かない。
あんたは境界値の間の値のような、
17を入れたら289が返ってくるはずが実装を間違えて
300と返ってくるバグを仕込んだ場合のテストコードを書くといいさ。
- 160 ：
- >>159
じゃあどうやるんだよってのが皆の疑問だと思うんだが。
猪が境界値の間の値という主張もどうかと思うが、
場合によっては間のテストも書くと >>148 に書いたよ
- 161 ：
- 例えば仕様が動物の名前を与えたら足の数を返す
という曖昧なものであれば猪のテストは追加しないかもしれない。
しかし実際にそんな仕様のコードを書くのは不可能なので、仕様が粗雑ならテストコードも粗雑になるのは必然
仕様がとある動物データ内で定義されている足の数が返る
というのであればその動物データを読み込んでデータと関数の返す値が一致するかをテストするだろう。
同様に仕様に猪を与えたら4を返すとあればそういうテストを書くのが当たり前
- 162 ：
- >>155
テストの目的によってちげーよばか
- 163 ：
- >>161
> 同様に仕様に猪を与えたら4を返すとあればそういうテストを書くのが当たり前
お前の提唱するシステム開発では、
仕様書を作る人は、全ての動物の足の数を仕様書として書く間抜けで
その仕様書に則って開発する人は、何の疑いもなく書かれている通りにテストを書くのだろう？
素人が仕様書を書いて、考える頭がないやつが開発する。
コストがかかるのはそのためだ。
境界値の間のテストを書きたいなら書けばいいさ？
var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}
assert(data["猪"] == 4) というテストに価値があると思うならな
- 164 ：
- 訂正ｗ
var data = {"人": 2, "猿":4, "猫": 4, "猪": 4}
- 165 ：
- >>163
全ての動物の足の数が必要とは誰も言ってないんだけど？
- 166 ：
- さすがにこの粒度でテストするのは意味ないだろｗ
二重メンテになるだけだわｗ
- 167 ：
- 君たち何のためにテストしてるの？何を保証したいの？
- 168 ：
- >>167
要求仕様書だよね
- 169 ：
- >>168
君は覚えたての言葉を垂れ流すのをやめなさい
- 170 ：
- {"人": 2} これを、{"入": 2} 書いてもエラーにならないから、確かめる必要がある。
特にハイフンなどは、何種類もあるから危険。
全角空白・半角空白も
テストせずに、こういうので、ずっと出来ないって言ってる、香具師が多い
- 171 ：
- カバレッジ100%にする事しか頭にない実装してからテストコード書くようなやつなんだろうね。
- 172 ：
- >>167
自分が決めたもしくは他人に決められた仕様を満たしている事の確認のためにテストを書いてる。
けっして全てのコードパスを通すためではないよ。
ID:fNu+0xzW がテストでどんなバリデーション書くのか興味あるね。
- 173 ：
- >>166
そう思う人は産業用ロボットなど高信頼性が求められるソフトウェア開発には参加しないでくださいね。
そういう手抜きで人が死ぬから。
- 174 ：
- >>166
そういうことだよねｗ
こういうコードがあって
var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}
テストで
var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
assertDeep(data, expected)
こういうテストを書くことに、どれだけの意味があるかって話だよ
今までそういう話じゃなかったって？
そうだね。今まではnumberOfFeetの話だった。
しかし、numberOfFeetの部分は他のdataですでにテスト済みとする。
そうすれば残り部分は、dataだけになる。だからdataが変わったのであれば
そのdataの変化分だけをテストすれば良い。それがこのテスト
>>172
> 自分が決めたもしくは他人に決められた仕様を満たしている事の確認のためにテストを書いてる。
他人もしくは自分が、境界値以外のどうでもいい値の仕様を書いたとしたらその値をテストすんの？
「（全ての）数値が二乗される関数であることと」と書いてあったら、
すべての数値をテストすんの？
- 175 ：
- >>174
コード上の境界値だけテストすれば十分だと思ってるの？
こわいなあ
- 176 ：
- どれだけテストすれば良いかは決まっているものでも、個人の感覚によるものでもありません
ターゲットとするソフトの目的や性質を踏まえて設計するものです
これをテスト仕様設計と言います
- 177 ：
- でもやっぱり仕様書で猪4が追加されてる以上テストはやりたいね
- 178 ：
- >>177
> こういうコードがあって
> var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}
>
> テストで
> var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
> assertDeep(data, expected)
> こういうテストを書くことに、どれだけの意味があるかって話だよ
- 179 ：
- テストするならせめてもう一つ外側とかかな。
例えば履物が合計何個必要かとかを計算する関数のテストとかね。
get_sum_feet( animal_list )
のテストとか。
- 180 ：
- >>176
> これをテスト仕様設計と言います
そのテスト仕様設計書に、
「（全ての）数値が二乗される関数であることと」と書いてあったり、
いかにも境界値でも、その前後でも、なんでもない普通の値が書いてあったら
どうするの？って話。
書いた本人は実装がわからない（この時点では実装が存在しない）から、
それが重要な値だって思ってテスト仕様書に書いたかもしれないが、
実装によっては重要でも何でもない値にできるかもしれないだろう？
実装を考えずに無駄のないテスト仕様書を書くのは不可能なんだよ。
- 181 ：
- 単体はともかく結合あたりじゃ
仕様書を満たすテストが主でしょ?
- 182 ：
- >>179
なかなか興味深い例をだすねｗ
では
numberOfFeet(animal)
get_sum_feet( animal_list )
の2つがあって，numberOfFeetのテストが猪の対応も含めてちゃんと書かれているとする。
この時、get_sum_feetのanimal_listに猪が含まれている場合のテストは必要ですか？不要ですか？
ただし実装の内容は決めません。
（俺がこの例で本当に言いたいことは、これは実装を決めなければ
テストが必要かどうかがわからない例であるという事ねｗ）
- 183 ：
- >>182
だから単体はともかく結合じゃいるよ
- 184 ：
- >>181
つまり仕様書から作るテストは正しく動くためのテストではなく、
単に仕様書から思いついたテスト（足りない物はあるし、意味のないものもある）
って話だよね？
では残りのテストはどこで作成するのか？
そして意味のないテストを、これからもやり続けたいのか？
という話が残る。
- 185 ：
- >>183
それでは、単体で行えるテストを
結合でもやる理由は何？
- 186 ：
- なるほど、そもそもテストの目的が違うわけだ。
品質を上げたいというよりかは
SIer から文句を言われないためのテストが必要だと。
それなら言われた通りに頭使わずに、
くだらないコードでもなんでもテストするのが正しいと思うよ。
- 187 ：
- >>180
せめてブラックボックステストとホワイトボックステストぐらい理解してから出直してきな
- 188 ：
- >>185
結合はお客さんが出してきた仕様書通りに動いてますよっていう保証だから
（会社によってはシステムテストだったり粒度は異なるが）
猪4って仕様があったならそれがPGにとってくだらんテストであるかどうかなんて関係ない
- 189 ：
- >>187
ブラックボックステストはコストがかかる割に
正確なテストが出来ないという話でOK？
- 190 ：
- ここまでのまとめ
numberOfFeet(animal)
get_sum_feet( animal_list )
は仕様書で決めることで、仕様書も、テスト仕様書もお客さんが決めることである。
当然ながらテスト仕様書の量に応じてお客さんがテスト作業費を支払う義務がある。
ということらしい
- 191 ：
- ちょっと訂正
は仕様書で決めることで、仕様書も、テスト仕様書もお客さんが作成するものである。
- 192 ：
- >>174
全ての数値が二乗される関数であること の意味が解らんが
リストで渡した数値全てが2乗されて返る関数ってことかな？
テストしない理由がないな
- 193 ：
- うむ、なるほど理解した。
1. 仕様書を満たすテストコード
2. テスト仕様書を満たすテストコード
この2つは別のものなのだ
例えば、仕様書には「すべての数値を二乗する処理」と書くだろう。
2を4に、3を9に、4を16に、・・・・にする処理。と全ての値を書くバカはいない。
そしてテスト仕様書には「2を4にする」などと特定の値のテストを書くだろう
2を4に、3を9に、4を16に、・・・・になることを確認する。と全ての値を書くバカはいないし
すべての値のテストを行うことと書くバカもいない（テストの量に応じてコストが大きく変わるため）
つまり、仕様書の内容とテスト仕様書の内容は一致しないということだ。
仕様を決めたからと言って、それがそのままテスト仕様書に書く内容になるわけではないのだ。
そこが勘違いしている点の一つだな。
テスト仕様書は別途書き起こさないといけない。そのテスト仕様書を書くのは客の仕事だ。
そしてテスト仕様書を満たすテストを行う（テストコードを書く場合もある）のは開発会社だが、
その費用はテスト仕様書の量に応じて客に請求するものとなる。
（俺の会社ではテスト仕様書の量が膨大でも固定の金額でテストするというのならどうぞ勝手にしてくれｗ）
テスト仕様書に書かれているテストは作業量をもらっている以上やるべきことだが、
テスト仕様書に書いてあるテストをパスしていたとしても、
仕様書の内容を満たしていなければ客は怒るだろう。それが仕様なのだから。
問題はここだな。テスト仕様書を満たすテストコードではなく仕様書を満たすテストコード。
仕様書には書かれているが、テスト仕様書には書かれていない値 に対するテストだ。
テスト仕様書には書かれていないのだから、その部分の仕様を満たすためのテストはどう書いてもよかろう？
話を戻すとこの仕様書のみに書かれている内容に対するテストの量は実装によって変わってくるという話だったわけだ。
- 194 ：
- >>192
「引数で渡した数値が二乗されて帰ってくる関数」って意味だよ。
あとは>>193で書いたとおり。
仕様書の内容が、そのままテスト仕様書になるわけではない。
- 195 ：
- >>174
あと、せっかく他人が >>149 で
assert( numberOfFeet(人) == 2 )
assert( numberOfFeet(猿) == 4 )
assert( numberOfFeet(猫) == 4 )
assert( numberOfFeet(猪) == 4 )
とnumberOfFeetの実装方法に依らないテストコードを書いてくれてるのに、
なぜ馬鹿みたいなテストコードを自分で書いて自分で批判してんの？
- 196 ：
- 補足
「引数で渡した数値が二乗されて帰ってくる関数」って意味だよ。
だから、テストするしないは別として引数として取りうる数値の数（32bitで2^32乗個）
だけテストケースは存在しうる。
その全てをテストしないでしょ？
だから仕様書に書かれた内容が、テスト仕様書の内容になるわけじゃない。
どっかの誰かは仕様書に猪が追加されたら、
テスト仕様書にも追加すべきだって言っているようだがね。
- 197 ：
- >>195
それは実装方法には依らないが
テストする価値が殆ど無いコストがかかるだけの
テストコードだって話をしてる
- 198 ：
- >>196
つまりお前は仕様として明示的に追加された”猪”が数値に置き換えると明示的に指定もされていない一つの数と重要度は同等であるという主張なわけな。
まぁ、それはそれでめんどくさいので置いておくとして、
numberOfFeet(猪)
が仕様からはずれた4を返す以外の結果が発生する場合に正しくテストがエラーとなるテストコードはどう書くんだい？仕様が追加されたときにテスト追加しなくても検出出来るって言ったよね？
- 199 ：
- >>198
人の話をちゃんと聞け
まずテストする価値が殆どないコストがかかるだけのテストコードを
書く意味があるのか？って話をしている。
> numberOfFeet(猪)が仕様からはずれた4を返す以外の結果が発生する場合に
> 正しくテストがエラーとなるテストコードはどう書くんだい？
こう書けばいい
実装コード（の一部）
var data = {"人": 2, "猿":2, "猫": 4, "猪": 6}
テストコード
var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
assertDeep(data, expected)
実装コードが間違ってる場合に正しくエラーになるぞ。
これはdataの内容だけしかテストしてないと言いたくなるかもしれないが、
それ以外の部分はダミーのdataを使って正しくテストしている（という前提）
変わるのはdataの内容だけなのだから、テストコードを書くとしたらdataの内容のみのテストだけでいい。
そして、こんなテストコードを書くのにどれだけの価値があるのか？って話
だってdataのデータを修正して、テストコードのexpectedにそれをコピペするだけだろ？
追加するたびに、二箇所にある同じデータを同じようにメンテするだけの作業
俺はそんなのをやる意味がないと思っているから、dataの内容以外のテストだけで十分
だからdataの内容が変わるだけならば、新たにテストを追加する必要はないと言っている。
- 200 ：
- >>199
え？テスト追加してるじゃん？追加なしに検出出来るんじゃなかったの？
仕様から導き出される実装がとても簡単だったから仕様を満たしているか確認するテストは面倒なので勝手に省きます！ って事か。
お前は何の為にテスト書いてんの？
- 201 ：
- >>199
> テストコード
> var expected = {"人": 2, "猿":2, "猫": 4, "猪": 4}
> assertDeep(data, expected)
テストコード書く能力ひくすぎだろこれ
- 202 ：
- >>201
しかもそれ、numberOfFeetが仕様を満たしているかかくに
- 203 ：
- ミスで途中送信
numberOfFeetが仕様通りか確認するテストでは無いんだよなぁ。自分で無意味なテストを書いて無意味だからやらない！とか何のギャグなんだかね。
- 204 ：
- >> var data = {"人": 2, "猿":2, "猫": 4, "猪": 4}
みたいなハードコーディングするということは、要求される場合の数が非常に限定されている場合で、
その場合は全てテストする必要がある。
要求される場合の数が多い場合は、ハードコーディングなんかはしないわけで、上の議論は不毛な議論と言える。
- 205 ：
- >>189
ちがうわ、ばーか
おまえテスト語る資格ねえよ
- 206 ：
- ID:T4INally のバカっぷりに笑った
- 207 ：
- よく2行のテストコードでこれだけ話を続けられるもんだ
- 208 ：
- 基本的に俺らの仕事が要件定義から始まってるってことを忘れたような議論をするやつがいるな
- 209 ：
- では要件定義と絡んだテストコードの話でもしたらどう？
- 210 ：
- >>209
業務系のは要件と、要件を満たすための仕様がふらつくんで厳しいかもしんね
できんこたないけどUI層からのぶっ叩き(Selenium/Capybara/UI Automationなど）のほうが楽だと思う
UIの変更がなければ動く（はずだ）し、動かないならバグでそ
- 211 ：
- DHH vs ケント・ベックの対談を見て以降
ユニットテスト =
UI層を迂回して最上位のクラスのメソッドを蹴れるようにしておき
必要な時に簡単な引数を突っ込んでメソッドを流し動作確認を取ること
というやりかたしかしなくなった（境界値とか直行表とかマトリクスとかはやらなくなった）
- 212 ：
- ユニットテストで自動化して工数削減できるぜってインタフェースのブラックボックステストしかしなくなったんだが、そりゃホワイトボックステスト省いてるんだから工数減るわ
- 213 ：
- >>212
お前のユニットテストはホワイトボックステストじゃないのかｗｗｗ
- 214 ：
- >>213←こういう馬鹿が本当に多い
実にお前ららしいけど
- 215 ：
- >>214
どうも日本語に問題があるようだね
- 216 ：
- >>215
ブラックボックステスト/ホワイトボックステストを勘違いしてる人は多い
- 217 ：
- >>216
恥ずかしいよね
- 218 ：
- >>213
「お前のユニットテストはホワイトボックステストじゃないのかｗｗｗ」
この文は受け手によって以下のどちらにも解釈できるんだよな
1. それはユニットテストといいつつ実質ホワイトボックステストだろ（ユニットテストをホワイトボックスの代わりにするな）
2. （俺はユニットテストをホワイトボックスの代わりに用いるんだが）お前のそれはホワイトボックスではないのか？
ID:gC8biGup が平均的な主張をしていると信じるなら 1. だが、
お前が平均的な主張をしているというソースはないし、受け手でどうとでも解釈できる
人の日本語の問題を指摘する前に、どちらとも受け取れるような日本語使うなよ
- 219 ：
- >>218
ブラックボックステストとホワイトボックステストという区別はテスト入力値の抽出の観点であって、試験対象の粒度の観点であるユニットテストとは独立した観点。
だから、ユニットテストの代わりにホワイトボックステストをするというのは用語として意味が通らない。
で、普通はユニットテストはソースコードを見れる状態でやるから、大抵はホワイトボックステストをやってる。
むしろユニットテストでブラックボックステストをする方が手間がかかる。
- 220 ：
- >>219
メソッド単位で仕様がカッチリ決まっているほど細かな仕様や設計ならブラックボックスなユニットテストもありえるけど、まあ巷で普通にやられているのはホワイトボックスなユニットテストだわな。
- 221 ：
- ユニットテストならカバレージぐらいはとるしブラックボックステストなんてありえんやろ
- 222 ：
- >>218
1はあり得ないだろ
- 223 ：
- >>219
独立した概念だからこそ、 1. も 2. もどちらにもとれるだろ
あと、ホワイトボックステストは入力値の抽出の観点だけではないだろ
ホワイトボックステストというと
デバッガで値を設定し、プログラムを追いつつ確認するようなのも含まれる場合もあるから、
単純にホワイトボックステストをすると言われたら、ユニットテストだけでは足りないという認識
ユニットテストが通常はホワイトボックスとして行われていることは同意
- 224 ：
- >>223
>ホワイトボックステストというと
>デバッガで値を設定し、プログラムを追いつつ確認するようなのも含まれる場合もあるから、
それがよくある誤解なんだよ。
ホワイトボックスかブラックボックスは入力値の極限値や境界値、組み合わせの特性を決めるのに、箱の中を見るのか見ないのかということを指してる。
デバッガで値を変更するのは、ウォークスルーレビューの一種で、本来机上でやるのを計算機のサポートを得ながらやるという意味であり、狭義のテストではない。
広義のテストではレビューも含まれるから絶対間違ってるってわけではないけどね。
- 225 ：
- よくある誤解というのは、
ブラックボックステスト=外から見た振る舞いを確認する
ホワイトボックステスト=内部の動きを確認する
というやつね。
これは全くの間違いで、テストは入力を与えて出力を見るものだから、どちらであっても外から見た振る舞いを確認するのが正解。
その時に、どんなテストをやれば効率的に十分な振る舞いを確認出来るのか、という観点で入力値を選ぶ方法として、ブラックボックスとホワイトボックスがある。
入力値自体の特性に着目するのか、入力値の扱い方に着目するのかって違いだね。
カバレッジは更に別の概念で、そうやって作ったテストが実際にどれぐらい振る舞いを網羅したのかという指標。
だから、ブラックボックステストであってもカバレッジは測れるし測るべき。
- 226 ：
- ふむ、非常に一貫しているな
参考にした文献があるなら教えてほしい
もし独自のものだったら、
「テストは入力を与えて出力を見るものだから、どちらであっても外から見た振る舞いを確認するのが正解。」
これは話が飛びすぎ、または正解の定義が抜けている
再現が難しいテストでソースコードを使って再現させるテストはレビュー扱いか……
テストを入出力で定義したら、ブラック／ホワイトボックステストやレビュー扱いはそうなるよな
だがテストという言葉を独自に定義したのなら、その定義だけを根拠に他人のテストや、
ブラック／ホワイトボックステストの認識を間違いと断じるのはおかしい
少なくとも、テスト以外の扱いになったデバッガによるレビュー作業が正解でないという理由を示すべき
（テストの定義に当てはまらないからという理由なら、お前の中ではなということになっちゃう）
- 227 ：
- JSTQB とか参考にすりゃいいんじゃね？
https://webrage.jp/techblog/three_types_of_test_design_techniques/
あとデバッガ云々はテストのやり方の話だからウォークスルーレビューとか言ってる奴はちょっと頭が固いと思う
- 228 ：
- >>225
ブラックボックステストのカバレッジってなんだか知ってる？
答えを知ってるならそれの測定結果になんら客観性がない事も分かるだろうし
知らないなら口からでまかせに言ってるかとんでもない勘違いのどちらかだし
何れにせよ「ブラックボックステストのカバレッジを測るべき」なんて発言は
著しい知性の欠如によるものだと判断せざるを得ないね
- 229 ：
- >>228
カバレッジって日本語にしたら網羅率なんだから何のテストのってことはないよ。
プロファイラ掛けながら実行すれば行カバレッジだって取れる。
ブラックボックステストのカバレッジってのに違和感があるなら、ブラックボックステストをテストのやり方だと誤解してるよ。
何度も言うように入力値の決め方(テストケースの選び方)なのだから、テスト項目になってしまえば、ホワイトボックスで決めたのかブラックボックスで決めたのかは区別が付かない。
- 230 ：
- >>226
>ふむ、非常に一貫しているな
>参考にした文献があるなら教えてほしい
普通に、古典のマイヤーズの「ソフトウェア・テストの技法」だよ。
>再現が難しいテストでソースコードを使って再現させるテストはレビュー扱いか……
デバッガを使えばテストではなくレビューだと言ってるのではないよ。
よく、ホワイトボックステストだと言われがちの、デバッガでステップを追って動作を確認するテストをレビューの方が近いと言ってる。
単にデバッガを汎用スタブ/ドライバ代わりに使えばテスト環境の一部になるしね。
逆にたとえデバッガを使わなくても、行毎にprint文を埋め込んで、どういう入力でどんな出力がでるのかという観点ではなく、どう言う順番で処理したのかに着目してるとしたら、それもテストではなくレビューだと言うべきだと思うね。
>少なくとも、テスト以外の扱いになったデバッガによるレビュー作業が正解でないという理由を示すべき
それはホワイトボックステストでは無いと言ってるだけだが、レビューと呼ぶべきと言うのは蛇足だったかもね。
- 231 ：
- まあこういう言葉尻とか定義にこだわってるといっこうにテストって作られないよね。
- 232 ：
- ブラックボックステストとかホワイトボックステトとかいう分類はいらん。
コストの観点から分類してくれ。
手動テストと自動テスト
- 233 ：
- >>227
これのリンク先もホワイトボックステストを勘違いしてるように見える。
JSTBQの用語集では、以下で定義されてる。
ホワイトボックステスト設計技法(white-box test design technique): コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
これを、内部構造を検証するテスト、と飛躍してしまってる。これこそ典型的な誤解だ。こうやって誤解がぶんさんしていくんだろうな。
ホワイトボックステストは内部構造の分析に基づいてテストケースを設計するが、検証対象はあくまでも元々のテスト対象であって、テスト対象の内部構造では無い。
テスト対象の内部構造をテストしたい場合は、内部構造のレベルまでおりて、その粒度でまた内部構造の外部仕様(ブラックボックス)と内部構造の内部構造(ホワイトボックス)の分析に基づいてテストケースを設計する。
最終的に一番細かい単位のテストが、いわゆるユニットテストと称される。
- 234 ：
- >>232
ちゃんと分類出来てないと、全然意味合いが違うもののコストを比較することになるよ。
ソフトウェアテストの場合は、手動テストは言うほど手動でなかったり、テストでなかったりするし、自動テストはそれほど自動でなかったりするからなあ。
コストを比較するなら、特定のテストのどの作業をどう自動化？するのかを論じないと。
自動って言葉って一人歩きするよね。
そのうち、「昔の自動車って手動で運転しなきゃならなかったんだって」って言われるようになるんだろうね。
- 235 ：
- > 自動って言葉って一人歩きするよね。
いや？ 全然。まずテストって言うのは
それが自動化されようがされまいがどんなものでも
ソースコードと同じリポジトリで管理されるべきものってのは
コンセンサス得られているかなぁって思う
この第一歩ができてないところが多すぎ
- 236 ：
- >>234
> コストを比較するなら、特定のテストのどの作業をどう自動化？するのかを論じないと。
だからあとからコストを考えるのは辞めてほしい。
特定のテストにかかるコストをどうやって下げるかを論じないと。
- 237 ：
- >>235
えっと、もしかして、全てのテストが「テストコード」の実行によるものだと思ってる？
- 238 ：
- >>236
だから、その「特定のテスト」というものをどう切り出すかがテスト技術なんだって気付け。
- 239 ：
- >>231
仕事の関係でJaSSTとかに何回か行ったことあるけどなんかこういう言葉遊びを延々やってるだけで全然まともなアウトプットがないんだよね
やってる本人達はこうやる「べき」だとかこうやればできる「はず」とかばっかりで、ならお前がやってみろよ！って突っ込みたくなる w
- 240 ：
- >>236
やること決めないでコスト算出したってその算出結果には欠片も意味がないからその算出作業のコスト自体がドブ捨て金になるよ。
自動なら手法確立までのコストが必要だがその後はほぼかからないのに対し、手動なら手法確立のコストは余りいらないが量に比例して作業や管理コストが増える。
そのどちらがいいかはその状況に依る。先行する条件に大きく依存するもので分類したところでそれには意味がない。
そもそも何するか判らない状態でどうやってコスト算出するのかこっちが知りたい。山勘とかはなしで。
だが、ここのスレの議論では得体の知れないコードのテスト方法を研究したいのであってコストの問題なんか知ったこっちゃない。
どういう立場の人か知らないけど、金勘定の話がしたいのならその手のスレに行った方がいい。プログラムロジックやその検証とは全く関係ない。
- 241 ：
- JaSSTはむしろテストの実践をしている人たちがよく登壇するんだがなあ…
- 242 ：
- むしろ対象を定義せずに、テストで何をするんだろう？わけがわからないよ。
- 243 ：
- >>241
まあ実践なんて一回使っただけでも言えるからねぇ w
で、ここ10年で広まったテスト技術って何よ？
- 244 ：
- >>233
C0,C1,C2カバレッジという観点は、内部構造の検証だろ
- 245 ：
- >>241
http://jasst.jp/symposium/jasst17tokyo/report.html
学術方面からとか、第三者検証をする人たちとか、丸投げする人たちメインな感じだが
- 246 ：
- 個人的には、第三者検証の人たちから、テストとは〜とか言われても響かないんだよ
「でも、あんたたち、プロダクトの設計もしてないしコードも書いてないでしょ」と思ってしまう
- 247 ：
- >>229
全く反論になってない
相変わらず頭悪いなお前ｗ
- 248 ：
- >>244
もちろんc0,c1,c2カバレッジは内部構造に着目しているけど、内部構造が正しいかを検証するためでは無い。
ホワイトボックステストは内部構造に着目して重複や漏れの少ない効率的なテストケースを作ろうと試みる手法だけど、その時にどれぐらい漏れているかを示す指標だよ。
テスト対象の内部構造を検証することと、内部構造の情報を元にテスト対象の検証効率を上げることを区別しなければならない。
前者はテスト対象を変えてしまってるため、適切なテストケースを作り直さなければならない。
- 249 ：
- >>247
君は相変わらず煽るのだけは上手いね
- 250 ：
- 言葉遊びの域を超えないね
>>248
> ホワイトボックステストは内部構造に着目して重複や漏れの少ない効率的なテストケースを作ろうと試みる手法
と繰り返しても、誰も納得しないよ
「ホワイトボックステストは、内部構造に着目してテストケースを決定し、その内部構造が意図通りに
実装されていることを確認するもの」と言ったらなにか反論できる？
- 251 ：
- >>249
ああああ煽りちゃうわ
- 252 ：
- >>250
言葉の定義合戦をしているわけじゃないんだよね。
ホワイトボックステストがテストの実施方法ではなく、テストケースの設計手法である、ということを認めないのなら平行線だろうね。
用語定義をあたってくれとしか言えないな。
「ホワイトボックステストを内部構造が意図通りに実装されてることを検証すること」と勘違いして人が多いってのが元々の主張だし。
そう考えてるせいで、ソースを逆翻訳したような試験項目や、見れば意図通り実装していることが自明なことをわざわざテストするような不毛な作業に苦しんでいる人がいると思ってるのだけど。
- 253 ：
- >>252
> 用語定義をあたってくれとしか言えないな。
偶然にも、全く同じことを言いたかったところ
ほれ、ホワイトボックステストを説明したページ
http://e-words.jp/w/%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E3%83%86%E3%82%B9%E3%83%88.html
http://www.sophia-it.com/content/%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E3%83%86%E3%82%B9%E3%83%88
https://en.wikipedia.org/wiki/White-box_testing
「ホワイトボックステストがテストの実施方法ではなく、テストケースの設計手法である」と定義してるページplz
> 「ホワイトボックステストを内部構造が意図通りに実装されてることを検証すること」と勘違いして人が多いってのが元々の主張だし。
「自分以外全員正しい」パターンでしょ
- 254 ：
- >>252
> 見れば意図通り実装していることが自明
さて、以下のコードが意図通り実装されているかどうか、見てすぐにわかるだろうか
if (hoge()) {
// process1
} else {
// process2
}
意図はすぐにわかるだろう
そして、コードが「意図」と一致しているかどうかを検証するのがホワイトボックステスト
ちなみにその「意図」は、外部要件とマッチしているとは限らない
- 255 ：
- >>253
ホワイトボックステストの用語定義を参照
http://jstqb.jp/dl/JSTQB-glossary.V2.3.J02.pdf
- 256 ：
- >>233
つかよく見たら、ホワイトボックステスト「設計技法」じゃねーか
設計技法の話をしてるんじゃねー
「ホワイトボックステスト」の話をしてるんだが
- 257 ：
- >>255
ほかのページを2,3例示plz
- 258 ：
- >>254
ちなみに、実装が実装者の意図通りに実装されていることを検証する目的は何？
その検証に支払うコストに対して、どういう成果が得られる？
- 259 ：
- >>258
> ちなみに、実装が実装者の意図通りに実装されていることを検証する目的は何？
おいおい、日本語大丈夫かよ
「実装が実装者の意図通りに実装されていることを検証する」こそがホワイトボックスてすとの目的だ
> その検証に支払うコストに対して、どういう成果が得られる？
TDDの文脈で言えば、確信・安心だな
つか、お前は「「実装が実装者の意図通りに実装されていること」は、いつどんなテスト手法で確認するんだよ？
- 260 ：
- >>256
いやだから、ホワイトボックス「テスト設計技法」でテストケースを作って、それを実施するのがホワイトボックス「テスト」だよ。
- 261 ：
- >>260
いい加減、勘違いに基づくアホ主張だったって認めろよ
- 262 ：
- >>250
>言葉遊びの域を超えないね
それは君が言葉の定義を理解できていないからでは？
- 263 ：
- という言葉遊びをまだしたいの？
俺は飽きたよ
- 264 ：
- >>261
ホワイトボックステストを「テスト対象の内部構造をテストする手法」と定義することに何のメリットも感じないからね。
ホワイトボックス/ブラックボックスが、テストの粒度や手法や対象を指す用語ではなく、テストケースを作る観点を指していると考えると、色々スッキリするのでお勧めするという程度にしておくよ。
- 265 ：
- ブラックボックステストのメトリクスをコードカバレッジで取ろうがどうでもいい。
そんなものはホワイトボックステストとブラックボックステストの違いの本質じゃない。
なんなら、組み合わせテストやペアワイズテストを実施した効果を評価するためにコードカバレッジを計測しても何の問題もない。
ホワイトボックスとブラックボックスで重要なのはテストデータを作成する基準なのだから。
- 266 ：
- >>264
スッキリしてないのはお前な
訳のわからん自分の勘違いに一つ気がついて皆にも教えてあげたいんだろうけど
そこを力説されても周りはポカンとするばかりなんだよ
あたりまえの事なんだから
お前一人レイヤの違うところで話をしてる
それどころかまだまだお前の勘違いは多いよ
もう少し素直になれば？
- 267 ：
- >>266
具体的にどうぞ
- 268 ：
- >>266
何が当たり前のことだと言いたいのか？
違うレイヤとはどのレイヤなのか？
他の勘違いとは何か？
ってところね。
そこが具体的じゃないと汎用煽り文句にしか見えない
- 269 ：
- >>264
それそれ
ブラックボックステストとかホワイトボックステストとかどうでもいいんだわ
ソースコードを少しでも修正した時に、今までやったテストを再度実行できますか？
で考えれば、手動でテストしていたら現実的に不可能
手動で行うテストは、テストのサボり方を計算しなければいけない。
サボり方と悪い言い方をしたが要するに、「コード修正したけど、
これぐらいならテストやんなくていいっすよね？ｗｗｗ」という話
手動でテストしていれば、コードを書きました→テストしました→バグが出ました→バグを修正しました→
修正した後のテストはしますか？前回テストでOKだった部分はテストしますか？
という問題が常に付きまとう
なのでコストが高いテストと、コストが低いテストにわけて、
○○というコードやシステムはテストのコストが高いです。
テストにかかるコストが低い方法に変更しましょうという話をするべき
ブラックボックステストとかホワイトボックステストとかいう区別はどうでもいい
なるべく小さいパーツでテストしたほうがコストがかからないということさえ知っていればいい
つまりはユニットテストでテストの大半を実施するのば良い
- 270 ：
- >>269
おいおい、ブラックボックステストとホワイトボックステストの違いが最もわかりやすいのがリグレッションテストだぞ…
- 271 ：
- >>270
ならそのテーマで違いをわかりやすく説明せよ
- 272 ：
- >>271
外部仕様が変わったら再設計しなければならないのがブラックボックスで作ったテストケース
内部構造が変わったら再設計しなければならないのがホワイトボックスで作ったテストケース
まあ何を元にテストケースを設計したのかを考えれば当たり前の話だ
ただしホワイトボックステストも入出力をテストしてる限りは外部仕様を満たすから、内部構造が変わったからと言って今迄通っていたテストが通らなくなるわけではない。
ホワイトボックスの観点で重複するケースや漏れてるケースが生じるだけだ。
逆に外部仕様を変えればホワイトボックスで作ったテストケースの想定出力値を変えなければならない。
- 273 ：
- やたらとスレ違いな話題を振って噛み付いてくるのがいると思ったらテストに関する総合スレというか隔離スレみたいなのがないのね。
そういうスレ立てて餌を付けといたら隔離できるかな? 障害は早めに摘み取らないと。
- 274 ：
- >>272
そいでリグレッションテストの話はどうしたよ？ｗ
外部仕様が変わろうが、内部構造が変わろうが、
コードを修正することに変わりはない。
条件によってテストケースを修正することはないと言いたいのだろうが
どちらの条件でもコードは修正する。
そのコードの修正が予想外の影響が現れていないかどうかを
確認するテストがリグレッションテストだが？
それとも外部仕様が変わったなら、新たにプログラムを作る。
既存のコードは修正しない。コピペして使うんだ。とか言いたいわけ？
- 275 ：
- >>272
> ただしホワイトボックステストも入出力をテストしてる限りは外部仕様を満たすから、内部構造が変わったからと言って今迄通っていたテストが通らなくなるわけではない。
それは予想外の影響が本当に現れてない場合ですよね？
予想できないから、予想外というのに、何もテストしなくて
予想外の影響が現れてないといえるのですか？
- 276 ：
- >>272
なるほどそうか。
あんたはテストを修正する必要がないといってるだけで
（テストを修正せずに）再度テストを行う必要がないとは言ってないわけだ
- 277 ：
- >>269
> ブラックボックステストとかホワイトボックステストとかどうでもいいんだわ
テスト手法を学ぶことには意味があるし、他者とコミュニケーションするときも意味がある。
上のように、君と君以外の「ホワイトボックステスト」の意味が異なると、まともに話ができません。
- 278 ：
- >>242
テスト対象を定義しないから、privateな関数をテストするべきか、なんて問題が生じるんだよ
テスト対象をclassにしたならば、privateメソッドはテストの入出力には使えない。ホワイトボックス手法で分析して、そのprivateメソッドを含めて網羅するpublicメソッドの入力値を探さなければならない。
それは非常に大変な場合が多々あるから、テストを変更するという対策が取られる。
大きく分けて２つ。テスト対象自体を変更する(privateをpublicに変えるとか)か、テストのスコープを変更する(classのテストをやめてclassの個々のメソッドをテスト対象にする)か。
どちらにせよ前までのテストは終わって別のテストを始めたと認識しなければならない。
- 279 ：
- >>276
そうだよ
テストケースを作るのとテストを実施するのを分けて考えなければならない。
それが顕著に現れるのがリグレッションテストだからね。
リグレッションテストは既にテストケースが存在していることが多いが、全部をそのまま使えるわけではないし、使えるテストケースの全てを実施するのことが費用対効果に優れているわけではない。
その時の指標になるのが、ホワイトボックス手法で作ったテストケースなのかブラックボックス手法で作ったテストケースなのかという情報だよ。
- 280 ：
- >>278
> classのテストをやめてclassの個々のメソッドをテスト対象にする
どういう世界にいると、こんな考え方になってしまうんでしょうね。
- 281 ：
- >>280
ある程度の高信頼性が求められるようなシステムでは大抵そこまでやってると思うが。
- 282 ：
- >>281
そういう話じゃなくて、「classをテストするぞというマインド」が、「classのメソッドを呼び出してテストする」とは
違うようだという驚き。
- 283 ：
- 単に、テストで確認する事柄が
「クラスが仕様通りに実装されているか」
から
「メソッドが仕様通りに実装されているか」
に変わるだけでしょ。よくあることだよ。
- 284 ：
- >>283
いやだからさ、君の言語が伝わってないってことなんですが。
- 285 ：
- 「テスト対象を定義」しろ
その対象とは、
・クラス
・クラスの個々のメソッド
である。
そして、両者には明確なマインドセットの違いが存在する。
というような考え方は、どこでなにをどのようにテストする文化だとそうなるんですかね。
ということなんですが。
- 286 ：
- >>285
質問なのか揶揄なのか分からないんだけど、聞きたいのは、以下のどっち？
・「クラスをテストする」と「クラスのメソッドをテストする」ことの違い
・「クラスをテストする」と「クラスのメソッドをテストする」ことの違いを認識するのに必要な文化
後者なら分かりません。
- 287 ：
- >>279
> リグレッションテストは既にテストケースが存在していることが多いが、全部をそのまま使えるわけではないし、
リグレッションテストの話です。
使えないテストケースとはどういうものですか？
繰り返しますが、リグレッションテストの話です。
- 288 ：
- >>279
> それが顕著に現れるのがリグレッションテストだからね。
リグレッションテストの話です。
顕著に現れた一例を教えてください。
しつこいようですが、リグレッションテストの話です。
- 289 ：
- >>287
リグレッションテストをするということは、変更した部分があるよね？
その変更によって、元々あったテストケースのうち、期待する出力が変わるテストケースと変わらないテストケースが存在する
期待する出力が変わったテストケースは再設計が必要になる。ここまでok?
- 290 ：
- >>288
しつこくリグレッションテストを繰り返すということはリグレッションテストとは何かについて合意が取れてないことをアピールしてるのだと思うけど
リグレッションテストを何だと考えてるか説明してくれる？
- 291 ：
- http://e-words.jp/w/%E3%83%AA%E3%82%B0%E3%83%AC%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%82%B9%E3%83%88.html
リグレッションテストとは、プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するテスト。
もっとも一般的に行われるのは、プログラムのバグを修正したことによって、そのバグが
取り除かれた代わりに新しいバグが発生していないかどうか、という検証である。
近年のOSのように大規模なプログラムでは、各部分のプログラムが複雑に関係しあっているために、
ある部分に加えた修正が一見何の関係もない部分に影響して誤動作を引き起こすことがある。
OSに修正パッチを適用したらアプリケーションが動かなくなった、といった話がそうした影響の代表例である。
- 292 ：
- https://enterprisezine.jp/iti/detail/195
システムに修正を加えた時、今まで動いていたところに影響が出ないことを
保証するのが、リグレッションテストです。
仕様の変更に伴う修正が入った場合も、システム全体への
影響を慎重に考える必要があります。
- 293 ：
- http://type.jp/s/itac/article23.html
上記以外に、『リグレッションテスト』と呼ばれるテストもあります。
リグレッションテストは、バグの改修後や仕様変更の対応後に行うテストのことです。
- 294 ：
- >>289
> ここまでok?
OKですよ。
でも次レスするときは「想定外」という言葉を使ってくださいね
理論上は問題ないはずだと思っていた想定が外れることを
想定外と言います。
- 295 ：
- >>294
ごめん、何を想定外と言ってるのか分からないわ。
理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、全てそのまま使えるはず、って言ってる？
- 296 ：
- めんどくせーから先に答えを書くか
リグレッションテストをするということは、変更した部分がある。
というか時系列が逆で、何かの理由で変更したならばリグレッションテストをする
変更した部分があるということは、それと同時に多くの変更してない部分が存在している。
出力が変わった部分のテストケース・・・新しいテストの実行（ブラックテストかホワイトテストかは関係なし）
↑こっちはリグレッションテストではないので無視してい良い
↓重要なのはこっち
出力が変わってない部分のテストケース・・・変わってない想定であるがもしかしたら変わってるかもしれない
本当に変わってないのか不安だ。こういう時にやるのがリグレッションテスト
変更した部分があるといっても、変更しない部分が大半であり
その変更していない初の部分に影響を与えていないかを調べるのがリグレッションテスト
だからいくら「出力が変わった部分」にフォーカスしても意味はない
変わってないはずのところが本当に変わってないことを調べるのがリグレッションテストだから
- 297 ：
- >>295
テストケースの話していない。
リグレッションテストは過去に存在するテストケースを
もう一度やる行為
テストケースではなくて行為
- 298 ：
- >>295
> 理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、全てそのまま使えるはず、って言ってる？
言ってない
理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、テスト対象以外は全てそのまま使えるはず、って言ってる
想定外の箇所＝テスト対処"以外"の箇所
に対してもう一度テストを行うことがリグレッションテスト
テスト対処以外は変わってないはずだって
再テストしなくても大丈夫だって思い込むのはやめなされ
- 299 ：
- >>297
いつから、テストケースの話でなくなったのか分からないわ。
- 300 ：
- >>299
リグレッションテストの話をしてからだが？
- 301 ：
- >>298
>理論上は、過去に設計したテストケースは、テスト対象に変更を加えても、テスト対象以外は全てそのまま使えるはず、って言ってる
テスト対象じゃなくて変更対象に関わるテストケースだよね。リグレッションテストのテスト対象は全体だから。
で、それ以外は全てそのまま使えるってことは、それは使えないって意味だよね。
使えないテストケースについて合意が取れたようで何より。
>テスト対処以外は変わってないはずだって
>再テストしなくても大丈夫だって思い込むのはやめなされ
やっぱりテストケースを作ることとテストすることを混同してる気がするよ。
- 302 ：
- >>300
>>287でテストケースについて質問しているように見えるけど？
- 303 ：
- 本当にリグレッションテストが分かってないんだなｗ
リグレッションテストは、変わってないはずのところが
本当に変わってないことを確かめるためのテストだって言ってるんだが
変更した部分があって、その変更した部分の仕様が "変わってない" ならば、
仕様を変えた部分を含めて、全てのテストケースをもう一回実施する
変更した部分があって、その変更した部分の仕様が "変わっている" ならば、
仕様を変えた部分を除いて、残りのテストケースをもう一回実施する
リグレッションテストのテスト対象は、最初から変わってないはずの部分と決まってるんだから
いくら変わったはずの部分のテストケースがどうとか話をしても意味がない
- 304 ：
- なんかこの話の噛み合わなさがスレタイっぽくなってきました。
- 305 ：
- >>302
リグレッションテストについて教えてもらえてよかったね
- 306 ：
- >>301
使えないテストケースの合意を取ってどうするの？
リグレッションテストの話をしてるんだから
変わってない部分（正確に言うと変わってないはずの部分）のテスト
変わってない部分なんだから、当然テストケースも使えるというのは大前提なんだが？
リグレッションテストの話をしましょうやｗ
- 307 ：
- で、リグレッションテスト＝変わってないはずの部分の再テストと
ブラックボックステストやホワイトボックステストがどう関係するのさ？ｗ
- 308 ：
- >>303
いや、そんなことは分かってるけど…
リグレッションテストにホワイトボックステスト/ブラックボックステストの観点がどう役立つかを知りたかったんじゃなかったの？
- 309 ：
- >>308
ここしばらく俺以外
ホワイトボックステスト/ブラックボックステスト
という用語すら出てこなかったよね？
それこそリグレッションテストと
ホワイトボックステスト/ブラックボックステスト には
何の関係もないことの証拠なんだがｗ
- 310 ：
- >>303
あ、一点意見が違うわ。
>変更した部分があって、その変更した部分の仕様が "変わっている" ならば、
>仕様を変えた部分を除いて、残りのテストケースをもう一回実施する
仕様を変えた部分を除いて残りのテストケースを実施するんじゃなくて、仕様を変えた部分のテストケースを再設計して、だ。
- 311 ：
- >>310
仕様を変えてテストケースも変えた時点で、
それはリグレッションテストではない。
リグレッションテストではないものの話はしてない
リグレッションテストの話をしている
- 312 ：
- >>311
つまり、テストケースを変えたらリグレッションテストとは認めないって主張ね。
よく読んで無かったけど、あのリンク先にはそういうことが書いてあるわけだ。
- 313 ：
- 変わってないはずの部分が本当に変わってないことを確かめるのが
リグレッションテストなんだからそりゃそうだろ
なんか引っかかるのは、全体を再テストした時
一部でも変わっている部分があるのなら、それは
リグレッションテストではないと言い出しそうなところだよなｗ
その場合は「変更された部分のテスト＋リグレッションテスト」を行ってる。
リグレッションテストをしてないわけじゃない。
やりたいなら別に分けて実行しても良いよ。その場合は変更された部分だけテストを行いました。
後日、それ以外の部分に対してリグレッションテストを行いました。となる。
分けて実行したと考えれば、リグレッションテストを行っていることが容易に理解できるだろう。
- 314 ：
- >>309
つまり、もう興味はないってことかな？
- 315 ：
- >>312
言葉が足りないね
- 316 ：
- >>270
> おいおい、ブラックボックステストとホワイトボックステストの違いが最もわかりやすいのがリグレッションテストだぞ…
最初に話を戻すと、ブラックボックステストとホワイトボックステストの違いと
リグレッションテストには何の関係もないってこった
- 317 ：
- >>316
うん、それで良いと思うよ。
君の勝利だ、おめでとう！
- 318 ：
- ああ、わかった、このバカは、
変更されていないコンポーネントに対するテスト実行のみがリグレッションテストだと思ってるわけだ。
「変更部分の影響範囲を調べて元のテストデータから再テストすべき部分を切り出し、
さらに追加すべきテストデータを作成して、リグレッションテスト用のテストデータを
作成する」ことはリグレッションテストに含めないと。
本物のバカだな。テスト工程とは何なのか、全く理解できていない。
- 319 ：
- おれのエスパー予想によると、
このバカは学部2年生ではじめて授業で「リグレッションテスト」なる言葉を聞き齧って
わけもわからずに独自解釈をわめきちらかしているだけ。
- 320 ：
- 多分、リグレッションテスト工程とリグレッションテストは違うと言いたかったんじゃないの？
知らんけど
- 321 ：
- >>381
> （ソースコードが）変更されていないコンポーネントに対するテスト実行のみがリグレッションテストだと思ってるわけだ。
それは違うよ。ソースコードが変更されてないのではなくて
仕様が変更されてない部分に対して、以前やってテストを
再度行うテストがリグレッションテスト
- 322 ：
- >>318
もちろんテストケースが足りなければ追加してもいいけど、
リグレッションテスト用のテストケースなんてのは存在しない。
そのテストケースをリグレッションテスト用にする必要はないから
負荷テストじゃないんだからさｗ
- 323 ：
- >>320
"リグレッションテスト工程"なんて言葉はないようですね。
Googleで検索したら一件しか見つかりませんでした。
普通そんな工程は存在しないってことでしょう。
- 324 ：
- 普通はリグレッションテストはテスト工程の一つとして行いますからね
- 325 ：
- >>318
> 「変更部分の影響範囲を調べて
リグレッションテスト目的が「想定外の箇所に影響を与えていないか？」だから
変更部分の影響範囲＝想定内の箇所
調べて影響ないと思ったが、想定外の箇所に影響があった！
↑これを知ることがリグレッションテストの目的なんだから
影響範囲を調べてそこだけテストするのは、リグレッションテストにはならないよ
- 326 ：
- リグレッションテストって仕様がドキュメント化されてなくて
実装が仕様ですみたいなソフトウェアに対してするもんだと思ってたよ。
- 327 ：
- >>286
> ・「クラスをテストする」と「クラスのメソッドをテストする」ことの違い
その違いとは？
> ・「クラスをテストする」と「クラスのメソッドをテストする」ことの違いを認識するのに必要な文化
微妙にニュアンスが変わっているが、どういう文化にいると上記のような使い分けをするようになるのか？
- 328 ：
- >>325
> 影響範囲を調べてそこだけテストするのは、リグレッションテストにはならないよ
またおかしなことを言い始めた。
影響範囲内のテストを再実行するのもリグレッションテストでしょ。
影響範囲調査が間違っていたというのは、また別の話。
・影響範囲を調査するのが困難
・その調査に誤りがある可能性が高いと思われる
・全部テストし直した方が速い
の場合は、全部テストすればいいさ。
- 329 ：
- >>326
いや、さすがにそれは違うでしょ
仕様がドキュメント化されていないソフトウェアは、どんなテストも総合テストや単にテストと呼んでいるイメージがある
- 330 ：
- 上で西先生disみたいなこと言ったが、いいこと言ってるわ（上から目線やめろ）
「【西康晴が語るソフト品質・第4回】テストの間引きが下手な企業は，品質事故が多発」
http://techon.nikkeibp.co.jp/article/NEWS/20060327/115426/
- 331 ：
- >>325
わかりやすいシロートだな。
ちゃんと先生のいうこと聞いて勉強するんだぞ。
そうしたら半年後には自分の書き込みを見て赤面できる程度の知識はつく。
がんばれ。
- 332 ：
- >>330
そういうこと。リグレッションテストもテストデータの間引きが重要。
- 333 ：
- 修正箇所から理論上変更が及ぶ可能性がある範囲と、
修正内容が「正しく」修正できていれば元と同じ振る舞いをする「はず」な範囲は別。
リグレッションテストは前者の範囲を再テストすることで、
後者の範囲の中にある誤り、つまり「正しく」修正できなかった箇所を発見する。
それがリグレッションテストな。
で、ホワイトボックステストとブラックボックステストでは、
リグレッションテストでのテストデータを間引くための技術が異なる。
当然のことだ。
- 334 ：
- 間引くってwwww
勝手にテストを間引くなよw
こういうの聞くといかにデタラメにテストしてるかが如実にわかるなw
普通はレビューで弾かれるもんだぜそういうのw
テストとして成立する前の話w
一度成立したテストはリグレッションで間引いてもいいテストなんかねえよw
- 335 ：
- >>330
で、これ10年以上前の記事なんだけどWモデルとか流行ってるの？
- 336 ：
- 一度テストしたものを間引くってわけじゃないだろ。なんでそんなアホな解釈になるんだか。
- 337 ：
- 記事では工数のためテストを間引くって言ってるから、
一項目数十分以上とかのテストで、開発工程が終了したモジュールのテストとか対象じゃないかな
ただ、リグレッションテストを間引くのは怖いよな
- 338 ：
- なんで俺がこれまで話してすらいないテストケースの間引きの話になってるんだよｗ
そもそもテストケースの間引きは、リグレッションテストではないものの話だろ
テストケースを必要十分に間引くって話はわかる
そして、え？なに？ 必要十分とされたテストケースを、リグレッションテスト用にさらにまびくの？
よくそんな恐ろしいことができるな。間引く理由は自動化されてないからかね？
- 339 ：
- >>333
> リグレッションテストは前者の範囲を再テストすることで、
> 後者の範囲の中にある誤り、つまり「正しく」修正できなかった箇所を発見する。
君の主張はわかった。だがそれは君の主張でしかない。
俺はちゃんと世間で言われているリグレッションテストの説明が
書いてあるページをもってきた。（上の方のレス参照）
それであんたの主張はそのページのどこに当てはまるのかね？
- 340 ：
- >>338
あげられた記事ではリグレッションテストを間引くって話をしてる
難しい作業であることも記事は認めてる
間引く理由は工数のため
テストケースが必要十分って網羅性の観点から出たような言葉使ってるけど、
バグ発見の費用対効果のために網羅性を多少犠牲にしてでも間引くのをうまくやろうって話だぞ
テストケースってテストの入出力のデータだよな？
「リグレッションテスト用のテストケースなんてのは存在しない」って主張してるけど、
テストが異なれば当然テストケースも異なるわけだし
例えば、CUIのプログラムのリグレッションテストって、
オプション引数と入力ファイル、出力ファイル、標準入出力をファイル化したものとかだぞ
もしかしてユニットテストを何度も実行することを回帰テストと思ってたりする？
- 341 ：
- だからなんで間引くって話になってるんだよ？
リグレッションテストとホワイトボックス・ブラックボックステストが
どう関係あるのかって話だっただろ
- 342 ：
- >>340
リグレッションテスト用に間引く＝既存のテストケースから
減らすってことを語っておきながら、
既存のテストケースにはないものを
追加するって話をしてるんだよ。ｗ
減らすのか追加するのかはっきりしやがれ
- 343 ：
- もう完全に最初の話題(議論には程遠い)から脱線してる。
ここ最近の話題として、まずはテストケース選択で白黒の定義をはっきりさせようとしてたよな。
で、コストバカが出て来て知らない言葉を勝手に追加し始めて発散して。
一旦もうどうでもいいや、ってなりかけたのに
>>270 がひょっとリグレッションとか言っちゃったのを調子乗りがすぐ拾っちゃったのが今の惨状なわけだ。
雑談好きにはいいヒマ潰しなんだろうがな。付き合いきれん。
君ら一応ロジックを書いてる人達なんでしょ? この程度の話の流れすら制御できないのか。
一旦このスレ全部読み返せ。赤面ものの恥しい展開になってるから。
- 344 ：
- こう言う基地外がプロジェクトにいるとテストしにくいよね
- 345 ：
- > 仕事の関係でJaSSTとかに何回か行ったことあるけどなんかこういう言葉遊びを延々やってるだけで全然まともなアウトプットがないんだよね
このスレと同レベルってことか
- 346 ：
- >>345
このスレにいる ID:Vv44G7XD みたいのがレベル低すぎて
せっかくJaSSTで説明してもらった話を理解できてないだけ。
- 347 ：
- 何かを考察するならともかく、単に相手を言い負かそうとしてるからね
匿名掲示板で自分が多数派だと主張し始めるやつが出てきたら、もう議論にはならないよ
- 348 ：
- このスレで勝利宣言したところで仕事が捗るわけじゃないのにな。
ほんとバカだ。
せっかく色々な人が教えてくれているのだから、
真摯に学べば、そのうち仕事も捗るようになるだろうに。
- 349 ：
- 学んでもバカが加速するだけだからバカなんだよw
- 350 ：
- >>346
で、JaSST のアウトプットってなに？
他人を見下す満足感ですか？ w
- 351 ：
- 末尾wは劣等感の表れ
- 352 ：
- リグレッションテストは自身に変更がなくても全然関係なさそうな他部署の変更とかセキュパッチ更新程度でも毎回通達が来るテストだぞ
変更当事者なら影響範囲を反映したテストを用意するし
その範囲はユニットテストとどまらない
- 353 ：
- もう、リグレッションテストの定義はそれぞれの心の内で解決して、テストしにくいコードをテストする方法について語ってくれ
- 354 ：
- じゃあテストしにくいコードって何なの
しにくいだけでテストできないわけじゃないよね
何か語る意味あるの
- 355 ：
- 具体的なコード例や体験談がたくさん報告されれば
よかったんだけどな
でも、スレで具体的なコードって十数行程度だろうし、
体験談も抽象的な書き方になって、このスレの住人だと設計が悪いで片付けられそうだ
- 356 ：
- >>354
> じゃあテストしにくいコードって何なの
しにくい = 時間がかかると読み替えればいいと思うよ
- 357 ：
- >>355
> 体験談も抽象的な書き方になって、このスレの住人だと設計が悪いで片付けられそうだ
なら設計が悪いコードを、設計を直さずにテストするチームと
設計を直してテストするチームに別れればいいともう
テストで頑張るって人は、そのままテストすればいいし
設計が悪いって言ってる人は設計を直せばいい
- 358 ：
- テストにかかるコストと時間が大幅に減れば
コードを修正するたびに全てのリグレッションテストを行うことも可能になる。
それができないところは、一部のリグレッションテストだけを
時々やる方式にするしかない。そうすると同意しても漏れが出てしまうし
問題に気づくのも遅れてしまう
- 359 ：
- 一般にテストしずらい原因
1. 仕様を誰も知らない
2. 実行時間が長い
3. 実行環境を用意するのが難しい
4. 依存関係がわからない
5. 非決定性プロググラムなため正しいか間違ってるかわからない
こんなとこかね。
それぞれで対処法を考えてくのもありかな。
- 360 ：
- マウスで手順通りポチポチやって同じ状態を作らないと
いけないってのはどれに当たるのかな？
- 361 ：
- そういう同じ状態なら仮想環境でポチポチ後にイメージコピって作れるじゃん
- 362 ：
- テストケースごとにデータベースなんかも含めた
全システムのイメージ作るってこと？
- 363 ：
- >>360
そんな事も出来なくてプログラマーとしてやっていけるの？
- 364 ：
- >>363
え？お前なら5秒でできるっていうの？
- 365 ：
- >>364
え？お前はマウスでポチポチ作らなくていいテストは5秒でできるの？凄いね！
- 366 ：
- 時間かかる的なのはUATの段階で予想外の障害が上がって来て
しかも障害上げた当事者はシステムのことを全く知らない
アポ取って現地行ってヒアリングして再現に時間が掛かったりする
結局それは窓の仕様ですねで時間だけ浪費して帰るみたいなことはある
- 367 ：
- 仮想環境を導入する権限ないプログラマとかいるからなー
あ、ホントにテストしにくいコードをテストする方法って、
上司の説得の仕方とか、権限の拡大の仕方とか、そういうことなのか？
- 368 ：
- >>365
テストケースが10000個あったとして1個5秒もかかっていれば
833分、13時間、コード修正のたびにこんなに時間かけてりゃ
やってられんだろ。5秒でも長すぎる。
遅くとも1個あたり0.01秒ぐらいで全てテストしたとしても100秒
程度じゃなければやってられん
- 369 ：
- >>368
InMemoryのUnitテストならミリ秒単位だろ
- 370 ：
- >>368
5秒って実行時間の事かよ。だったら
>どれに当たるのかな
なんて聞くまでもなく自明だろ？
- 371 ：
- >>335
> で、これ10年以上前の記事なんだけどWモデルとか流行ってるの？
千人月を超える規模の開発では、ウォーターフォールあるいはウォーターフォールを内包した
スパイラルモデル（あるいはそれもどき）で開発するのが主流。
Wモデルという単語自体が現場で飛び交っているかどうかは不明だが、その概念は今や常識だろう。
アジャイルや数十人月程度の小さなシステムなら、そもそもVモデルっぽい開発はしない場合が
多いだろう。なので、Wモデルという概念もない。
- 372 ：
- >>371
> その概念は今や常識だろう。
コーディング前に全てのテスト設計が完了してるなんてほんとに実現できてるの？
> 数十人月程度の小さなシステムなら、そもそもVモデルっぽい開発はしない場合が
> 多いだろう。
普通にウォーターフォールで開発してるけど？
- 373 ：
- >>372
> コーディング前に全てのテスト設計が完了してるなんてほんとに実現できてるの？
Wモデルのことを理解してないでしょ。
http://www.itmedia.co.jp/im/articles/1111/07/news202.html
> 普通にウォーターフォールで開発してるけど？
で、いまだに上流工程での設計ミスが、受け入れテストで発覚なんてやってるの？
- 374 ：
- あ、わかった。
>>372
> コーディング前に全てのテスト設計が完了してるなんてほんとに実現できてるの？
俺が言ったのは、Wモデル（あるいはそれに類するような概念・問題意識）が常識だということで、
「Wモデルの実施」が常識的に行われているということではない。
実施そのものはまだまだ、あるいは試行錯誤中ってとこが多いと思う。
2012年時点の雰囲気：
http://www.kumikomi.net/archives/2012/03/rp11jas2.php
- 375 ：
- >>374
概念は知ってるけど実践はできてないってこと？
10年も経ってそれって意味ないじゃん w
- 376 ：
- >>375
どうとでも、とって（投げやり
- 377 ：
- 結局口先だけなんだよな...
- 378 ：
- はっきり言えばいい。
Wモデルは実施されていない
- 379 ：
- >>373
大丈夫。設計ミスなんて忖度で存在しなかったことになりますから。
コーディング、テスト担当が数人クビになってその派遣元が取引停止になるだけです。
- 380 ：
- 実施される/されないとかじゃなくて、モデルってのはそういうものだ。
バカじゃねーの？
- 381 ：
- >>380
また実践もできない口先君が来たのか w
> モデルってのはそういうものだ。
具体的にどう言うものか書いてみ
- 382 ：
- 半角スペース+wで荒らしてる奴、他のスレでも見た気がするぞ
- 383 ：
- 末尾wのレスを抽出すれば分かるが、基本的に無視して構わないことしか言ってないので、簡単にNGに出来るよ
- 384 ：
- ウォーターフォールにおけるV-modelからのW-modelの流れは、BDD(Befavior Driven Developemtn), ATDD（Acceptance Test Driven Development)アプローチと似てると思う。
いずれにしても、テスト準備を前に持って行けば持って行くほど、問題の解決コストが低くなる可能性が高くなるというのがメリット。
- 385 ：
- 糞みたいなうんちくはどうでもいいよ。
意味のないテストは削除して、意味のあるテストを増やしてけばいいだけ。
それができないのが問題なだけなんだよ。
- 386 ：
- >>384
> いずれにしても、テスト準備を前に持って行けば持って行くほど、問題の解決コストが低くなる可能性が高くなるというのがメリット。
で、なぜ流行ってないの？ w
- 387 ：
- 低くなる可能性が高くなる
馬鹿特有の言いまわしですよこれ
- 388 ：
- >>387
さすがにそれはお前がアホすぎる
- 389 ：
- >>386
テストを先に書けるだけ要件が決まってるプロジェクトが流行ってないからだろ。
>>387
[[コストが低くなる可能性]が高くなる]という構造を勝手に壊すのは馬鹿特有の解釈だと言うことができます。
- 390 ：
- >>389
いやいや金融の案件とかやったことあればわかると思うけどレビューやりまくってがっちがちに仕様決めてからやるプロジェクトもあるよ
でもWモデルなんて実務で見たことない
- 391 ：
- >>390
成功したwモデルを見たことないならともかく、失敗したwモデルも見たことないなら、単に見たことのある現場が少ないだけだよ
- 392 ：
- >>391
まあうちの会社は基本的に金融関係はあまりやってないからそんなにたくさんは見てないよ
そもそもその手のプロジェクトだと２〜３年はかかるし
で、君のところではWモデル使ってるの？
- 393 ：
- >>391
wモデルが使われてないってだけでは？
- 394 ：
- >>390
その金融の案件の詳細はわからないけど、勘定系システムの場合は早い段階（上流工程）からQA担当が入るだろ
- 395 ：
- Wモデルが普及してないのは明らかなんだが、何をこだわってるんだろう？
Wモデルとか言ってた奴pgrってこと言いたいのか？
- 396 ：
- Wモデルが普及してないとしても、方法としては非常によいもののように見える
普及していないというのは、どういう理由なんだろう？
a. マイナーな方法なので誰も知らない
b. 呼び方が定着してないだけで実践されてる
c. Wモデルの方法では欠陥がある（コストとか？）
d. 業界がテストの最新方法を取り入れるのが遅れている
testing w-model とかで検索したら、それなりにヒットしたので a. ではないな
日本では流行ってないということなのかな？
e. 日本で取り入れるのが遅れているだけなのか、
f. 日本のソフトウェア業界には合わないのか
というのも追加しとこう
- 397 ：
- >>393
見たことのある人が存在する以上は使われていないってことはないな
N系の大規模開発で見たことあるよ
- 398 ：
- >>392
使うプロジェクトの時も、使わないプロジェクトのときもある
wモデルのおかげで成功したと感じたことは一度も無い
- 399 ：
- >>394
入るけどその上流の段階でテスト設計して仕様にフィードバックしてる？
>>397-398
そりゃ一回でも使われてたら
「使われてないことはないな」
って言えるけどそんな話をしたい訳じゃない
いったいどれぐらいの割合で使ってるの？
って話
- 400 ：
- >>399
> 入るけどその上流の段階でテスト設計して仕様にフィードバックしてる？
そりゃ、テスト設計の知見により仕様に誤りや漏れが発見されたら、
当然フィードバックされるでしょ。
- 401 ：
- >>399
>いったいどれぐらいの割合で使ってるの？
>って話
それは使われてる割合の大小で何かを主張したい人が調べるべきでは？
割合を論点にするなら、あなたが全体のどれぐらいのプロジェクトを見たかを示さないと、見たことがないから流行ってないと主張は無意味ですよね。
- 402 ：
- Wモデルって、アジャイルでいうプラクティス的なものがきっちり決まってるわけじゃないから、
「今回はWモデルを採用しました」みたいなことが言いづらいってのもあるかもね。
QAチームが独立して入る、ある程度以上の規模のプロジェクトなら、Wモデル的な何かの
取り組みは大抵してる気がするんだがどうだろうか。
- 403 ：
- >>390
おまえの世間は狭いな。
- 404 ：
- >>396
他の開発モデルと同様に、取り入れられても事例として明らかにできない事情が多いから。
- 405 ：
- >>400
> そりゃ、テスト設計の知見により仕様に誤りや漏れが発見されたら、
> 当然フィードバックされるでしょ。
いや、だから上流段階でテスト設計までしてますか？ って話
>>401
ざっくり100プロジェクト程度を見てもうちではほぼ使われてない
君のところでは使われたり使われなかったりするんでしょ？
で、その割合はどんなものかと
- 406 ：
- >>397
> 見たことのある人が存在する以上は使われていないってことはないな
確率の問題。見たことある人が極端に少ない以上
殆ど使われてないと判断するしかない
最悪のケースでは「一件だけ使われている」ことだってありうる。
- 407 ：
- 要件定義の時点で「顧客はこの画面で入力値を1コ増やしたがる」と予見できるなら
できるかもしれないが
相手だってこっちだって全部わかってるわけじゃないんだよ
という現実的な問題がある
初期の経済学では「市場参加者は全部ワカってるはずだ」と仮定してて
そりゃないだろっつって情報の不均衡とか言い出して
最終的には「知ってる/知らない」をモデルに盛り込んだ理論でようやくってところだ
- 408 ：
- 日本で使われてる使われてないとか、どうでもよくね？
- 409 ：
- >>406
うん。気になるなら調べてみれば良いんでないの？
- 410 ：
- 調べた結果はもうわかってるよ。
使われているという実例は存在しない。
結論としてはそれで良いはずなんだが、
肝心の反論する人が反論の根拠を示さないから
あーだこーだいう羽目になってる。
やめやめ。Wなんたらとかは使われてない。以上。
- 411 ：
- >>410
おまえの狭い世界では、だな。
現実世界では少なくとも俺は複数事例を知っている。
- 412 ：
- でも使われてる割合は明かせない
ってか w
数回使っただけで実践中って言うのはよくある話
- 413 ：
- >>410
現在進行形で使ってるんだが
- 414 ：
- >>402
まずWモデルと名乗って導入する前にV字モデルで開発プロセスを適用してなければならない。
それまでのプロセスをV字モデルと呼んでなければ、Wモデルと呼ぶことはないだろうから。
次にV字モデルの実施者にとって、Wモデルは、単純に工数を二倍にして先にテストプロセスを開始して設計プロセスに重ねただけに見える。
こう捉えてしまうと、V字モデルに比べて二倍の成果が出ないと元が取れた気がしない。人月の神話で有名なように、期間辺りの人員を二倍にした場合、成果は二倍を下回る。
最後に、Wモデルは何をやるかについては言及しているが、何をしないかについて言及していない。
だから、やることが増えることによって、開発プロセスの制御が困難になることに対応する指針にも使えない。
結局、このモデルの役割は、設計が終わらなければ試験設計を始めることが出来ない、という固定観念を崩す程度でしかない。じゃあ、どうやったらそれが上手く出来るのか、についてまで踏み込めていない。
固定観念を崩すということについては、実装を行う前に試験を実施する「テストファースト」に比べると、それほど突飛な事を主張しているわけでもない。
- 415 ：
- >>413
君はZモデルを知ってるかね？
俺のは複数の使用事例を知っている。
使用している割合はあかせないが
現在進行形で使ってるんだが？
疑うんじゃねーよ
- 416 ：
- >>414
> 次にV字モデルの実施者にとって、Wモデルは、単純に工数を二倍にして先にテストプロセスを開始して設計プロセスに重ねただけに見える。
スキルの低い奴がTDDをやっても意味がないように、スキルの低い集団がWモデル（やそれに類する取り組み）をやっても意味がない。
そういうことだよ。
- 417 ：
- >>410
> 使われているという実例は存在しない。
いや、軽くググった程度で事例は見つかるだろ。
> やめやめ。Wなんたらとかは使われてない。以上。
なんでそういうことにしたいのか、そのモチベーションはどこから来てるんですかね。
- 418 ：
- >>405
> いや、だから上流段階でテスト設計までしてますか？ って話
するでしょ。
もししないのなら、上流から入ったQAチームは何してるんだ？
- 419 ：
- >>418
> するでしょ。
なるほどちゃんとやってるところもあるんだな
> もししないのなら、上流から入ったQAチームは何してるんだ？
QAの観点でのレビューと仕様の早期把握でしょ
- 420 ：
- そもそも上流て設計する工程ちゃうでｗ
- 421 ：
- >>415
キチガイか
- 422 ：
- >>415
そのZモデルについて語りたいなら、存分にどうぞ。
どれぐらいの割合で使われているかに関係なく、何か役に立つ示唆を与えてくれるモデルなら、興味を持つ人もいるだろう。
- 423 ：
- 俺が言うのもアレだが、このスレって
>>1
> ここで言うテストっていうのは
> ユニットテストみたいなものね。
なんだよね。
- 424 ：
- ユニットテストはテストコードを書いてやるものだけじゃないけどな
- 425 ：
- 結局、知識も調査能力も低いバカが「Wモデルなんて使われてないもーん」と駄々をこねていただけでした。
ちゃんちゃん。
- 426 ：
- >>414
>次にV字モデルの実施者にとって、Wモデルは、単純に工数を二倍にして先にテストプロセスを開始して設計プロセスに重ねただけに見える。
それはお前がバカだから。
- 427 ：
- >>426
そんなに構って欲しいのか？
- 428 ：
- >>425
具体的な数値を出さずに実践してますから〜
ってか w
- 429 ：
- Wモデル？聞いたことないわw
↓
あれ、知らないの俺だけ？
↓
いや、全然使われてないっしょ？w
↓
ん？そうでもないのか？
↓
具体的な数値出せやw
↓
とでも言っとけば、誰も出せないからマウント完了w
な感じか
- 430 ：
- 傍目にはデタラメなネコパンチ合戦にしか見えないけどこんなのでマウントって言うの？
- 431 ：
- >>429
> とでも言っとけば、誰も出せないからマウント完了w
こういうのはマウントと言わないでしょ？
裁判かな？
証拠出せ！証拠ありません！
じゃあ認められないな
閉廷
- 432 ：
- >>429
> Wモデル？聞いたことないわw
そんなこと言ってるのはお前だけ
バカは絡んでくるなよ
初っぱなの >>330 を除けば具体的な話は >>373 と >>374 だけ
>>373 は上っ面の説明だし >>374 は JaSST の発表で５年前で試行錯誤って状態
ググればわかるけど2012〜2013辺りはそこそこ活発だったけどその後は鳴かず飛ばず状態
嘘だと思うなら期限を一年以内にして Wモデル でググればいい
ある意味笑える
- 433 ：
- Wモデル否定バカがどんどん主張がショボくなっていくの笑える
Wモデル？聞いたことないわw
↓
あれ、知らないの俺だけ？
↓
いや、全然使われてないっしょ？w
↓
ん？そうでもないのか？
↓
具体的な数値出せやw
↓
期限を一年以内にしてWモデルをググっても出てこないぞ
ほんとバカだわ。こんなのがソフトウェア開発業界にいるんじゃ、そりゃ炎上案件が出るわ
- 434 ：
- ググってリンク貼るのが調査です！
- 435 ：
- 具体的な事例も出せずに使ってるうって言うだけの簡単なお仕事お疲れ
- 436 ：
- モデル名クイズスレとかでも作ってそっちでやれ。
これなら脚の本数でグダグダ言ってる方がまだテストスレっぽいわ。
- 437 ：
- Wモデルがなぜ失敗したのかを調べたほうが良いだろうね。
- 438 ：
- そっちの方が価値があるだろうね
- 439 ：
- 研究成果が世の中に浸透するのに時間がかかる分野ってあるから、
流行してない ＝ 失敗というのは早すぎるんじゃないかな？
最近ラムダ式がプログラミングでは一般的になってきた感じがするけど、
理論は 1930年代からあったみたいだし……
テストのような応用分野では普及はもっと早いとは思うけど
- 440 ：
- >>439
使われないのと
使われてるのに評価されないのとは意味が違うよ
使われてないものは、使われ始めてやっと評価されるが、
Wモデルは使われてるんだろ？
なのに評価されてない。
ダメだったってこと
- 441 ：
- >>439
流行しているかどうかを気にしているのは少ないんじゃないか？
たとえ流行していたとしても、Wモデルに開発モデルとしての価値はないと思ってる
- 442 ：
- 流行に流されない俺かっこいい的な事を言いたい模様
- 443 ：
- >>442
実際に言ってるのはお前だけどなｗ
- 444 ：
- 流行は亡くなったろ
- 445 ：
- >>441
TDDに開発モデルとしての価値はないと思ってる
アジャイルに開発モデルとしての価値はないと思っている
なんでも言えるな
- 446 ：
- >>445
お前は何も言ってないけどな
- 447 ：
- >>446
俺が何も言ってないんだとしたら、>>441も何も言ってないな
- 448 ：
- ちなみに俺は何も言ってないよ
- 449 ：
- >>447
じゃあ、なんでも言えるんじゃなくて何にも言ってないってことで
- 450 ：
- 日本人じゃないのか、致命的に日本語能力に欠ける日本人なのか
- 451 ：
- そんなに自分のことを卑下しなくてもいいのに
- 452 ：
- >>440
ダメなのはお前だバカ
- 453 ：
- 俺が知らないものは世界には存在しない教
俺が見えないものは世界には存在しない教
ググって見つかっても、やはり世界には存在しない教
- 454 ：
- そろそろスレタイ見直すべきじゃない？
- 455 ：
- >>453
存在は誰も否定してないよ。
それが有効かどうかって話
- 456 ：
- >>454
別にここのスレを存続させる必要はないから放置しとけばいいよ。
気になって見てしまった人にとっては釣りスレになるけどしゃーない。
- 457 ：
- >>455
まずやってみろよ
- 458 ：
- 自分とこのプロジェクトがWモデルだとしても、
曽孫受け末端PGは気付かないだろうからなあ。
Wモデルなんて使われていないと言っているのは
そういうレベルの連中なんだろう。
- 459 ：
- つーか現状で何が不満なわけ？
Wモデルは使われてない（反論するなら証拠出せ）派と
Wモデルは使われてる（証拠はない・だせない・示せない）派に別れてるでしょ？
使われてない派は、（自分の意見が正しくあるために）証拠が出ないことを望んでいる
使われてる派は、（何らかの理由で）証拠を出さないことを望んでいる。
どちらも「証拠はない」という現状で満足しているわけだから
これで両者とも納得してると思うんだけど？
あとは「証拠がない」故に使われてない
「証拠がない」が使われてるという風に
お前ん中ではなという結論でしょ？
相手を説得するつもりがないんだから、これで解決じゃね？
（これ以上のレベルで相手を説得したいならどちらにしろ証拠を出すしかない）
- 460 ：
- >>458
害虫さん乙
普通の企業ならWモデルみたいなプロセスの変更がある時は全員に教育するよ
でないと混乱するし
- 461 ：
- >>460
最初からW次モデルの場合は教育しないのかよ
- 462 ：
- >>459
普通に使われてると主張してる奴が証拠出せばいいだけ
>>374 によると５年前でも導入するかしないか程度だからその後普及してるなら JaSST とかでもっと発表があるはず
でも実際は...
ってことでしょ
>>461
> W次モデル
なんだその新しいモデルは？ w
- 463 ：
- 検索すればたくさんヒットするじゃん
グーグル検索にヒットするのは氷山の一角だから
潜在的な利用数はその千倍あると言っていいでしょう
- 464 ：
- >>459
Wモデルの使用例を知っている人にとって、使われていることなんて自明だから議論の対象ですらない。
また、自分がWモデルの使用例を知らないから殆ど使われていないと主張する人を納得させるメリットもないから、単に馬鹿にして楽しんでいるだけ。
Wモデル自体のメリット・デメリットについて興味ある人が二人以上同時に現れないから、それについての議論は始まってもいない。
- 465 ：
- >>463
> 検索すればたくさんヒットするじゃん
最近の話題を10件ぐらい出してみそ
- 466 ：
- 品質保証に1ミリも興味なさそうなんで、会話しても意味ない
- 467 ：
- >>466
うむ。品質保証どころかコードの臭いもしない。伝書鳩が騒いでると思って諦めてる。
- 468 ：
- >>465
自分でググればいいじゃん
- 469 ：
- > 検索すればたくさんヒットするじゃん
> 最近の話題を10件ぐらい出してみそ
> 自分でググればいいじゃん ← 今ここ
分かりやすすぎる w
- 470 ：
- >>462
> 普通に使われてると主張してる奴が証拠出せばいいだけ
使われていると主張しているやつは
証拠を出したくないんだよ
それがわからないの？
使われているやつは、証拠を出したくない。
使われてないと言ってるやつは、証拠を出してほしくない
両方共証拠がない方がWin-Winでいいだろ？
なんで証拠を求めるんだ？
- 471 ：
- このまま証拠がない状態であれば、
証拠がないのは、自明なことだからだろ。ふふふん。
と言ってるやつと
証拠がないのは、使われてないってことだろ。ふふふん。
と両方がこういうふうに思ってる。
ほら両者満足じゃん？
ふふふんと本気で思っているならば、
証拠がない状態で満足なんだから、
現状維持（証拠はない）にしておけよ。
- 472 ：
- >>471
何言ってんの？ずっと現状維持に決まってんじゃん
誰も解決しようとなんてしてないだろ
- 473 ：
- >>470
> 使われていると主張しているやつは
> 証拠を出したくないんだよ
出せないだけだろ
Win-Win とか頭にうじでもわいてるのか？
- 474 ：
- 使っている：NTTデータ、日本ユニシス、複数の第三者検証会社
- 475 ：
- まあ、日立も富士通もNECもどこでも、Wモデルに類する取り組みはやってると思うがね。
やってないと思いたい理由がわからんわ。お前に関係ないだろと思うね。
- 476 ：
- >>475
日立は基本Wだね
- 477 ：
- 議論に証拠は必要ないと思うけどなあ
- 478 ：
- 裁判プレイなのかね
- 479 ：
- 議論するつもりなんかないでしょ
- 480 ：
- 言い負かすのが目的になってて、自分の知識を増やしたり新たな考え方を知ろうというのを目的にしていないから
- 481 ：
- >>476
メジャーなSIerの名前だして使ってる（はず）って言うだけの簡単なお仕事お疲れ w
SQiP2013 の論文も読んだことないんだろうな
- 482 ：
- >>481
君はHIPACE読んだことないんだろうな
- 483 ：
- >>482
第５版の方？
それとも Agile Scrum Methodology の方？
両方ざっと見たけどWモデルの話なんて見当たらないからどこに書いてあるのか教えてくれるかな
- 484 ：
- >>481
SQiP2013 の論文を読むと、メジャーなSIerのどこでもWモデルに類する取り組みがなされてないことがわかるのか。
- 485 ：
- つか、Wモデルを否定している奴のところは、QAチームはどのへんからプロジェクトに参加するんだ？
- 486 ：
- >>483
読んでないのがバレバレ
- 487 ：
- >>484
えっ？
日立の話だろ？
SQiP の論文見たことないのか？
>>485
ものによるけどでかい案件だと受注段階から絡んでるよ
でもそれとWモデルの話は別なのぐらいはわかるよね？
>>486
具体的に書けないなら黙ってろよ w
第５版って書けばイントラ見れる奴ならわかるはずだし
- 488 ：
- >>487
俺は読んでないよ。
説明してくれるかい？
- 489 ：
- >>488
まず読めばいいと思うよ
https://www.juse.jp/sqip/symposium/archive/2013/day2/files/ronbun_A3-3.pdf
俺の感想は相当レベル低いな
って感じだけど w
- 490 ：
- >>487
日立のイントラ見れるやつならすぐわかるだろ
今時新入社員研修でも扱ってるし
- 491 ：
- オープンソースプロジェクトでの採用事例無いの？
- 492 ：
- >>489
これって、wモデルを適用したって論文じゃないの？
- 493 ：
- >>490
だからどこに書いてあるんだ？
内容は書かなくて良いから章・節番号を書いてみて
>>492
そうだよ
ちょっと試してみましたって奴
その後使われてると言う話はさっぱり聞かないけどね
- 494 ：
- >>493
じゃあ>>475の言うとおりwモデルに関する取り組みはしてるってことじゃないか
- 495 ：
- そしてその取り組みは終わったんでしょう？
- 496 ：
- >>494
>> 数回使っただけで実践中って言うのはよくある話
- 497 ：
- 大企業ってはたから見れば意味のないことやるからな。
ちょっとした検証した程度で、すごい効果がありましたって
プレスリリースだすのには驚いた。
大企業ってのは小さな部門がたくさんあって成果を出しなさいって
上から言われてるから、内容はともかく「成果を上げた」ということを
会社に知らせるためにやってるんだろうなって聞いてて思った。
あとプレスリリース自体が宣伝になってるとかね
- 498 ：
- >>496
ようするに、あまり使われてないって主張したいのかね？
- 499 ：
- >>495
知らん
もう取り組んでないって論文が出てきたのかと思って聞いだけ
- 500 ：
- >>497
まあやってみないとわからんからやることは別におかしくない
やったらそれを報告しないとなにもやってないと思われるしね
>>498
そうですけどそれがなにか？
>>499
なにか別のやり方に変えるとか以外でそんな論文見たことある？
- 501 ：
- >>500
論文を引き合いに出すわりには、想像を語るだけなんだなぁ
- 502 ：
- >>500
俺が言いたいのは報告するかどうかじゃなくて、
その報告にどれだけの価値があるのかってことだよ
アフリカに井戸を作りました。という報告はいいけど、
その一年後、どうなっているかを見に行ったら
井戸は破壊されていました。じゃ問題は解決してないだろう？
重要なのは「その報告」をその後どう役立てたかだよ。
- 503 ：
- >>501
想像？
HIPACE ガーって言うから具体的にどこ？
って聞いたらノーレス
これが事実ですよ w
- 504 ：
- >>502
> その報告にどれだけの価値があるのかってことだよ
書いてあるだろ？
>> 報告しないとなにもやってないと思われるしね
> 重要なのは「その報告」をその後どう役立てたかだよ。
それは各組織内の話
まあ役立てられてたらHIPACEとかにも反映されてるはずなんだが...
- 505 ：
- >>503
想像で悪いわけじゃないけど、>>484の反論に対して、論文を読めみたいに言うから、wモデルの普及率についての論文なのかと思ったら全然違ったので
- 506 ：
- >>505
普及率を論じられた資料も見つからない
ってことでお察しください w
- 507 ：
- >>503
うん、読んでないんだよね君は
- 508 ：
- >>507
日本語を理解できないのかな？ w
>> 両方ざっと見たけどWモデルの話なんて見当たらないからどこに書いてあるのか教えてくれるかな
- 509 ：
- >>506
そりゃ普及率を気にする人が少ないからでは？
ちょっと気になって調べたら、これの総論8ページで、
>近年，V字型モデルを進化させたダブルV字型(=W字型)モデルが利用される ようになってきています。
ソフトウェアテスト見積りガイドブック
http://www.ipa.go.jp/files/000005132.pdf
って書かれてたわ。
本当かどうかは各自で判断してください。
というか、無料でこういうのが読めるんだな。ありがたい話だ。
- 510 ：
- >>509
> 本当かどうかは各自で判断してください。
それは不可能。証明責任は主張する側にある
- 511 ：
- >>510
コストはそれによって利益を受ける側が負担すべき
疑うならIPAに問い合わせなよ
- 512 ：
- 聞いた所で利益は得られない。
本を配布して宣伝する側が利益を受けているわけで
やっぱり本を書いた側が負担すべき問題だなｗ
- 513 ：
- >>508
日本語を理解できないのかな？
新入社員研修ですら嫌と言うほど見せられる有名な図だよ？読んだことないのがバレバレ
- 514 ：
- > 新入社員研修ですら
いくつの会社の新入社員研修ですか？
- 515 ：
- >>514
知らないね。ただHIPACE扱うような会社なら避けられないような重要な項目。ほら見てないんでしょ？
- 516 ：
- >>508
グループ外秘じゃねえの？
- 517 ：
- >>515
だって、他社の新入社員研修なんて知らないしｗ
お前の知ってる一社以外では
使われてないんだから
知るわけないよね？
知らない人が多い = 使われてないということ
- 518 ：
- > HIPACE扱うような会社なら避けられないような
HIPACE = HitachiHigh-Paceを扱うような会社って
日立システム以外の会社で使われてるんですか？
日立システムの下請けとか子会社に押し付けてるから
使われてるんだ！なんてのはなしですよｗ
日立システムとは関係ない、例えば海外の会社で
使われてるんですか？
- 519 ：
- >>517
日本語読めないの？HIPACE読んだなら書いてあるでしょって言ってんのwww
- 520 ：
- HIPACEなんてゴミを読む人はいませんよ。
- 521 ：
- >>518
日立システムってなあに？
- 522 ：
- HIPACEは日立の社員が、会社からよめと
押し付けられるものですからねｗｗｗ
- 523 ：
- うひひひひｗ
http://blog.goo.ne.jp/katakait/e/acf5eda9e249719a0795c5e1692b8097
富士通のSDEMに対し、日立はHIPLAN、HIPACEと言っていた開発方法（手順）です。
当時、その会社にいましたが、これに従って資料を作ったらとんでもない手間になって
しまいます。しかし、デザインレビューでは、アレをやったか、コレをやったかと責め
立てられます。バ〜カ！と思いつつ、ＳＥは時間をかけて体裁を整えていました。
決してお客さんのためではない時間の使い方です。そもそも、分厚い設計資料を見て
喜ぶお客は、システム導入で効果を出そうなどと思っていないでしょうね。教条主義な
設計手順、その全体となるＲＦＰ、いずれも遺物ならぬ異物です。
誠に情けないことですが、後生大事に今でもこの発想がはびこっているのが現状です。
大手SIerでこれに染まっていないところがあれば、そこに開発依頼をしたいものです。
しかし、我こそは、という気鋭のSIerに任せて安心できない、というのも一方の現実。
難しいですね、この辺。
- 524 ：
- http://sugi-tec.tokyo/2015/03/09/%E3%82%A6%E3%82%AA%E3%83%BC%E3%82%BF%E3%83%95%E3%82%A9%E3%83%BC%E3%83%AB%E6%99%82%E4%BB%A3%E3%81%AE%E6%89%8B%E6%B3%95%E3%81%AB%E5%9B%BA%E5%9F%B7%E3%81%97%E3%81%AA%E3%81%84/
大型コンピュータから出される帳票、伝票を見ながら仕事する時代が
１９７０年前半からパソコンが業務処理の主役に台頭してくる１９９０年前半まで
長い間続いていました。この時代、大手コンピュータベンダに人材が集まり、
各社から様々な開発手法が発表されました。日立はHIPACE、HIPLAN、富士通は
SDEMなどがありましたが、いずれも仕様ががっちり固まってからのウオータフォールが前提でした。
- 525 ：
- 用語集
HIPACE(日立システム開発方法論)
- 526 ：
- 凄いぜスレ違いを延々と続けるこの情熱。普及してるとかしてないとかがそんなに大事な事なのか？
なんというか典型的な日本人って感じだね
- 527 ：
- >>509
それ何年前の本なのか知ってる？
あと独立行政法人だからそれなりに税金投入されてるのでただと言う訳じゃないよ
- 528 ：
- >>513
具体的な場所を示せない時点で吹いてるだけなのがバレバレ w
>>516
そんなにハードルは高くないけど閲覧は特定のグループ会社のみだよ
>>524
一応改訂してるから汎用機時代のままじゃないよ
まあ現場からの評判は散々なのは変わらんけど w
- 529 ：
- >>527
知ってるよ。2008年付だから9年前だね。
独立行政法人なのも知ってるよ。税金投入されててもこの文脈では無料と言うよね、
- 530 ：
- >>528
具体的な場所を示せない時点で読んでないのがバレバレwww
- 531 ：
- >>518
ねえねえ日立システムってなあに？
- 532 ：
- このスレの役目は前スレ時点で終わってるからスレ違いだろうがなんだろうが消費させてとっとと落とすのが吉。
- 533 ：
- >>529
知ってたならそんな本あまり意味がないこともわかると思うんだが...
- 534 ：
- >>530
書いてないものの場所を示せとかアホすぎる w
- 535 ：
- 結局HIPACE(日立システム開発方法論)なんてものは
日立以外では使われてないってことか
まあ名前のまんまだなｗ
- 536 ：
- >>534
ないことの証明は？
- 537 ：
- >>534
君も全く読まずにレスしてるねwww
- 538 ：
- >>536
読んでもらうしかない
これはグループ外の人には基本無理
でもあることを示すにはある場所を明示すればいいだけ
それをやれないと言うことは...
>>537
何度も同じこと書いて虚しくないの？
- 539 ：
- >>538
何度も同じこと書いて虚しくないの？
- 540 ：
- だから、開発プロセス全体を見る立場にない5次受け末端PGが
「W字モデルを使ってるところなんて見たことないもん！」
と駄々こねてるだけなんだから、みんな遠巻きにニヤニヤしながら眺めてればいいんだよ。
- 541 ：
- そうおもうならこそば、その5次受け末端PGに
使っているという証拠を突きつければいいだけなのでは？
- 542 ：
- >>533
意味がないとは？
- 543 ：
- >>533
あぁ、他人を罵る役に立たないって意味か
- 544 ：
- >>509
それのW字モデルの定義を見ると、後半の工程はテストの実施と修正を分離しただけだから、前半の工程で試験設計をするかどうかがV字モデルとの違いだな。
試験設計が実装完了を待つ必要がないのは自明だから、開発チームとは別にテストチームを持ててる所は、W字モデルと呼んでなくても、W字モデルに準拠するやり方でやってるんじゃないのかな？
- 545 ：
- 自明って言葉は、自分が説明できないことから
逃げるためのセリフだってじっちゃんが言ってた。
自明ってことを言うやつには、それが何故自明なのかを
説明されると、簡単に論破できるってばっちゃんも言ってた
- 546 ：
- >>542
現在の普及状況を知りたいのに9年前の情報もらってもねぇ
>>543
なんだよ単なる煽りかよ
- 547 ：
- >>544
> 開発チームとは別にテストチームを持ててる所は
そんなところあるのか？
運用テストとかシステムテストはQA部門がやるとしても単体テストや統合テストを別チームとか難しくね？
- 548 ：
- >>546
それはあなたにとって意味がないってことだよ
そもそもIPAのこの文言がどこまで信頼できるかも分からないし、だから、各自で判断しろと書いた
もっと最新の普及率について知りたいなら、それで利益を得るのはあなたなんだから自分で探しなよ
- 549 ：
- >>548
> 各自で判断しろと書いた
だから自分の判断を書いたわけなんだけど...
アホなの？
- 550 ：
- >>549
>>533
あなたに意味があるかどうかはあなた以外には分からないと思うのだが…
- 551 ：
- >>550
9年前の情報に意味があると言う主張？
- 552 ：
- アルゴリズムの本は30年前のものでも役に立った
テストテクニックは何年くらい通用するのだろうか
毎年画期的な発明や発見があるわけではないであろうし内容で判断するしかないんじゃ……
- 553 ：
- >>551
自分にとっては意味があるが、それを主張してるわけではない。しても仕方ないし
あなたに意味がないということは、事前に分からないというのが主張
つまり、>>533に対する反論
自分に意味がある資料は自分で探しておいで
- 554 ：
- 既に2012年の状況が示されてる（>>374）のにそれより古い情報をどや顔で出してくるとか
ちょっと頭の構造を疑うレベルだわな
- 555 ：
- 新しければいいってものじゃないだろ
ファッション感覚でテストやってんのか!?(ドヤ
- 556 ：
- >>554
それがあんたに役に立ったんならそれで良いじゃん
相手がドヤ顔に見えるのは、あんたの劣等感の問題だから他人には解決出来ないよ
- 557 ：
- うめ
- 558 ：
- >>556
> それがあんたに役に立ったんならそれで良いじゃん
役立たずの資料だしてそんなこと言われてもね
> 相手がドヤ顔に見えるのは、あんたの劣等感の問題だから他人には解決出来ないよ
はいはい w
- 559 ：
- >>558
末尾wも劣等感の表れ
- 560 ：
- IPAの文書を誰が書いたのかは知らないが、5SfAcpgV よりは信頼できそうだとは思うな。
- 561 ：
- >>558が今もっと役に立つ資料を探してきてくれるよ
- 562 ：
- >>560
そりゃそうだ
ここの匿名発言のどれよりも信頼できる
- 563 ：
- >>560
そりゃそうだ
別に信用できないと言う話じゃなくて情報が古いってだけの話だし
まあ>>561はそう言うことも理解できてないみたいだけど w
- 564 ：
- 最近はDevOpsでもWモデル的な考え方が取り入れられてきている。
どういうことかというと、上流の設計時点でデプロイ方法や監視方法までを視野に入れて、
それを上流の設計にフィードバックするというもの。
- 565 ：
- >>564
そもそもさ、実装（コーディング）のために
設計するって当たり前じゃね？
実装で使う道具によって、設計変わるんだしさ。
jQuery使うかReact使うかAngular使うかで設計違うし
下流のことを知らないSEが上流の設計をやってるっていうのが
大きな間違いだって、随分前から言われてる
- 566 ：
- >>564
最近あまりDevOps見てないけどそんな流れあったっけ？
- 567 ：
- >>565
> jQuery使うかReact使うかAngular使うかで設計違うし
それだいぶ下流だよ
- 568 ：
- >>567
あぁ、君、旧世代の人だねｗ
- 569 ：
- >>565
> そもそもさ、実装（コーディング）のために
> 設計するって当たり前じゃね？
>>564は、そういう話じゃないんだけど。
>>566
> 最近あまりDevOps見てないけどそんな流れあったっけ？
Wモデルでは、開発とQAが縦割りだったのを有機的に融合させるというスタイルで、
同じようなことが、DevOpsで開発と運用が縦割りだったのを融合させ、結果的に
デプロイ・運用を見込んだ上流設計（方式設計）がされることが多くなった。
- 570 ：
- 設計時点でテストの概念を導入しようなんてのは
モデルが出来ては忘れられ名前を変えて出て来ては忘れられしてきてるんだよ。
原因は便利そうだと飛び付いた上流とか言ってる奴らが理解できずに運用できなくて結局途中でやめるから。
きれいなサンプルコードに分岐網羅でいいからテストを書かしてみたいもんだ。
「ちゃんと動作することを目視する」とか書きそうな気がしてならない。
- 571 ：
- まあ、QAエンジニアと経験が数千時間、数万時間違うのに何いってんだってことですわ。
- 572 ：
- >>569
> 同じようなことが、DevOpsで開発と運用が縦割りだったのを融合させ、結果的に
> デプロイ・運用を見込んだ上流設計（方式設計）がされることが多くなった。
具体性の欠片もなくて笑うしかない
JaSST の連中が得意気に言いそうな内容だな
- 573 ：
- >>572
なるほど、君がいるあたりのド底辺の事情はJaSSTの人たちは知らないかもな。
でもそれはJaSSTのせいじゃないから。君自身の責任だから。がんばって。
- 574 ：
- >> 具体性の欠片もなくて
には触れないJaSSTかぶれ乙
- 575 ：
- 難癖付けるのは具体的でなくてもいい良いから楽だしな
- 576 ：
- 「具体性の欠片もなくて」と言う具体的な指摘をされてるのに何を言ってるんだ？
- 577 ：
- 具体性の定義がないし欠片の定義もないじゃないか
具体的どころかぐだぐだじゃないか
- 578 ：
- >>577
それが具体的だというなら、「開発と運用が縦割り」も「デプロイ・運用を見込んだ上流設計（方式設計）」も十分具体的だよな
2chに書けることなんてヒントぐらいでしかないのに、アレが無いコレが無いって文句ばかり言うだけで、もっと詳しい資料が提示されたら読みもしないで意味がないと言う
いつもそうだよ、構うだけ無駄
- 579 ：
- >>578
> 詳しい資料が提示されたら
提示してから言えばいいと思うよ
まあどうせ出てこないだろうけど
- 580 ：
- >>579
君は本当に馬鹿だね。がんばれ。
- 581 ：
- 馬鹿としか言えない哀れな人乙
- 582 ：
- 他人を馬鹿にする人は心のどこかで自分に対して不満や無価値感を持っている人である
- 583 ：
- 他人を馬鹿にする人を馬鹿にする人は心のどこかでナニ満をもってるの？
- 584 ：
- 他人を馬鹿にする人に対する不満じゃね？ 不満を言うことは馬鹿にすることじゃないよ
- 585 ：
- 要するに自分は正しい、他人は間違っているとゆうわけですね
馬鹿ですね〜
- 586 ：
- 自分だけは常に正しいという前提
- 587 ：
- 自分だけは常に正しいという他人の持つ前提は間違っているという前提
馬鹿ですね〜
- 588 ：
- >>587
どこにも間違ってるなどとは書いていません
ただその前提があるというだけ
- 589 ：
- まあ、間違ってると思うけどね
- 590 ：
- 正しいとは限らない、としか言わなければ常に正しい
- 591 ：
- >>590
その姿勢が正しくない
- 592 ：
- 他人だけは常に正しくないという前提
- 593 ：
- >>590
とは限らない
- 594 ：
- JSのMochaってすげえ簡単にテスト環境構築できるんだな、
ちょっと感動したわ。
- 595 ：
- >>594
ただ、そこにカバレッジとか付け足そうと
思ったら大変になるよｗ
なんかのフレームワークでそこら辺まで
ちゃんと整備されていればいいんだけどね
- 596 ：
- 人をバカにしないと自分の価値が維持できないという強迫観念
自分は人より何でもよく知っていないと価値がないんだという価値観
- 597 ：
- 自己紹介ですね
- 598 ：
- >>596は無意識で起こる根底の深層心理であって普通は意識されない
自分は違うと思っている人ほど掘り下げるとそうである
- 599 ：
- あー、いまなんかモヤモヤしているのが解決した気がする。
コードのテストは必要。だけどデータはテストは不要。ってこと。
もう少し詳しく言うと、コードを実行した結果の処理されたデータ（戻り値）はもちろんテストする。
そのことに対してコードのテストは必要と書いた。
だけど、例えば、クラスのデータとしてなんらかの定数を持たせて
その定数が定義どおりであること。なんてテストは不要
ある関数を引数を渡して呼び出した時、その引数が渡した物と一致するかのテストも不要
テスト済みのライブラリを使ってJSON形式の設定ファイルを読み込んで、
その設定値が正しく読み込まれているかのテストも不要
（ただし何かしらの処理で加工されている場合は、それに対してのテストは必要）
関数を通した時にデータが何の加工もされずに使われたり戻る場合はそのテストは不要ということ
そんなものにテストを書いたとしても、結局データが書いたとおりの値であることしか調べられないので
単にコードとテストコードの両方に同じ定義を二回書くだけでしかない
- 600 ：
- バグで加工されてるのが検出できないな
セッタゲッタをコピペして参照するメンバがそのままでバグとかよく見かける
仕様通りだったら問題ないからテストしないというのは賛成できない
品質落ちてもいいから工数削減のためにどのテストから削るかってならわかるけど
- 601 ：
- プロパティ使えよ
- 602 ：
- >>601
プロパティをラップできる言語とは限らないし
何かフックしてるからコピペなのかもだろ
お前のテストは抜けが多そうだな
ひとつの言語しか触ったことないというならまあしょうがない気もするが
- 603 ：
- >>602
かわいそうに
- 604 ：
- >>603
それしか言えないのかｗ
- 605 ：
- >>604
（そういうバグをよく見かけるような環境で）かわいそうに
って言わないとわかんないのかい？
- 606 ：
- 理由を書いても理解されないことが多々あるのに、
感情だけ書かれて理由を察しろって無理だから
- 607 ：
- >>605
感情でテストするのか
テスト経験が少ないのに
周りがかわいそうだな
- 608 ：
- >>607
テストとそれ以外の区別もつかないなんてあわれなやつ
- 609 ：
- >>608
テストの話じゃないならスレチなのでお帰りください
- 610 ：
- ここでスレチでない話題なんかほとんどねーよ。
- 611 ：
- テストとそれ以外の区別もつかないなんてあわれなやつ
- 612 ：
- どうやって区別するの？
- 613 ：
- 自分もわかってないんじゃない？
- 614 ：
- get と set をテストしなきゃならんとか
開発効率めちゃくちゃ悪そう。
こんなところにバグがあるならそもそも
もうすこしレイヤの高いメソッドでバグが出るもんだろうし、
そういうところでテストすべきだと思うよ。
- 615 ：
- コードの量が空行も入れて100行ぐらいしかないです。
簡単なツールで、関数すらありません。
処理の内容は、あるファイルを元にサーバーに対して
REST APIを呼ぶ程度です。
これをテストするとしたら、クラスや関数を作って
REST API部分はモックを使わなければ行けないと思うのですが
やる価値ありますか？
- 616 ：
- QUnit, Sinon, Jasmin とかだろ
- 617 ：
- >>615
テストすることで得られる情報量とコストを比べろ
- 618 ：
- >>617
テストすることで何が得られるんでしょうか？
100行程度なので実行コードを見れば
何をしているかなんて明らかななんですよ
テストコード書いたらおそらく100行以上になるので
実行コードを見るよりも時間が掛かるでしょう。
- 619 ：
- >>618
何がしたいのお前
- 620 ：
- >>618
何が得られるかはお前にしか分からない
テストしても新たな情報が得られないのが分かっているならテストしなくて良いよ
- 621 ：
- >>620
ですよね。これぐらいの短いコードに
テストコードがあったて意味が無いと思ってました
- 622 ：
- >>618
テスト対象は今後変更することは無い？
もし変更するのであれば、テストコードはリグレッションテスト用として価値があるかと。
- 623 ：
- >>622
変更するときは仕様を変えるときだろうな。
その時はテストも変えないといけないだろうね。
100行って意外と大したことないよ。
コマンドライン引数の処理部分で20行ぐらい使ってるし。
（当然ライブラリ使ってるのでここに条件分岐とかない）
- 624 ：
- 今ある機能はそのままで機能追加とかよくある事だと思うんだけど
- 625 ：
- シンプルに単機能にしてるからなぁ。
全く別の機能を追加するぐらいだったら
別のツールにするし。
出来る限り機能は削ぎたいぐらい
- 626 ：
- あと、テストを後から書こうとするから面倒くさいん
- 627 ：
- というかクラスにも関数にもなってないようなもの
というかそうするまでもないような短いコードに
どうやってテストを書けばいいのかわからん
テストを書くためにわざわざ関数やクラスにして
モック使って倍以上の量にして
それを読めって言う方が大変だろう
- 628 ：
- >>623
あぁ、テスト対象って特定の機能じゃなくてクラスとかモジュールとかもっと大きな単位で考えてたわ。言葉足らずだったか。
今までの機能はそのままで追加機能とか別の機能の変更とかそういう時のリグレッションテストに役立つかと。
- 629 ：
- テストはなくても簡単にサンプルが実行できるスクリプトとかは
書いておいた方がいいんじゃないの？
- 630 ：
- ライブラリ使ってるというならそのライブラリの挙動含めて意図通りになってるかテスト書いておいた方がいいと思うけどね。
俺の環境では動いたは仕事では通らないし。
環境含めて提供するなら別だが、単機能のツールにDockerとか持ち出されても困るだろ。
趣味なら好きにしたらいい
- 631 ：
- 100行程度のツールとかなら
・正常系
・ファイルがないとか読めない
・サーバーにアクセスできない
・...（ファイルの内容を色々）
程度のテストはする
よほど重要とか多数の人に配るとかでもない限りREST API のモックまではやらないな
- 632 ：
- こいつは単にテストする気がないだけだろ
- 633 ：
- いや、テストなら手動でやってるよ。
- 634 ：
- 良い例えを思いついたよ。
Dockerfileから呼び出す
エントリーポイントのシェルスクリプト
例えばこんなのな
https://github.com/docker-library/mysql/blob/e207dbbdfd5c95e4b51bdc2dae62c5f72a1dd908/8.0/docker-entrypoint.sh
これはループも条件分岐もある203行のコードだが
これに対するテストコード書くの？って話
- 635 ：
- >>634
だからお前はここで何がしたいの？
- 636 ：
- >>635
最初に書いてあるよね？
> やる価値ありますか？
- 637 ：
- >>636
誰にとっての価値を聞いてる？
- 638 ：
- そりゃテストコードを書く場合と一緒だろ
お前は誰のためにテスト書いてるんだよ？
- 639 ：
- >>634
俺なら書くよ。
逆に聞きたいけど、例えばその規模のコードを書くとき、全く動作確認もせずに0から全部書き切るの？
いや、動作確認はするよってことだったら、それはテストだよね。
- 640 ：
- >>639
テストコードは書かないよ
実際に動かしてテストすればいい
- 641 ：
- >>640
10行書く毎にテストするとして、最後の1回の動作確認は最後に書いた10行分の動作確認をするの？
それとも、今まで確認したこと全てやりなおすの？
前者だとしたら、今までOKだったものが動作しなくなっている場合に検知できないし、後者なら
動作確認に時間がかかりすぎる。
だから、俺たちはテストコードを書くんだ。
- 642 ：
- > それとも、今まで確認したこと全てやりなおすの？
単機能なんで、今まで確認したことの全て＝一つと言ってもいいぐらいなんだよｗ
- 643 ：
- もちろん全く一つではないけどね。
オプションで-vをつけると詳細なログがでる。
というテストを書く？
オプションで--debugとつけると
デバッグログが出力される
というテストを書く？
--versionと書くとVERSION変数の中身を表示するだけ
というテストを書く？
- 644 ：
- >>642
> 単機能なんで、今まで確認したことの全て＝一つと言ってもいいぐらいなんだよｗ
いやいや、例えば>>634のコードなら、というのが前提の話だよ。
> というテストを書く？
書かないよ。
まぁざっくり言えばC0カバレッジで考えたときに、明らかに意味のないもの以外のテストを書くだろうね。
仮に_check_config(), _get_config()なんかがリファクタリング（重複コードのメソッド抽出）の
結果だとするなら、何度もテストできるテストコードがあってよかった、ってことになると思う。
- 645 ：
- >>636
もうお前の中で結論出てるんだろ
- 646 ：
- 夏休みも終わりだな
- 647 ：
- まあ短いコードでもネットワークアクセスやデータベースアクセスみたいに
副作用の強いものとつながってるんなら、
そういう部分をスタブで置き換えてテストできるくらいには
整えておくのもいいんじゃないかね。
- 648 ：
- テストするかどうかも決まってないのに
方法に来てどうするんだ
- 649 ：
- 各々の中で決まってるだろ。
- 650 ：
- 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
UZFWS
- 651 ：
- KWG
- 652 ：
- >>646
バカヤロウ、まだ始まってもいねぇよ！
- 653 ：2020/06/14
- イチカラツクリナオセ
ECMAScript デス 4
【Delphi】Embarcaderoオッチャ その31【C++ﾋﾞﾙﾀﾞ】
オブジェクト指向は愚かな考え。この世は計算式 ★3
.Net Core / Net ASP Core
Windows 10 UWPアプリ開発 Part 2
おまいらのプログラムの勉強の仕方を教えろください
Vue vs React vs Angular Part.3
Rust part8
【Win/Mac/Linux/Android/iOS】 Qt 総合スレ 18
【Delphi互換!?】FreePascal/Lazarus その2【GPL】
--------------------
包食速報 雑談スレ 322食目
【島根県・竹島】韓国政府が声明 「竹島の日」式典開催に抗議「不当な主張を直ちにやめ、謙虚な姿勢で歴史を直視すべき」[2/22]
【モンスト】モンスターストライク 脱超初心者スレ286【脱超】
宇部豚ニートがハロインのおかしもらえなかったから相撲板で暴れてるって
☆G-FORUM★２
雨宮天 Part56
【TRY】トルコリラ Part425【というわけで週末】
航空法「200g以上のドローンは規制！」DJI「199gの日本仕様ドローン作りました！」 [193136539]
渋谷AVALON
【百合】♀×♀なところのあるｹﾞｰﾑを語る46【レズ】
【アズレン】アズールレーン Part 3307
iPhone11/iPhone11Pro/iPhone11Pro Max予約総合スレ★4
【FSX】Microsoft Flight Simurator X vol.27
【バーチャルYoutuber】にじさんじ有ンチスレ10794【力一10万人いったりきたりゲーム応援スレ】
【サッカー】＜ジェフユナイテッド千葉＞新ユニ発表！「秋田犬」の斬新デザイン...2ndユニはパープルに...
テレワーク、在宅勤務中のリーマン Part.2
か→め→は→め→波を完成させるスレ part29
【FEH】ファイアーエムブレムヒーローズpart5190
咳が止まらないJKとお話しようや
コントラクトブリッジ
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
