トレイウィンドウのメッセージ配送をテストする#2533
Conversation
テストスイート単位でインスタンス生成するように変える。 メンバーアクセスがテストを書くのに都合が悪いので、一時的に変える。
TrayWndもウィンドウなので、メッセージ配送が主な役割。 現時点では「おかしなメッセージ」に耐性がなくてテスト不能なものが結構ある。
|
MinGWビルドの失敗について。
あと何回かリトライしてダメなようなら、「トレイクリックをエミュレートする」を最小限に抑える変更を含めてしまうことも考えようかと思ってる。 1本のPull Requestに複数の意図が入り込むと、どれだけアプリに対する理解が深くても「これなんだっけ?」になりがち。 無理な場合を除いて、できるだけソレは避けたい。 |
|
ぼくがサクラエディタに関わっている目的には、「先端技術のキャッチアップを怠らないよう、勉強の機会を得る」ということが含まれている。 GitHub Actionsで発生したエラーを GitHub Copilot(≒AIアシスタント) に見て貰っている。 スパッと直せたら Copilot すげぇぇぇ! になるよね。 ならんとは思うけど。 |
|
ん? ExpandParameter_mixed の失敗が2回続けて再現しただと・・・? |
|
OK。Copilot君正しい。 > #2534 Copilot すげぇぇぇ! になった。 ただ、このまま入れるのは違う気がする。 |
|
さて。どうしたものか。 選択肢
最善は1つ目。 |
|
テスト実行が完了しない不具合発生。(クリティカル。) |
|
テストが完了しなかった理由は、以下。 トレイクリックメニューからGrepダイアログを表示し、OKボタンを押す 仕方ないので、障害になってる部分を直す最低限の修正を入れてリトライ中。 |
|
|
CFileNameManager以外の TSingleton も移行しておいたほうが良さげ。 |
|
トレイウィンドウのテストとしてはまだ問題が残っているけれど、メッセージ配送のテストはできているのでマージしてしまう。 |



PR対象
カテゴリ
PR の背景
背景にあるのは「カバレッジ低過ぎ問題(#2526)」です。
仕様・動作説明
ウィンドウクラスはメッセージハンドラをメンバーに持つため、本質的にテストしづらいです。
※メッセージハンドラはWindows APIの生構造体が引数となるため。
しかし、クラスの役割 ≒ メッセージ配送 と置けば、
メッセージ配送が正しく行われるか と
配送されたメッセージが正しく(?)処理されるか に評価観点を分離できます。
サクラエディタの場合、メッセージ配送が正しく行われることを保証できないコードが結構あったりするわけですが、これまでは「たたき台」にできる評価コードすら一本もない状態でした。
本件、勝手にやります。
PR の影響範囲
テスト内容
関連 issue, PR
参考資料