TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
次世代言語15 Go Rust Bosque Kotlin TypeScript
Visual Studio IDE環境
今までに見たソースコードで一番感動したのは deux
【関数】Erlang Part 2【エリクソン】
Visual Studio 2019 Part4
GPGPU#5
DarkBASIC
「コンパイラ・スクリプトエンジン」相談室16
【Lua】組み込み系言語総合 その7【Squirrel】
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
テストしにくいコードをテストする方法 その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 ：
- 出題しろよ
100〜のスレッドの続きを読む
くだすれPython(超初心者用) その45【Ruby禁止】
UNIXプログラミング質問すれ Part10
COBOL？極めてやんよ シュッシュ!!
【安定版】ActiveBasicその12【4.24】
Visual Studio 2019 Part3
C言語相談室(上級者専用）
テスト
Rust part8
【PHP】下らねぇ質問はここに書き込みやがれ 2
人工知能を作ろうver0.0.7
--------------------
【BSプレミアム】主婦カツ！part1【鈴木保奈美・島崎遥香・岡田義徳・高橋ひとみ】
こんな祥子さまは嫌だ！その36
「子ども」と「税金」
Sony BRAVIA ブラビア Part261
安倍、政府主導で中韓に頼らない5G半導体メーカー「日本版ﾌｧｰｳｪｲ」設立へ。予算はたったの1000億円w
まだマンション買っちゃだめ！あと２年で半額に 178
花組スレ Part200
100kg以上の超デブが悩みや愚痴を語るスレ9
なぜ、新潟市には美人が多いのか？
邦人作曲家総合スレッド Part7
【日露】極東カムチャツカ半島にＬＮＧ中継基地 日ロ協力、エネルギー調達を多角化 北極圏航路活用
【イラン】国連安保理に「戦争は求めていない」
【ｶﾈ金ｶﾈ】どこのｽﾋﾟﾘﾁｭｱﾙ屋も金目当てばっかで変だと思う人の数→
スレをたてるまでのない質問＠水泳板11
矢沢永吉を聴かない奴は総じてクズ
【Meet】林原めぐみpart1【again】
Qが滅茶苦茶に面白かった件について30
♪宇多田ヒカル統一スレ・パート433♪ 【修正】
◆◆ 自宅練習に最適なアンプ93Ω ◆◆
椎名慶治 井坂仁美 愛のトラブル駆け込み寺vol.2
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼