  |
はてなキーワード: ホワイトボックステストとは
計算やロジックが複雑かつ特定のオブジェクトに密に関わっている場合、元記事に引かれている例でいえば麻雀の点数計算のようなものとかあるいは準数値演算や組み合わせアルゴリズムが関わってくるようなメソッドだと、振る舞いを見るブラックボックステストではなく、ロジックを調べるホワイトボックステストが必要になる。
そういう場合、たとえ別モジュールに切り出してもテストしたい部分の複雑さは変わらず、やっぱりプライベートの部分をテストしたいということになる。
別モジュールに分ければプライベートメソッドをテストする必要はないはずだという想定は、プライベートメソッドをテストができない言語やテストライブラリの欠陥に対する言い逃れじゃない？
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)
private メソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、private メソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の public メソッドの重複部分を private メソッドに抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)
きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)
しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。
伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)
単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)
private メソッドをテストするかどうか？ まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)
特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1
テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)
private メソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)
RustやGoではプライベートメソッドに対するテストが簡単にできる。
そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。
Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)
Rustではプライベートに対して何の手間もなくテストが書ける。
Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
コンサルにてアナリストをやった後、データサイエンティストを名乗りながら仕事をしています。そんな中で嫌だったなと思った人たちとプロジェクト
最近はアウトカムでの評価の流れにはなってきたが、まだまだモデルの評価をする事は少ない。
でも何故か相変わらずロジステックとCox回帰をやれればおっけーであり、モデルの精度が当たらなくてもオッズ比と説明変数の
有意差だけでていれば上手く行く分野。 本当に心が痛む上、まだまだ「医者でなければ人であらず」が通ってしまい、モデルの説明よりもお医者様のお言葉が1stにきてしまう。また分析プロジェクトの
設計らしい設計があまり出来ないのもつらいところ（モデルの精度が出ていないのにそのオッズ比・有意差に何の意味があるんだと思う）。後日本の製薬企業から「何とか工夫で有意差がでないのか！！」
という謎おしかりを受ける・・・いやそんなん無理ですやんと切実に思う。やる気でこの世界の数字は変わりません。
割と良いBIみたいなんが良くも悪くもあるためアナリストの人たちがやった気になっているやつ。Web関係のアナリストは、アナリストを名乗って欲しくない人の方が多いイメージ（勿論しっかりWebアナリストやっている方々は知っている）。広告内容を分類し、CVを予測、そしてマルチチャネルの予算からのCVを最適化案件をしていたらWebアナリスト様から「私の作るLPは最適です。なので予算４０００万です」という謎の最適の主張を受けたのはいい思い出（何故かデザイナー様がWebアナリストもやっていた）。広告内容のuser2vecでのレコメンド実装にチャレンジして評価して、協調フィルタリングよりも精度はよさげだな喜んでいたら、どっかのよくわからないレコメンドツールというのが汎用性もあるし、既存のツールに１万ぐらい払えば追加できるとそして何故か「最適化」されているという言葉に役員が騙されて決済がおりていたのを聞いたときは殺意が沸いた。どうせ既存のマーケティングオートメーションのレコメンドエンジンなんて協調フィルタリング・ロジぐらいだろうと思っている。本気で分析やっている人がそうそう最適化なんて言葉を使わないと思うんだ・・・。まぁここの反省はWeb業界といってもみんなコーディングがりがりではなくてGUIでいいならそれでが割と多いという事を学んだ （注意）。
３．データベース関連
どっかの人のにもあったが、「あっ、データ分析分かるんだよね？」という事でVB6とAccessの改修をやらされそうになったときは全力で拒否った。
４．やる気を説いて来る人達
やる気で数字が変わったら誰も苦労なんてしないんだよ・・・。半教師有り等で精度向上見込めるといってもいくらなんでもこのデータでは
５．ホワイトボックステストを要求されたとき
モデルのホワイトボックステストってどうやってやるんだ？精度を検証用データでやっていれば良いじゃないかと思っていた。ただそこの金融系でITプロジェクトは、基本的に「ホワイトボックステスト」やらが必須らしく・・・おいおい・・。とりあえずカテゴリーの目的変数がそれぞれの値を取ることを客先で見せてかつレポートで「こうこうこうゆうときにカテゴリー変数が変わりますよ」という彼らがいう境界線の確認を全てやることになった。カバレッジ１００％も言われたが、流石に無さ過ぎるので諦めてもらった。
６．KGIとKPIしっかり切り分けてBI作成していたら集計屋かといって来られる時
どこかの人にもあったが、私はビジネスが動けばよいと思っているので難しい分析をしなくても上手く行く時は、集計で上手く切り分けて、要因分析をやる（裏で決定木とかで境界値とかは見ていたりする）。ただ何故かそれで集計ばかりしかしていないと怒られる。別に研究者ではないし、難しい分析をしてクライアントへの説明に時間を取られたり、展開が難しくなるぐらいならば皆と合意した上で、KPIとKGIを切り分けてダッシュボード作成をしっかり出来る方が実はビジネス上上手く行くだ。むしろ自分への戒めでいつも難しい分析が本当に必要なのかと思ってるぐらいである。
注意 因みに私の別部署でインフラ基盤周りのWordpress関係が炎上していた。そこそこの大規模でWordpress使うって大変らしいのに・・・。
汎用系のエンジニアからRubyのエンジニアとして転職して1年。
コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。
その特徴はだいたいこの3つだ。
やれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。
そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。
テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。
ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。
そもそも自分が行おうとしているソートが何ソートなのか知っているのか？計算回数を考慮した上での実装か？
便利なメソッドがたくさんあるのは知っている。
ただ、中身くらいは知っておこうよ。
新人に教えたらバカにされたけど、まずフローチャート書くようにしようぜ。
「Githubで公開されてましたんで導入しました」じゃねーよ。
得体の知れないコードをたくさん詰め込んだプログラムをよく動かせるな。
そんで都合の悪いところだけコードを読んでオーバーライドする。
影響範囲を全く調査せず、Gem絶対神話を唱える。あれなんなの？
いや、Rubyが便利なのは認めるよ。俺だってPLIとかCOBOLより書いてて楽しいよ。
エンジニアもどき量産言語だね。どれか１つでも当てはまった奴は小学校からやり直せ。
追記
意見がたくさんもらえて喜ばしい。
文化の違いという意見もあったが、「よくわからないけどなんかうまくいく」コードだとデバッグも大変だし不具合も起きやすい。
「だいたい」とあるだろう。全てのだいたいだ。
＞フローチャート糞
精神論に聞こえるかもしれないが、フローチャート書いて育ったエンジニアは頭の中でロジックの組み立てと凡その演算回数が計算できるようになるよ。
＞カバレージが100%だったとしても実際の打鍵結果でエラーは弾ける
あー、ここは誤タイピングだわ。
自動テストでカバレージ100%です、そして画面数回触ってリリースしますーっていう奴が多いってこった。
単体だけじゃなく画面使ったテストもケース表書いて網羅性を担保しないとダメだろ。
