  |
はてなキーワード: バックドアとは
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えば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)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
独自OSまではいかなくても、ハッカーを国家公務員として高給で雇いLinuxをしらみつぶしに解読する
独自のOSを作らなければならないのは、例えばアビオニクスなどのためでもある
ロシアからスホーイの最新機は売ってもらうとしても、ロシア側はアビオニクス、電子機器やセンサー、コンピュータ、そのソフトウェアOSなどを抜きにして売ってくる
ラジコン飛行機とかで、機体だけは売るけどあとは自分でどうにかしてね、みたいな感じである
そうすると寄せ集めだろうがコピーだろうが、その最新スホーイを飛ばすために意図的に空白にされた箇所を埋めなければならない
ワリャーグもそうだったが、多くが欠損した巨大なパズルがあったとして、その欠損個所を埋めるというのは、自分には意外と創造性さえある仕事に思える
欠損個所の周辺から自ずと仕様は決定するが、その中に正解はない
インターフェース、APIの仕様はあるが、中は独自実装するしかないからだ
だから、そこはコピーだろうだが何だろうが埋めて、戦闘機や戦艦を動かすしかない
で、彼らはそれをやってのけたわけだ
航行できる状態になったワリャーグから黄色く塗装されたスホーイをタッチアンドゴーさせた
世界にあの実証実験を見せたのは、自分たちはここまでできるようになった、と見せつける意味がある
アメリカが人工知能でステルス爆撃機をタッチアンドゴーさせたのも同様だ
あれは本当にできるだけ人が介入しない、つまり巨大なラジコン飛行機ではなく、人のように自律した爆撃機が自ら離発着できることを意味する
まあ、コストの問題から後継機はうまくいってないらしいが、金はともかく技術はあるということだ
もちろん、なんらかの中国国民を監視するためのバックドアが仕込まれるのかもしれない
しかし、中国それから台湾なんかも独自CPUに乗り出す時代、特に台湾はマザーボードなどの薄利な仕事から抜け出すチャンスでもある
もっとも、それがARMやAMD、Appleと対抗できるかは未知数だし分からん
ただ、ニッチな分野で生きれば御の字だろう
プログラミング言語Adaだって、比較的最近まで軍事兵器業界では生きていたみたいだ
当然ではあるが、今はCやC++に置き換えられている
ここまで書いて思うのは、やはり軍があるかどうかではないだろうか
疾病対策センターだって、仮想敵国からのバイオ兵器、化学兵器への対策を含んでいる
原発事故があってもアメリカがパックボットをすぐに導入できるのは、ルンバも開発しているiRobotが軍事ロボットのメーカーだからである
大学の研究所で作ったロボットと同じ機能だったとしても、アメリカ側は実戦経験のあるロボットなわけだ
左の人は軍需産業＝悪と考えがちだが、軍需産業は敵の兵士に被害を出させることだけが目的ではない、
味方の命を守ること、味方の負傷兵を救うことも同様に軍需産業のカテゴリーに含まれるものであり、
これはレスキュー活動などと十分に被るし、既存のレスキュー活動をより効率的に、よりパワフルにする可能性を秘めている
頭ごなしに～はいけない、と人は考えがちである、自分もそうであろう
しかし、一旦その固定概念を捨ててみて、目の前の問題に対してどうするべきか考えることも重要なのではないだろうか
https://www3.nhk.or.jp/news/html/20191218/k10012219801000.html
はてブの※でこの手のニュースの度に「未来の人材だ！」みたいに言う馬鹿は何なの？家のルーターの管理IDとPASSは初期のままなのかな？
遠隔操作アプリがその通りかもしれないが、この場合先生も使用していた専用アプリを中学生もスマホにでも入れて、盗んだIDとPASSでログインしただけだと思う。なんか凄いか？
令和の時代になっても世間のハッカーのイメージは謎のコマンド画面にプログラム打ち込むイメージか、凄いプログラムでPASSが解読されるイメージだろうが、平成初期から実際は泥臭いのがハッキングだった。ソーシャル・エンジニアリングが大半で、あとはウィルス・スパイウェア・自力等でのバックドアを仕込むパターン。変な話、職場でディスプレイに貼ってあるIDとPASS覚えたらあなたもハッカーだ（実際のハッカーの意味とは違うが、世間的なイメージのハッカーの意味で）
行動力を考えたら有望かもしれないが、やってることは大したこと無い。最近はなんでもネットにやり方あるので、正直コピペだけの可能性もあるし、脊髄反射で褒め称えるのはどうかと思うわ
