sakura
sakura copied to clipboard
sakura-editor
スモークテストを導入したい
スモークテストって何だ？
-
スモークの名前が示す通りもやっとしたテストです。 - アプリに備わった色んな機能をざっくりと動かします。
-
なんとなく今まで通りを検証することを目的とします。
単体テストと何が違うの？
- 単体テストは
内部仕様の妥当性を検証するガラス張りテストです。 - スモークテストは
操作と処理結果の妥当性を検証するブラックボックステストです。
スモークテストを導入すると何が嬉しいの？
-
なんとなく今まで通りを検証できるようになります。
スモークテストのダメな点は？
- 動かした機能についてしか検証できません。
-
なんとなく今まで通りの範囲に何を含めるかできっとモメます。 - 実装の詳細のクソくだらないことで絶対モメます。
タスクリスト
- [x] スモークテストとは何かを説明する。
- [ ] サクラエディタでの実現方法を説明する。
- [ ] 前提で必要な機能の単体テストを導入する。
- [ ] 超簡易版シナリオでスモークテストを導入する。
- [ ]
なんとなく今まで通りの内容を固めて暫定シナリオを作る。 - [ ] 暫定シナリオでスモークテストを導入する。
道は長い・・・。
何らかのリアクションをお願いします。
以下のいずれかだと反応しやすいです。
- 説明自体は理解できた。（何か文句がある。）
- 何言ってるか理解できない。
いわゆる「回帰テスト」ってことですかね。
いわゆるJTest的なことをインタフェース（UI、コマンドライン）に対して総当り的に行うのが理想なのかもしれないけど、クリック位置とか、再描画後の画面が正しく描画されているかとか、 UIに対して導入するのは難しいのかなと。
であるならば、各ファンクション（出来たら全ファンクション）のカバレージが１００％になるように、テストパターンを描いてそれを実行する（一部今やってる？）、修正のあるファンクションはテストパターンを書き換える。
んなかんじ？
でもマルチタスク、マルチスレッドとか、結構条件再現させるの難しいのもあるよねー。 この辺もうなんか決まったフレームワークとかあるのかしら。
JavaScriptとかは簡易テストフレームワーク作ったりしたけど、 自前はもうやりたくないよねぇ、今どき・・・
https://github.com/microsoft/WinAppDriver
このへんかな、日本語入力とか弱いみたいだけど・・・ あとAzure PipelinesとかAppVeyorで動くのかって問題も（あ、ローカルでテストでもいいけど）
マクロを使ってサクラエディタの機能をいろいろ動かしてみるテストはやらないのだろうかと考えています。UI以外のテストならマクロを使えばいろいろ出来るだろうと思います。
マクロを使ってサクラエディタの機能をいろいろ動かしてみるテストはやらないのだろうかと考えています。UI以外のテストならマクロを使えばいろいろ出来るだろうと思います。
やるっす。
具体的方法の説明をしていなかったですが、実現方法としてはスクリプトのホスト機能を最大限に活用することを考えています。方法的にUIテストは不可能です。
👍
最初はこんな感じのテストでもいいと思うんですよね。
start /wait sakura.exe "-M=InsText('a');FileSaveAs('x.txt');ExitAllEditors()" -MTYPE=js
a とだけ書いたファイルを x.txt として保存して終了するだけのマクロですが、これを実行して、期待値として用意しておいたファイルと fc コマンドや diff コマンドと比較して、差分がなければ OK と。
結果の判定に外部コマンドを使いたくなければ、マクロでいろいろ判定するようにしてもいいでしょう。
これをやるだけなら sakura.exe 本体の修正は不要だと思っているのですが、ここで言っているスモークテストはどういう形でやろうとしているのかがまだよく分かっていません。
最初はこんな感じのテストでもいいと思うんですよね。
#1363 の第三段階テストも当初、開いた瞬間マクロで閉じるの形式にしていました。 最初に導入するテストはごく簡単なもので構わないと思ってます。
できれば、外部コマンドの実行でなく単体テストに組み込んでしまいたいと思っています。
最大の理由は、単体テストのカバレッジが異常に低いのを補いたいからです。
現状のカバレッジは 2% くらいです。
エディタを起動をケースとして実行すると全体の 15% くらいを実行できます。
そのノリで作られたテストケースの効果については激しく疑問が残りますが、カバー率10%未満と10%超の差は心理的に大きいような気がします。
これをやるだけなら sakura.exe 本体の修正は不要だと思っているのですが、ここで言っているスモークテストはどういう形でやろうとしているのかがまだよく分かっていません。
スモークテストなので全機能を「動かす」が目標です。
サクラエディタにはGUI前提の機能（ファイルを開くダイアログとか）が結構あるので、sakura本体の修正なしには実現は不可能と思います。もっとも、sakura本体の修正を行わずにかなりのところまでイケるのは確かなので、初期のスモークテストはできるだけ本体を修正せずに実現したいと考えています。 #1363 の後半で色々いじってみたのは当初構想ではないです :smiley:
初期のスモークテストはできるだけ本体を修正せずに実現したいと考えています。
単体テストに組み込もうとした場合 本体を修正せずに は無理そうです。
採れる手段は、３つです。
- 最低限の修正を行って単体テストに組み込む
- 単体テストに組み込まない
- スモークテストを導入しない
判断を行うにあたり 最低限ってなんぼやねん！ の情報が必須と思うので #1363 で明らかにしていきたいと思います。
単体テストに組み込もうとしている理由は何でしょうか。カバレッジ測定？ 単体テストではないものを単体テストに組み込もうとすると、いろいろ無理が出るんじゃないかという気がしますが。
gcc だと --coverage オプションを付けてビルドしたバイナリを実行すれば、それだけでカバレッジが取得できて、あとは codecov や coveralls にデータを投げれば Web 上から結果が見れて便利ですね。(MinGW で試したことはないのですが。)
単体テストに組み込もうとしている理由は何でしょうか。カバレッジ測定？
測定することは目的じゃないんですが・・・そうです。
2桁を超えるカバレッジの提示により得られる「安心感」が目的です。
単体テストではないものを単体テストに組み込もうとすると、いろいろ無理が出るんじゃないかという気がしますが。
プログラム設計のやり方には、単体テストできる設計とそうでない設計があると思います。
サクラエディタは後者です。
単体テストできない設計のコードをテストするには、いろいろと工夫をする必要があります。この工夫を「無理をする」と表現してしまえば、確かにその通りだと思います。無理ではない工夫だと思ったのでやってみよう、の提案をしてみているわけですが（といいつつ、まだ具体的な中身の説明はできていませんけれど・・・。）
gcc だと
--coverageオプションを付けてビルドしたバイナリを実行すれば、それだけでカバレッジが取得できて、あとは codecov や coveralls にデータを投げれば Web 上から結果が見れて便利ですね。(MinGW で試したことはないのですが。)
この辺の知見が欲しいんですよねｗ
現状のカバレッジが 2% である事実はこれまであまり書いてこなかったのですが、あまりにも数値が低すぎるとカバレッジを公開しようっていうモチベーションが得られないっていうですね・・・。
この辺の知見が欲しいんですよねｗ
Vim では何年も掛けて整備してきたのでそれなりに説明は出来ます。(あくまでLinuxでの話ですが) codecov はこんな感じです。 https://codecov.io/gh/vim/vim?branch=master
逆にVisual Studioではどうやってカバレッジを測定するのか把握していませんが…。
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
MinGW + codecov を試してみました。
https://github.com/k-takata/sakura/commit/60b9b0434b6957d69198b663ac00375a24cc90fb
これで、GHA 上で、--coverage オプションを使って sakura.exe をビルドし、実行してカバレッジを取得し、codecov に結果をアップロードすることが出来ます。
結果はこんな感じで見ることが出来ます。 https://codecov.io/gh/k-takata/sakura/branch/feature%2Fmingw-coverage
ローカルで MinGW を使ってカバレッジを調べるには gcovr というツールを使うのが良さそうです。
インストール:
pacboy -S python-lxml:m
pacboy -S python-pip:m
pip install gcovr
pip install は MSYSTEM=MINGW64 または MINGW32 のどちらか必要な環境、あるいは両方で実行する必要があります。
ビルド:
cd sakura_core
mingw32-make -j4 MYCFLAGS=--coverage MYLIBS=--coverage
ビルドが終わると、*.gcno ファイルが生成され、さらに sakura.exe を実行すると、*.gcda ファイルが生成されます。
カバレッジ:
mkdir coverage
gcovr -r . --html --html-details -o coverage/coverage.html --source-encoding utf-8
これで、coverage ディレクトリに HTML 形式のカバレッジレポートが出力されます。
結果はこんな感じで見ることが出来ます。 https://codecov.io/gh/k-takata/sakura/branch/feature%2Fmingw-coverage
これカッコいいですね。
意思決定＆方針決めの場面において、カッコいいかどうか は重要な基準になると思います。
というわけで、なんとか入らんかな？と思うわけですがどうでしょう。
ただ、検出された行数がgcovとvisual studioでだいぶ違うのがなんか気になりました。
| tool | total | coverage |
|---|---|---|
| gcov | 67,882 | 14.58% |
| vs2017 | 126,799 | 4.19% |
なんでだろう・・・（最新masterで測り直したら4%でした。）
これで、GHA 上で、
--coverageオプションを使って sakura.exe をビルドし、実行してカバレッジを取得し、codecov に結果をアップロードすることが出来ます。
--coverage オプションって何だ？と思って調べたら、昔からある -ftest-coverage オプションの短縮指定バージョンなんですね。
https://stackoverflow.com/questions/28840261/gcov-what-is-the-difference-between-coverage-and-ftest-coverage-when-buildi
--coverage オプションが使えるようになったのがいつか調べてみましたが、GCC 4.1辺りのようで既に相当昔のことでした。
ただ、検出された行数がgcovとvisual studioでだいぶ違うのがなんか気になりました。
ファイル単位でどういうところに差分が出ているか見ていくしかないですかね。 https://codecov.io/gh/k-takata/sakura/tree/60b9b0434b6957d69198b663ac00375a24cc90fb/sakura_core
よくよく考えてみたら、vs2017のtotalってブロック数（≠行数）でした。
int ret = a == b ? 0 : 1;
という1文に対し、2と数えるのがブロック数という単位と思われます。正確な定義は知らない・・・。
https://github.com/microsoft/WinAppDriver
このへんかな、日本語入力とか弱いみたいだけど・・・ あとAzure PipelinesとかAppVeyorで動くのかって問題も（あ、ローカルでテストでもいいけど）
これはとても良さそうですね。CI でテスト実行を自動化はとても便利ですけど仮にそれがもし無理だったとしても、PRの作成者がローカルで実行してPRの説明にログファイルを添付するやり方でも問題無いと思います。ただし実行完了までに時間が掛かってしまうとそれをする気が失せてしまうので、量が増えてきたらテスト量を絞った簡易テストを用意した方が良いでしょうね。
この issue で語っているのは、似非スモークテストです。
構造的に単体テストできないコードを無理やりテストする手段としての全機能網羅ができないか？を話題にしていて、本物のスモークテストとは少し趣旨が違います。
ただ、バッチで実現するとスモークテストというよりはリグレッションテストに近い雰囲気のものになりそうです。
スモークテスト ＝ なんとなく主要機能を動かしてみるテスト。 リグレッションテスト ＝ 特定の機能の挙動がある時点から変化していないことを確認するテスト。回帰テストともいう。