unit-testing - TClでプライベートメソッドをどのようにテストしますか

Question

この質問がばかげているように思われる場合は非常に申し訳ありません。私はTCLとTCLtestの初心者です。いくつかのTCLOOプログラムで単体テストを実行しようとしていますが、プライベートメソッド（キーワード「my」を使用して呼び出されるメソッド）のテストに問題があります。 ）。ガイダンスが必要

Answer 1

プライベートメソッドをテストする必要があるかどうかという質問は別として、次のいずれかのスキームでメソッドを取得できます。

• これを呼び出すために使用[info object namespace $inst]::my $methodnameします。これは、イントロスペクションを使用しての実際の名前を見つけることができるという事実を利用しています（これは、確実に機能します。 、、、およびTkなどのコマンドmyを使用してコールバックを実行する場合に必要です）。vwaittracebind
• 特定のインスタンスに対してoo::objdefine $inst export $methodnameメソッドをパブリックにするために使用します。その時点で、通常どおりに実行できます。$inst $methodname

結果：厳重に保護する必要があるものには、TclOOオブジェクトのプライベートメソッドを使用しないでください（たとえば、Javaオブジェクトのプライベートフィールドとは対照的です）。このような情報のシュラウドを処理するための正しいレベルは、マスターインタープリターに配置するか（信頼できないコードを安全なスレーブで評価する）、保護された情報を基盤となる実装（C）レベルに維持することです。これら2つの最適なオプションは、プログラムの詳細によって異なります。通常、どちらが正しい選択であるかはかなり明白です（それ以外の場合は、Tclコードを記述しているだけの場合は、このためだけにCを記述しないでください）。

Answer 2

これはOTのように見えるかもしれませんが、我慢してください。

プライベートメソッドをテストする必要がありますか？それは実装をテストするように聞こえます、そしてそれはあなたがすべきではないことです。クラスの動作をテストする必要があり、それはパブリックメソッドを介してテストされます。

プライベートメソッドの1つに複雑なコードのチャンクがあり、それを徹底的にテストする必要があると思われる場合は、コードを2つの別々のクラスにリファクタリングすることを検討してください。テストが必要なメソッドを2つのクラスのいずれかで公開します。

そうすれば、すべてを実行する「神のクラス」を持つことを避け、テストしたいものをテストすることができます。単一責任の原則についてもっと読みたいと思うかもしれません。

リファクタリングに関する特定の本のタイトルが必要な場合は、RobertC.Martinによる「CleanCode」をお勧めします。私はその本が大好きです！