筆者のプログラミング力

職業プログラマーの経験なし、QA→企画→QAといった経歴です。
そのためお給料もらってお客様向けのコード書いた経験がありません。実際にかけるほど理解しているとも言えないです。

一応、VBAやGAS使った効率化、SQLでSELECT使ったテスト活用、Shellを使ったファイル移動や自動作成による効率化などは個人または狭い範囲で使うものを作った経験はあります。

そんな私が自動テストに憧れてE2E書いて、レビューに提出したら、めっちゃ喜んでもらい、実際に稼働するまでに学んだことをまとめてみました。自動テスト書いてみたいなーと思っていて一歩踏み出せない方に届けばいいなと思っています。

記事にしたこと

今はどうしてるのか
なぜE2Eを書こうと思ったのか
使用技術
勉強するにあたって捨てたこと
どのように勉強して理解しているのか

今はどうしてるのか

E2Eが実践投入されています

毎週少しずつ、ものすごく簡単なシナリオを実装しています。
例：遷移チェック（ページAからページBに遷移して、特定文字列が表示されていること）
（CIは仲間の力を借りて実装してもらいました）
実際に、ライブラリのアップデートで動作しなくなったことや、リンク切れの指摘を出したこともあり、微力ながらもリグレッションテストとして機能しつつあるかなと実感しています。

簡単ですが実装状況のグラフです。所々テスト項目の追加で下がっていたりします。

最近はAndroidアプリでのE2Eも実装してます

@CaptainPagパイセンがEspressoを使ってAndroidのE2E実装をしていたので、私も便乗してこちらのお手伝いも始めました。
Webとは違うUI概念やコードの書き方の違いに苦労していますが、要素を掴んでアクション→目的の箇所でテストするという部分は同じなので、知識流用ができるなという実感をしています。

なぜE2Eを書こうと思ったのか

キャリアアップのため
弊社に限らずですが、QA採用で自動テスト経験が求められていることを感じています。
そのため、自動テストの知見は無駄にはならないと思い、どっかのタイミングで学びたいなーと考えてました。
単体テストはプログラマーさんが書いてるし、まずは目に見えて動く分かりやすさからE2Eをチョイスした形です。
手動テストを減らしたいため
これまでの職場では手動テストがメインだったこともあり、単純なテストでも手でやっていました。
ものすごく眠くなっちゃうんですよね。そこに工数使うのももったいないと思うし、別のことに時間を使いたいという意図がありました。
自動で動くことの憧れ
これは子供っぽい理由かもしれませんが、ブラウザとかで、自分で操作せずに自動で動くのってなんかSFチックで格好良くありませんか？私だけ？それが自分での手で作り出せるようになったら…という気持ちがありました。

使用技術

RSpec
Capybara
Turnip
Selenium

Rubyではよくありそうな構成ですね。調べる上で情報が多いこと、社内エンジニアに知見がありそうといった観点で技術チョイスしました。

勉強するにあたり捨てたこと

技術が動く理由
いまだにどういった原理で動くのかぶっちゃけわかってません。いろんな記事見て試したら動くぞ！やった！！！ぐらいの浅い理解です。あくまで自動で実行して動作することを担保するための手段として、動けばいいやな精神でトライしました。
ベストプラクティス
良いお作法は大事だと思ってます。また先人の知恵は偉大だと思っています。
でも、あえて踏んだり苦しんだりすることで得るものがあるだろうし、まずは動かしてみるを大事にしていたのでこの辺もよくわかってません。

どのように勉強して理解しているのか

必要なもの

Rubyのインストール方法
- インストールの仕方を調べてインストールできれば大体なんとかなります
ターミナルの使い方
- cd とかいくつか覚えてれば大体なんとかなります
Pathの通し方
- Pathの通し方を調べて通せれば大体なんとかなります
gemのインストール方法
- 設定ファイル書いてインストールできれば大体なんとかなります
最初のE2E設定
- Capybaraの設定方法を調べて設定できれば大体なんとかなります

検索すれば答えはある

Qiitaをはじめとして、先人の知恵は検索すると見つかります。
検索ワードも特殊なことはなく、「ｘｘやり方」「ｘｘ　インストール」「ｘｘ　初期設定」などなど。
思いついたキーワードを入力→上から見ていく、良さそうな記事はタブとして残しておく繰り返しでした。

最大の壁はローカルPCで実行できる状態にすること

Pathの通し方とか初期設定みたいなところが一番手間な気がしています。
でも乗り換えちゃうと頻繁に設定変更する訳でもないので、ここをまず乗り越えるのが重要です。

まずはこれだけ覚えた

特定URLにアクセスする
- visit "https://~"
要素を見つけてリンクやボタンをクリックする
- find("hogefuga").click　(aタグはhrefがないとクリックしてくれないのでその場合使ったり)
- find_all("a",text: "hogefuga").first.click (複数見つかる要素の1番目クリックしたい時に使ったり)
- click_on "hogefuga"
テキストエリアに入力する
- fill_in "hogefuga", with:"hogefuga"
ページ内の文字列をテストする
- expect(page).to have_content("hogefuga")

特定のURLにアクセス→特定の要素をクリックして遷移する→メアドみたいなテキスト入力が必要な場合は対応する→必要なページまで進んだら、ページ内の文字列を使ってテストする　簡単なものです。

勉強していた日

さすがに成果が出るものか分からない状態で、会社の稼働時間を使うわけにはいかなかったです。
なので、土日に勉強していました。最低限コードかけるかも・・・といったところまで来たらテスト環境使って書いてました。

ハマっても解決策はある

たまに単純なクリックだけでも、うまく動かない要素とかあって、数時間単位でハマっていたこともあります。
手を変え、品を変え、調べたことを試していたら解決できることも多かったので、答えは必ずあると思っています。
現状の技術で解決できそうになければ、考え方を変えるのも有効かなと思います。

最後に

やる前までは高く感じた壁ですが、やってみると案外、、、という印象です。
そしてテスト手段が増える＝テストの幅広がったかなと、特に再発防止策としてE2Eを選択肢に選べるので収穫は大きかったと思ってます。
今後は単体テストが書けるようになりたいのでその辺もしっかり勉強していきたいです。
そして、ビビッドガーデンでは仲間を募集中です！一次産業の課題を解決していきましょう！