テストを整備する

[Hiroshiba]

#90 のつづき。

バージョン１を目指すには必須かなと思います。
Electron・Vue・Vuex・インストーラなど様々な領域で、まずは単体テストがあれば良いのかなと思ってます。

#164 が参考になるかもしれません。

[Hiroshiba]

どちらかというとあってほしいのはE2Eテストなのかなと思い始めました。
単体テストを書くには既存実装に対する深い理解がないと難しいのと、
アプリケーションとして挙動を保証したいのはユーザー行動に対する正しいレスポンスなためです。

エンジンはモックではなく本番に近い物を使ってしまって、起動したらテキスト欄が表示されているとか、テキスト入力した後音声合成できるとか、そういうテストが開発のコスパがいいのかなと感じました。

[so-c]

e2eテスト作れそうなので少し調べてみます

[Hiroshiba]

コメントありがとうございます！！！とても心強いです！！！！
もし不明な点等あればなんでもお聞きください！！

[so-c]

@Hiroshiba お返事ありがとうございます。ちょっと試してみたので早速相談させてください。

前提

Electronのドキュメントによるとテストフレームワークは２系統。PlaywrightかWebDriver interface.（カスタムテストドライバは私の手には余ります）

比べてみると、Playwrightはエントリポイントから起動でソースマップが使えるなどデバッグ効率が高そう。WebDriver系はバイナリから起動なのでユーザ環境に近いがデバッグ効率が低そう（CIは絶望的に思えます）。

一番聞きたいこと

いろいろ他にも比べられるのですが、一番大事なのは「どの状態での挙動の保証を優先」だと思うので、ご意見伺いたいです。

Playwrightでいくなら

fork先ではPlaywrightを試していて、テストランナーからElectronApplication のインスタンスを作るところまで確認できました。so-c#3

課題は山盛りですし、捨てて WebDriver系試すのもOKです（その場合 wdio がよさそう）。ただ、私の環境がAMD GPUなので、PR前に肝心のCUDA版バイナリを動かせない問題はありますが……

[Hiroshiba]

コメントありがとうございます！
僕もPlaywrightが良いのかなと思いました！

一番大事なのは「どの状態での挙動の保証を優先」だと思うので、ご意見伺いたいです。

e2eテストについての解像度が高くなく、ちゃんと言葉にできるか怪しいのですが、「ユーザー操作に対してアプリの挙動が想定どおりである」ことを保証したいと考えています。

例えば、＋ボタンを押したらテキスト欄が増えるとか、テキストを足したりいろいろ操作したりしたあとの状態が想定と同じかとか･･･。
なるべく実際の動作環境に近いと潜在的な問題に気づけそうだと思っていますが、どこまで実環境を想定すべきかはちゃんと答えを持っていません･･･。

もし何か頓珍漢なことを言っていたらすみません！

[so-c]

なるべく実際の動作環境に近いと潜在的な問題に気づけそうだと思っていますが、どこまで実環境を想定すべきかはちゃんと答えを持っていません･･･。

実環境に近づけるの大変ですしね……。

お返事、ありがとうございます！　それではPlaywrightの課題もう少し調べてみます。問題切り分けられたらまた相談させてください！

[so-c]

Close #4 so-c/voicevox@e1835ab で初期表示を確認するテストが動きました。

結局テストコードでdotenv.config()という乱暴な方法なのですが、これはこれでよい面もあるので別Issue #8 · so-c/voicevoxに。

使っていないCypressの除去とテスト実行方法のドキュメンテーションができれば、そのコマンド打てば他の人も使ってもらえる状態になるのでそこまで進めたらPRしたいと思いますがいかがでしょう？

GitHub Actionsにもとかテストの追加などは別Issueでやってもよいかなと思い始めていて

[Hiroshiba]

たしかに環境違いのテストがしやすくなって良いかもですね！

そこまで進めたらPRしたい

ぜひお願いします！！
そういえばVue CLI Plugin Electron Builderのalpha版を使うことになると思うのですが、ビルド時などになにか別の問題があるかもなので、テスト時のみそのalpha版を使うのもありかなーと思いました。
･･･が、テスト時のみnpm installする良い感じの方法が無さそうな気がしますね･･･。

NODE_ENVにproductionがどうしても来ちゃうのは躓きポイントなので、そちらのPRがマージされたタイミングでissue作るのも良さそうだなと思いました！

[so-c]

ぜひお願いします！！
ありがとうございますー。

テストだけalpahが使えれば副作用の心配がなくなるので嬉しいですよね……。
so-c#6
Issueは立ててるのですが、PR前にもう少しリスクは下げておきたい

テストがのんびりしているうちに、3.x正式リリース、別の理由で本ビルドにそれを採用
となって上がってくれていると楽なのですが😁

[Hiroshiba]

ビルドが通るかはPRマージ後にチェックビルドしてみて、ダメそうならrevertを検討するくらいの感じでも良いのかなと思っています！
ご心配でしたら、一応npm run electron:buildでビルドは可能です。
（まあまあ時間がかかると思います。）

[Hiroshiba]

メモです。
Vue CLIからViteに移行した関係で、vue-cli-plugin-electron-builder周りの問題はなくなったかもです。
（まあalpha版を使うことで解決していたので変更はないのですが）

• Migrate: vue-cliからviteに移行 #1207

[Hiroshiba]

• ブラウザでEditorが動作する状態にする #1345

がマージされました 🎉
e2eテストが書きやすくなったはず？