Skip to content
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.

RSpecとCapybaraを使ってChromeでjsをレンダリングした結果の画面内容をテストする #5961

Merged

Conversation

suzuryo
Copy link
Contributor

@suzuryo suzuryo commented Feb 1, 2021

👏 解決する issue / Resolved Issues

📝 関連する issue / Related Issues

⛏ 変更内容 / Details of Changes

  • RSpecとCapybaraを使ってChromeでjsをレンダリングした結果の画面内容をテストする基盤
  • h1の内容をテスト
  • h2の内容をテスト
  • h3の内容をテスト
  • 「ハンバーガーメニュー」の開閉をテスト
  • 「テーブルを表示ボタン」の開閉をテスト
  • 手順を FOR_DEVELOPERS_RSPEC.md にまとめ

- http://localhost:3000 を対象にテストする
- ChromeDriver を使って Headless Chrome を iPhone6/7/8 デバイスエミュレーションモードでテストする
- 各言語に対応したimg src
- 各言語に対応したHeaderText
- svg に mdiChartTimelineVariant が埋め込まれている
- 各言語に対応したpageTitle
- SiteTopUpper の高さ (約1600px) の分をスキップ
- div.v-lazy の中に div.row が2つ入ってる
- min-height (600px) ずつスクロールする
- 各言語に対応した h3
- 各言語に対応した h3
- 各言語に対応した h3
@kaizumaki
Copy link
Collaborator

@suzuryo PRありがとうございます!これって、どのように使うのでしょうか...?手順を教えていただけると助かります。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 3, 2021

@kaizumaki issue #5960 の方に実行手順を書いてありますが、もっと詳しく手順書が必要でしょうか?

@kaizumaki
Copy link
Collaborator

ああ、なるほど!issueに書いてくださってたんですね。ありがとうございます。

@kaizumaki
Copy link
Collaborator

手順書はissueだと流れてしまうので、ソースコード内のどこかに書いておいてもらえると嬉しいです 🙏
FOR_DEVELOPERS.md でもいいと思うのですが、いかがでしょう。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 3, 2021

@kaizumaki FOR_DEVELOPERS_RSPEC.md にまとめました

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 3, 2021

あと.github/workflowsでrenovateが作ったPRの時だけ実行するか、全てのPRで実行するか方針を決めていただければ。

@kaizumaki
Copy link
Collaborator

@suzuryo ドキュメントありがとうございます!私の手元環境でやってみました。

まず、環境構築のChromeDriverの「PATHを通す」というところがピンときませんでした(macなので、あまりその辺のお作法をわかっておらず...)。~/.bashrc または ~/.bash_profile に書くのですね(新しめだと .zshrc )。

その後無事動いたのですが、そもそもブラウザテストのことをよくわかってなかったです。これって「動作テスト」が主な役割なのですかね?「表示」についてのテストは、カードのタイトル部を確かめているのでしょうか。
テストの結果に、「何のテストが通ったのか」が文章で書いてあるほうがよいかと思いました。

それと、動作テストであるなら、各グラフの下のテーブルも開閉するかどうかがあるといいなと思いました。

また、テストの内容のメンテナンスが心配になりました。今後もコンポーネントが増えたりレイアウトが変わったりする可能性は十分にあるので。

お願いが多くて恐縮です 🙇‍♀️ できる範囲で、段階的にでも構いません。まずはご意見伺いたく思います。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 3, 2021

@kaizumaki

環境構築はいろんな作法があるので最低限の条件「PATHを通す」とだけ書いておきました。

  • https://chromedriver.storage.googleapis.com/88.0.4324.96/chromedriver_mac64.zip
    をダウンロードしてダブルクリックでZIP解凍して /usr/local/bin にFinderでコピーする
  • curl -O https://chromedriver.storage.googleapis.com/88.0.4324.96/chromedriver_mac64.zip
    unzip chromedriver_mac64.zip
    mv chromedriver /usr/local/bin/
    # を実行する
  • Homebrew を使っているならば、brew install --cask chromedriver を実行する。
  • 自分の好きなディレクトリにchromedriverをコピーして、.zshrc や .bashrc で $PATH に追加する

などいろんな方法があります。


「動作テスト」としてDOMの要素をクリックして、結果として求めるDOM構造に変化したか、などの動作をテストできます。

682eeed#diff-15ab8ca31a3d32bfc064f0e6176824baa252939c5ab5e90fae74550b4213fc0dR19-R22

の部分では

<button class="SideNavigation-OpenIcon">という要素をクリックしたら

<div class="SideNavigation open">
  <div class="SideNavigation-Body -opened">
    <button class="SideNavigation-CloseIcon"></button>
  </div>
</div>

という構造がブラウザ内に存在することをテストしています。


「表示テスト」として、特定のDOMに求める属性が設定されていることをテストできます。

1a9de9b#diff-5b22336129d546b6e79911431ca0f14a893e79cbd29f6f76c7442a6ab0b3fad0R13-R15

の部分では

http://localhost:3000/ にアクセスしたら、

<h1 class="SideNavigation-HeaderTitle">
  <a class="SideNavigation-HeaderLink">
    <img class="SideNavigation-HeaderLogo" src="/logo.svg">
  </a>
</h1>

という構造が存在し、

http://localhost:3000/en/ にアクセスしたら、

    <img class="SideNavigation-HeaderLogo" src="/logo-en.png">

http://localhost:3000/zh-cn/ にアクセスしたら、

    <img class="SideNavigation-HeaderLogo" src="/logo-zh-cn.png">

と言語ページによってロゴ画像のsrc属性が差し代わっていることをテストしています。


259bb6f#diff-dc36b9cee656b5f983f8903f63b7c53b438831cd89bf8752a73cdee4731112ffR14

の部分では

<h2 class="pageTitle">
  <span class="v-icon">
    <svg>
      <path d="">

のd=の中身が M3,14L3.5... (指定したSVGの文字列)であること、

つまり
SiteTopUpper.vue の <page-header :icon-path="headerItem.iconPath">のpropsであるmdiChartTimelineVariantがPageHeader.vueにちゃんと受け渡しできているかをテストしています。


259bb6f#diff-dc36b9cee656b5f983f8903f63b7c53b438831cd89bf8752a73cdee4731112ffR18

の部分では

http://localhost:3000/ にアクセスしたら、

<h2 class="pageTitle">都内の最新感染動向</h2>

http://localhost:3000/en/ にアクセスしたら、

<h2 class="pageTitle">Updates on COVID-19 in Tokyo</h2>

http://localhost:3000/zh-cn/ にアクセスしたら、

<h2 class="pageTitle">东京都最新新型冠状病毒感染情况</h2>

という文字列になっていることをテストしています。


「何のテストが通ったか」を全部出力すると冗長なので、「失敗したテスト項目」だけが出力されるようにしています。

テストを実行するコマンド

bundle exec rspec spec

に formatオプションを渡して

bundle exec rspec spec --format documentation

と実行すると、今どのテストが成功・失敗しているのか、もう少し詳細が出力されます。


それと、動作テストであるなら、各グラフの下のテーブルも開閉するかどうかがあるといいなと思いました。

岩手版では「データを表示 をクリックしてv-expantion-panel開いて、そこに表示されたテーブルの上から4行目のtdの中身が期待した値になっているか」など詳しくチェックしています。
https://github.com/MeditationDuck/covid19/blob/development/spec/lib/PositiveRateCard.rb#L32

これも、どこまで詳しくテスト項目に含めるか、ということなので、東京版ではどこまでテストを求めるかを決めていただければ。


「内容のメンテナンス」は仕様が変化すれば、それに追従してテスト内容も変化する必要があります。
本来はテストコードと実装コードを同時にコミットするのが理想です。

テストコードを充実させたり、仕様の変更に追従させるのは、そこそこ体力が必要になります。

@kaizumaki
Copy link
Collaborator

@suzuryo 解説ありがとうございます!丁寧に書いていただき助かります。
「PATHを通す」については suzuryoさんが先のコメント #5961 (comment) に書いていただいているそのままを FOR_DEVELOPERS_RSPEC.md に追記していただけるといいなと思いました。(あらゆる環境を網羅してなくていいと思います。「一例として」ということで。)

表示テストについて、h3タイトルのテキストなどはよっぽどのことがない限り変更がかかることはないと思っているんですが、ここのテストが失敗する場合っていうのは、どういう状況が考えられるでしょうか?例えば、カードごとまるっと非表示になってしまうとかですかね?
岩手県版で、どういう時にテストが失敗していたのか、事例を教えてもらえるとうれしいです。
また、すべての言語のページでテストを行ったほうがいいのかどうかもご意見いただけると。私は英語ページが成功していれば、その他の言語のページも失敗することはないのではないかと思っています。

というのも、いまご提示いただいた内容でテストを回すと3分30秒かかっており、github actionsで回す際の負荷がどれぐらいかかるかが気になっています。

「内容のメンテナンス」は仕様が変化すれば、それに追従してテスト内容も変化する必要があります。
本来はテストコードと実装コードを同時にコミットするのが理想です。

これはまったくその通りですね。そのあたりは運営で方針を考えようと思います。

いずれにせよ、当サイトの運用での決めの問題であると理解しました。少しお時間いただけると助かります 🙏

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 4, 2021

@kaizumaki

h3タイトルのテキストなどはよっぽどのことがない限り変更がかかることはない

例えば
2b7b85d
の h3 のテストについて説明すると、

h3 のテキストの中身が期待した値とイコール(eq)かどうか、翻訳が正しく当たっているかだけをテストしているコードに見えますが、

実際には

  1. http://localhost:3000/ にアクセスして
  2. 画面を下までスクロールしたら
  3. index.vueのtemplateの<lazy-cards-tabs>の遅延ローディングが成功してそのDOMが構築され
  4. そこに<a href="#tab-1"></a>という要素があり、その「その他・参考資料」タブをクリックしたらタブが切り替わって
  5. 画面を下までスクロールしたら
  6. CardsReference.vueで<cards-lazy-row :rows="rows" />としてlazyに読み込んでいるCardコンポーネントのDOMが構築され
  7. それらのCardの中に h3 として求める翻訳テキストが入っている

というアプリケーションの実装の動き

を、結果としてテストしていることになります。

なので、このテストが失敗するとしたら

  • nuxt.config.tsなどに不具合があり、そもそもproductionのbuildに失敗した
  • 何か実装の一部が失敗して、カードごとまるっと非表示になってしまう(から該当するh3が存在しない)
  • CardsReference のカードの位置を変えた、つまり、<cards-lazy-row :rows="rows" />のrows[]の配列の順番が変わった

という、nuxtアプリケーションの実装面での出来事や、

  • Vuetifyをアップデートしたらv-lazyv-intersectが仕様変更しており、以前と動作が変わったので遅延ローディングがうまく動いていない(2,5に該当)
  • Vuetifyをアップデートしたらv-tabが仕様変更しており、以前と動作が変わった(3,4に該当)
  • vue-i18nをアップデートしたら仕様変更しており、$t()で期待した翻訳が得られない
  • 各言語に翻訳キーが存在しない(今はあえてja.jsonにフォールバックして回避している)
  • GoogleChromeをアップデートしたらChromeの挙動が何か変わった

という、関連ライブラリのバージョンアップによる意図しない挙動の変更(当初の目的の更新負荷低減のためにリグレッションテスト)

これらを暗に含んだ「jsがブラウザで表示されるまで」の項目をテストしていることになります。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 4, 2021

岩手県版で、どういう時にテストが失敗していたのか事例

failする多くは、タイミング問題で、lazyで読み込んでいる部分を、読み込み完了する前のタイミングでテストが動いてしまった場合です。何かの要素をclickするテストを書いたら、その後にsleep 1とかすると回避できるような問題です。本来はlazy処理が完了するまでテストの実行を待つような仕組みを実装すると良いですが、今はsleepで回避しています。

ほか、

  • 7日間移動平均の値を計算したら「3.05」だったとして、これを小数第1位で画面上に表示するときに、四捨五入されて「3.1」になるかと思ったら、utils/monitoringStatusValueFormatters.tsgetNumberToFixedFunction()を通すと、3.05.toFixed(1)となり、jsでは「3.0」になる(浮動小数点の丸め問題 rspec: 3.05を一桁にする処理でjsとrubyで結果が違う MeditationDuck/covid19#1196
  • data.jsonが "lastUpdate": "2021\/02\/01 09:00"だと、日本語版で表示すると最終更新 2021年2月1日 9:00 JSTとなるけど、英語版で表示するとLast update Feb 1, 2021, 09:00 JSTとなる「9時の部分が1桁か、0 paddingされた2桁か」の問題(https://github.com/MeditationDuck/covid19/pull/1271/files OSの言語設定の時刻表示フォーマットに依存?)

など細かい挙動の部分でfailしたことがありました。

ほか、ページ上の全てのaタグに設定されているhrefのURLが存在しているかリンク切れ(実際にアクセスして200 OK)をチェックをしているので、
https://github.com/MeditationDuck/covid19/blob/development/spec/feature/check_broken_links_spec.rb
この部分でもfailする場合があります

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 4, 2021

すべての言語のページでテストを行ったほうがいいのかどうかもご意見いただけると。私は英語ページが成功していれば、その他の言語のページも失敗することはないのではないかと思っています。

全ての言語のassets/locales/lang.jsonに、サイトで使われている $t('翻訳キー')が全て存在するかどうかをテストするならば、全言語に対して回した方が良いし、ブラウザのconsoleに出力される「vue-i18nの対応する翻訳キーが存在しないよwarning」

[vue-i18n] Cannot translate the value of keypath '自分や家族の症状に不安や心配があれば
まずは電話相談をどうぞ'. Use the value of keypath as default.

が出ててもよい(対応する翻訳キーが準備できていなくてもよい)ならば、全言語に対してテキストの確認は回さなくても良いかもです。

h1 > img.SideNavigation-HeaderLogoのsrc属性 や div.Annotation など、言語によって挙動を切り替えている部分は、テストした方が良いかも。

テストを回すと3分30秒かかっており、github actionsで回す際の負荷がどれぐらいかかるかが気になっています。

テストを実行するときに

# 全部のテストを並列に実行 (parallel_rspec)
$ bundle exec parallel_rspec spec

のコマンドを使うと、搭載しているCPUをフルに使って並列実行するので、16コアならば16並列で処理しますが、Github Actionsを動かすGitHub-hosted runnersのスペックは 2-core なので、2並列の処理になるので、そこそこ時間がかかります。

岩手版だとja/enの2言語しか対応していないので2言語分ですが、7分くらい https://github.com/MeditationDuck/covid19/actions?query=workflow%3AgoogleSheetMenu_development

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 4, 2021

岩手版はテストを回してpassすることを確認できているので、node は 14.15.4 の最新安定板で運用しています。
Vue@3.0.0 に対応するとかの動きが始まっても、テストがあれば自信を持って作業できるかと。

@kaizumaki
Copy link
Collaborator

@suzuryo 丁寧な解説ありがとうございます!わかりやすくて助かります。

#5961 (comment) については、なるほどです。この工程は必要ですね。そもそもRenovateの更新負荷低減が動機でしたから。

ブラウザのconsoleに出力される「vue-i18nの対応する翻訳キーが存在しないよwarning」が出ててもよい(対応する翻訳キーが準備できていなくてもよい)ならば、全言語に対してテキストの確認は回さなくても良いかもです。

これは出ててもいいと思っています。
それよりも、Actionsでテストを回す際の負荷の方が気になっています。

岩手版はテストを回してpassすることを確認できているので、node は 14.15.4 の最新安定板で運用しています。
Vue@3.0.0 に対応するとかの動きが始まっても、テストがあれば自信を持って作業できるかと。

これは非常にいいですね!

いま運営で、どのPRのActionsに紐付けるか検討していますので、しばしお待ちください。導入後も、もし負荷が目に余る状態になってきたら、解除することもありえますこと、ご了承いただけたらと思います。

あと、追加でテストしたいのは、テーブルの開閉ですかね。
それと、ルートディレクトリにできる vendor フォルダは .gitignore に加えておかなくていいのでしょうか?

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 4, 2021

@kaizumaki

追加でテストしたいのは、テーブルの開閉ですかね。

コミットしました
cda1540
bb0a1c8

ルートディレクトリにできる vendor フォルダは .gitignore に加えておかなくていいのでしょうか?

Rubyの環境構築方法によっては vendor フォルダが生成されるので、ignoreしました
92ea121

Cardにid属性が付与されていないとテストのセレクタを書きづらいので、cards以下のコンポーネントにid属性を付与しました
45a87a3

nth-child()を使ったセレクタから、id属性を使ったセレクタに書き換えました
e18f4a7
このようにセレクタを書くと、暗黙的にテストされていた

CardsReference のカードの位置を変えた、つまり、<cards-lazy-row :rows="rows" />のrows[]の配列の順番が変わった

がテストされなくなります。

つまり nth-child でセレクタを指定しないので
```
CardsReference のカードの位置を変えた、つまり、<cards-lazy-row :rows="rows" />のrows[]の配列の順番が変わった
```
という暗黙的なテスト項目はテスト対象要素から外れた
@suzuryo suzuryo force-pushed the tokyo-metropolitan-gov/add_rspec branch from d111635 to 90ece95 Compare February 4, 2021 14:27
@kaizumaki
Copy link
Collaborator

@suzuryo もろもろありがとうございます 🙇‍♀️
ところで、こちらのPRの最新の状態をpullして、私の手元でテストを試してみたのですが、

Finished in 39.35 seconds (files took 1.34 seconds to load)
75 examples, 75 failures

ということで、軒並み失敗してしまいました。
何が原因かわかりますか?

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

@kaizumaki Finished より前に、どんなエラーが出力されているかによりますが、ローカルのwebサーバーが立っていなくて http://localhost:3000 にアクセスできていないとか?

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

いま運営で、どのPRのActionsに紐付けるか検討していますので、しばしお待ちください。
導入後も、もし負荷が目に余る状態になってきたら、解除することもありえますこと、ご了承いただけたらと思います。

workflowsとして
https://github.com/suzuryo/covid19-iwate/blob/development/.github/workflows/on_pr_from_renovate_rspec.yml
のように、

on:
  push:
    branches:
      - 'renovate/**'

と書くと、renovate が renovate/ts-loader-8.x のようなブランチを作った時だけ動かすことができそうです。

@kaizumaki
Copy link
Collaborator

@suzuryo
あ、先ほどの全てコケた件、サーバーが立ち上がってなかったです。失礼しました 🙇‍♀️
改めて、テストを走らせた結果は次のようになりました。半分ほどコケたようですね。

% bundle exec rspec spec
FFFFFFFFFFFFFFFFFFFFFFFFFFF................................................
Finished in 7 minutes 2 seconds (files took 0.84051 seconds to load)
75 examples, 27 failures

Failed examples:

rspec './spec/feature/index_CardsMonitoring_DataViewExpantionPanel_spec.rb[1:1:1:1:1:1]' # page [/] ja CardsMonitoring #ConfirmedCasesNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsMonitoring_DataViewExpantionPanel_spec.rb[1:1:1:2:1:1]' # page [/] ja CardsMonitoring #MonitoringConfirmedCasesNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsMonitoring_DataViewExpantionPanel_spec.rb[1:1:1:3:1:1]' # page [/] ja CardsMonitoring #UntrackedRateCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsMonitoring_DataViewExpantionPanel_spec.rb[1:1:1:4:1:1]' # page [/] ja CardsMonitoring #PositiveRateCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsMonitoring_DataViewExpantionPanel_spec.rb[1:1:1:5:1:1]' # page [/] ja CardsMonitoring #TokyoRulesApplicationNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsMonitoring_DataViewExpantionPanel_spec.rb[1:1:1:6:1:1]' # page [/] ja CardsMonitoring #HospitalizedNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsMonitoring_DataViewExpantionPanel_spec.rb[1:1:1:7:1:1]' # page [/] ja CardsMonitoring #SevereCaseCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsMonitoring_h3_spec.rb[1:1:1:1:1]' # page [/] ja h3 CardsMonitoring has h3
rspec './spec/feature/index_CardsMonitoring_h3_spec.rb[1:2:1:1:1]' # page [/] en h3 CardsMonitoring has h3
rspec './spec/feature/index_CardsMonitoring_h3_spec.rb[1:3:1:1:1]' # page [/] zh_cn h3 CardsMonitoring has h3
rspec './spec/feature/index_CardsMonitoring_h3_spec.rb[1:4:1:1:1]' # page [/] zh_tw h3 CardsMonitoring has h3
rspec './spec/feature/index_CardsMonitoring_h3_spec.rb[1:5:1:1:1]' # page [/] ko h3 CardsMonitoring has h3
rspec './spec/feature/index_CardsMonitoring_h3_spec.rb[1:6:1:1:1]' # page [/] ja_basic h3 CardsMonitoring has h3
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:1:1:1]' # page [/] ja CardsMonitoring #PositiveNumberByDevelopedDateCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:2:1:1]' # page [/] ja CardsMonitoring #PositiveNumberByDiagnosedDateCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:3:1:1]' # page [/] ja CardsMonitoring #TestedNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:4:1:1]' # page [/] ja CardsMonitoring #TelephoneAdvisoryReportsNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:5:1:1]' # page [/] ja CardsMonitoring #MonitoringConsultationDeskReportsNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:6:1:1]' # page [/] ja CardsMonitoring #TokyoFeverConsultationCenterReportsNumberCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:7:1:1]' # page [/] ja CardsMonitoring #MetroCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_DataViewExpantionPanel_spec.rb[1:1:1:8:1:1]' # page [/] ja CardsMonitoring #AgencyCard behaves like DataViewExpansionPanel Open Panel -> Close Panel
rspec './spec/feature/index_CardsReference_h3_spec.rb[1:1:1:1:1]' # page [/] ja h3 CardsReference has h3
rspec './spec/feature/index_CardsReference_h3_spec.rb[1:2:1:1:1]' # page [/] en h3 CardsReference has h3
rspec './spec/feature/index_CardsReference_h3_spec.rb[1:3:1:1:1]' # page [/] zh_cn h3 CardsReference has h3
rspec './spec/feature/index_CardsReference_h3_spec.rb[1:4:1:1:1]' # page [/] zh_tw h3 CardsReference has h3
rspec './spec/feature/index_CardsReference_h3_spec.rb[1:5:1:1:1]' # page [/] ko h3 CardsReference has h3
rspec './spec/feature/index_CardsReference_h3_spec.rb[1:6:1:1:1]' # page [/] ja_basic h3 CardsReference has h3

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

@kaizumaki
bundle exec rspec specで並列実行ではないテストを実行して、前半がFailしているのが気になりますね。

手順の2.2 / 2.3 のproductionコードをbuildしてyarn startでテストを実行したのではなく、yarn devでdevelopment環境で http://localhost:3000 を立ち上げたので、ビルド中にテストが走ってしまったとか?

@kaizumaki
Copy link
Collaborator

@suzuryo いやー、 yarn build ですねえ。 yarn dev は走っていないことは確認しました。念のため yarn install して再度 yarn build してテストしましたが、状況は変わらずです。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

@kaizumaki Finished の前にもログが出力されていると思いますので、全ログをgistなどでコピペください

@kaizumaki
Copy link
Collaborator

@suzuryo ログはこちらです(最初からこうやって渡しておけばよかったですね 🙇‍♀️ )。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

@kaizumaki
75 examples, 27 failures になるパターンを見つけました。
tokyo-metropolitan-gov/developmentのheadをproduction build して生成された /dist を localhost:3000 して、それに対してこのブランチの rspec を回すと 75 examples, 27 failures になるようです。

これは、
2b7b85d
41d4797
という nth-child() でのセレクターでの実装から、

45a87a3
で各cardに対してidを割り振り、そのidに対してセレクターが存在するか(そのidのカードが存在するか)
90ece95

に実装を変更してあります。なので、cardに対してidが割り振られていないproduction buildに対してrspecするとfailすると思われます。

@kaizumaki
Copy link
Collaborator

@suzuryo いや、cardにidはふってありますね。このPRをpullして試しているので。それともキャッシュでしょうか...

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

@kaizumaki
うーん、こちらでは #5961 (comment) のパターンしか見つけられていないですが、
yarn start じゃなくて python3 -m http.server -d ./dist 3000 とかで試してみたり?

@kaizumaki
Copy link
Collaborator

@suzuryo いろいろ試してみて、わかりました!ビルドされたコードからid属性が除去されているパターンがありました。

  • dev -> 除去されない
  • build -> 除去される
  • generate:dev -> 除去される
  • generate:deploy -> 除去されない

最終的に yarn generate:deploy でテストが通りました。
なぜ、id属性が除去されるのかまではわからずです。ちなみにid属性が除去されるパターンでは、カスタムの data- 属性も除去されるようです。class は残ります。もしかしたらvuetifyあたりが怪しいですよね。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

@kaizumaki ではidじゃなくてclass付与で実装してみます

ビルドされたコードからid属性が除去される場合があるため
Tokyo-Metro-Gov#5961 (comment)
@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 8, 2021

@kaizumaki id付与からclass付与に実装を変更しました

@kaizumaki
Copy link
Collaborator

@suzuryo 最新のコミット、pullして試しました。テストは無事に通りました。ドキュメントの更新もありがとうございます!
ところで、まだ全言語でテストしている項目があるようですが、日本語と英語のみにしてもらってもいいでしょうか?なるべく負荷を低減させておきたいのですが、いかがでしょう。

@suzuryo
Copy link
Contributor Author

suzuryo commented Feb 9, 2021

@kaizumaki
テスト対象を ja と en のみにするコミットをpushしました。

@kaizumaki
Copy link
Collaborator

@suzuryo ありがとうございます。かなりいい感じになったなと思っています。

% bundle exec rspec spec
...................................

Finished in 4 minutes 23.8 seconds (files took 1.36 seconds to load)
35 examples, 0 failures

あとはどこにフックするかですね。運営内で相談しますので、もうしばらくお待ちください 🙇‍♀️

```
bundle update
```

- capybara 3.34.0 -> 3.35.3
- regexp_parser 1.8.2 -> 2.0.3
- rspec-mocks 3.10.1 -> 3.10.2
- rspec-support 3.10.1 -> 3.10.2
Copy link
Collaborator

@MasaGon MasaGon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTMです。workflowへの組み込みは運営側で行います。

@kaizumaki kaizumaki added the ready-for-merge コードレビューが終わり、マージができるもの label Feb 23, 2021
@soutaito soutaito merged commit 6c93965 into Tokyo-Metro-Gov:development Feb 24, 2021
mcdmaster pushed a commit to mcdmaster/covid19 that referenced this pull request Feb 26, 2021
ビルドされたコードからid属性が除去される場合があるため
Tokyo-Metro-Gov#5961 (comment)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
ready-for-merge コードレビューが終わり、マージができるもの
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RSpecとCapybaraでUIの意図しない表示崩れ、動作不具合などを検知する
4 participants