berryzplus

it seems to be no target modules defined. ``` run cmd as :%time% "C:\Program Files\OpenCppCoverage\OpenCppCoverage.exe" --sources "D:\Lib\src" --excluded_sources "D:\Lib\ut" -- "D:\Lib\build\Debug\UnitTest.exe" %time% ``` 1. execute test module. 2. some module...

> I think @pingqi identified that slowness comes from report generation, not the execution itself. HtmlExporter takes 15min to generate coverage results... is it right?

このissueのステータスは `ツッコミ待ち` です。 `スモークテストとは何か` を説明できてる気がしないので進行を保留しとります。

何らかのリアクションをお願いします。 以下のいずれかだと反応しやすいです。 - 説明自体は理解できた。（何か文句がある。） - 何言ってるか理解できない。

む。 「説明は完了した」と見做してよさそう・・・。

> マクロを使ってサクラエディタの機能をいろいろ動かしてみるテストはやらないのだろうかと考えています。UI以外のテストならマクロを使えばいろいろ出来るだろうと思います。 やるっす。 具体的方法の説明をしていなかったですが、実現方法としてはスクリプトのホスト機能を最大限に活用することを考えています。方法的にUIテストは不可能です。

> 最初はこんな感じのテストでもいいと思うんですよね。 #1363 の第三段階テストも当初、開いた瞬間マクロで閉じるの形式にしていました。 最初に導入するテストはごく簡単なもので構わないと思ってます。 できれば、外部コマンドの実行でなく単体テストに組み込んでしまいたいと思っています。 最大の理由は、単体テストのカバレッジが異常に低いのを補いたいからです。 現状のカバレッジは `2%` くらいです。 エディタを起動をケースとして実行すると全体の `15%` くらいを実行できます。 そのノリで作られたテストケースの効果については激しく疑問が残りますが、カバー率10%未満と10%超の差は心理的に大きいような気がします。 > これをやるだけなら sakura.exe 本体の修正は不要だと思っているのですが、ここで言っているスモークテストはどういう形でやろうとしているのかがまだよく分かっていません。 スモークテストなので全機能を「動かす」が目標です。 サクラエディタにはGUI前提の機能（ファイルを開くダイアログとか）が結構あるので、sakura本体の修正なしには実現は不可能と思います。もっとも、sakura本体の修正を行わずにかなりのところまでイケるのは確かなので、初期のスモークテストはできるだけ本体を修正せずに実現したいと考えています。 #1363 の後半で色々いじってみたのは当初構想ではないです :smiley:

> 初期のスモークテストはできるだけ本体を修正せずに実現したいと考えています。 単体テストに組み込もうとした場合 `本体を修正せずに` は無理そうです。 採れる手段は、３つです。 1. 最低限の修正を行って単体テストに組み込む 1. 単体テストに組み込まない 1. スモークテストを導入しない 判断を行うにあたり `最低限ってなんぼやねん！` の情報が必須と思うので #1363 で明らかにしていきたいと思います。

> 単体テストに組み込もうとしている理由は何でしょうか。カバレッジ測定？ 測定することは目的じゃないんですが・・・そうです。 2桁を超えるカバレッジの提示により得られる「安心感」が目的です。 > 単体テストではないものを単体テストに組み込もうとすると、いろいろ無理が出るんじゃないかという気がしますが。 プログラム設計のやり方には、単体テストできる設計とそうでない設計があると思います。 サクラエディタは後者です。 単体テストできない設計のコードをテストするには、いろいろと工夫をする必要があります。この工夫を「無理をする」と表現してしまえば、確かにその通りだと思います。無理ではない工夫だと思ったのでやってみよう、の提案をしてみているわけですが（といいつつ、まだ具体的な中身の説明はできていませんけれど・・・。） > gcc だと `--coverage` オプションを付けてビルドしたバイナリを実行すれば、それだけでカバレッジが取得できて、あとは codecov や coveralls にデータを投げれば Web 上から結果が見れて便利ですね。(MinGW で試したことはないのですが。) この辺の知見が欲しいんですよねｗ 現状のカバレッジが `2%` である事実はこれまであまり書いてこなかったのですが、あまりにも数値が低すぎるとカバレッジを公開しようっていうモチベーションが得られないっていうですね・・・。

> Vim では何年も掛けて整備してきたのでそれなりに説明は出来ます。(あくまでLinuxでの話ですが) サクラエディタだと、かなり頑張って5割くらいが限界かな？と思っています。 5割を超えた先は「使ってないコードを削る」の作業になる予想で、 7割を超えられたら `文句あるか！` と豪語していいんじゃないかと思います・・・。 > 逆にVisual Studioではどうやってカバレッジを測定するのか把握していませんが…。 2% とか 15% とかいうのはvisual studioで測定した値です。 visual studioにはカバレッジ測定機能を使えるエディションがありまして、それで出してます。 azure pipelinesの標準agentにインストールされてるvisual studioならこの機能が使えるので、 折を見てテスト結果のカバレッジを公開する作業をしたいと思っています。 MSVC版のカバレッジツールの候補として次点は OpenCppCoverage かな？と思っています https://github.com/OpenCppCoverage/OpenCppCoverage