これの続編で、CI上で実行したい！
そう思ってあれこれやってて得られた学びです。
Dockerで動かす
CircleCIとかなんたらCIとか、まあとりあえずDockerの中で動くようになればいけるやろってことで。
FROM circleci/node:8.11.0
USER root
# get the latest browsers
RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - && \
sh -c "echo 'deb http://dl.google.com/linux/chrome/deb/ stable main' >> /etc/apt/sources.list.d/google-chrome.list" && \
apt-get update && \
apt-get install -y google-chrome-stable
RUN apt-get remove binutils && \
sh -c "echo 'deb http://ftp.hr.debian.org/debian sid main' >> /etc/apt/sources.list" && \
apt-get update && \
apt-get install -t sid firefox
# fetch tests
RUN git clone https://github.com/leader22/webrtc-e2e.git && \
cd webrtc-e2e && \
npm i && \
echo "window.__SKYWAY_KEY__ = '<YOUR_KEY_HERE>';" >> ./src/shared/key.js
WORKDIR webrtc-e2e
CMD npm run test最終的にこういう感じに。
わざわざ`git clone`してるのは、まあ便宜上というやつ・・。
Firefoxを自前でインストールしてるのには理由があって、次の記事を参照。
Chromeも最新バージョンが欲しいので結局自前でインストール。
さて、いよいよ学びたちです。
FirefoxHeadless on Linuxでは、getUserMedia()できない
冗談抜きで。
挙動として、`getUserMedia()`してる行に差し掛かるとそこで止まる風。
`{ fake: true }`ならパーミッションはスキップできるはずだが、それでも止まる。
- なんかそういうフラグが必要なのか
- インストール方法がまずいのか
- TestCafeとLinuxの相性なのか
原因はわかってないけど、とりあえず動かない。
ので、Canvasから取るなりなんとかしてMediaStreamを自作しないといけない。
ただ音に関しては、TestCafeでWebAudioで音を出せないっぽいので、どうしようもないのでは・・？というところまで。
TestCafeのspeed
macOSのローカル、macOSのDockerよりも、CircleCI上で動かすには余裕を持った設定にしないとダメだった。
これはまあポチポチ試して最適な値を見つけるしかない。
謎の環境差異
- Dockerイメージは同じ
- ブラウザのバージョンも同じ
- もちろんテストコードも同じ
なのに、
- macOSのローカルでPASS
- macOSのDocker内でPASS
- CircleCIのDocker内でFAIL
するパターンがあって意味がわからない。なんのための仮想環境なの？って感じ。
まあすっぱり諦めて、忘れた頃に治ってることを祈るのが賢明かなー。
E2E on CIは地獄
だと思う、個人的に。
デバッグがつらいだけでモチベーションはがりがり溶けていくし、環境差異もつらい。
がんばってLinuxで動かしてCIに載せたとしても、実際のユーザーはほとんどWinかmacやんっていう。
あとはこの分野はブラウザのバージョンによっても大きく挙動が左右される悲しい世界。
なので、Winとmacでブラウザ3世代くらい入った実機をいつでもさわれるようにする方が、コスパいいんじゃないか？と思ったりする。
その実機をいい感じに操れる術はあるにこしたことがないけど・・。
いやーほんとにつらい世界ですね！