kakakakakku blog

Weekly Tech Blog : Keep on Learning 👍

Autify で記事一覧から「1記事目」を厳密にクリックする

先週 Autify を使って kakakakakku blog の画面遷移をするシナリオをレコーディングしたときに「最新記事(1記事目)」をクリックするステップを作った(はずだった).しかし Autify のシナリオを数日間実行し続けたところ,実は「最新記事(1記事目)」をクリックできていなかったことに気付いた.今回は記事一覧から「最新記事(1記事目)」を厳密にクリックできるようにする.

kakakakakku.hatenablog.com

「要確認」とは?

先週作ったシナリオ「kakakakakku blog 画面遷移 + 検証」を実行したところ,以下のように「要確認」という警告が出た.テスト自体は成功している.この「要確認」というのが Autify の特徴的な機能と言える.Autify では「レコーディング時と完全一致しない場合に AI を使って探索をする」仕組みになっているため,今回は AI を使って探索し,結果をフィードバックするために「要確認」と表示してくれている.

f:id:kakku22:20200504094604p:plain

スクリーンショットを確認すると,2記事目に下がった「diff2html-cli 記事」をクリックしている.ようするに「最新記事(1記事目)」ではなく「完全一致する要素」を探索してクリックしてくれていると考えられる.

f:id:kakku22:20200504094650p:plain

記事一覧から「1記事目」を厳密にクリックする

今回は Autify の「JS ステップ機能」を使って「1記事目」を厳密にクリックできるようにする.

1.「シナリオ」を複製する

まず,シナリオ「kakakakakku blog 画面遷移 + 検証」を複製して「kakakakakku blog 画面遷移(JavaScript 利用)+ 検証」を作る.基本的な操作は今までと重複するため割愛する.

2.「シナリオ」を修正する

「1記事目」をクリックするため「JS ステップを挿入」を選ぶ.

f:id:kakku22:20200504094709p:plain

「JS ステップ」には JavaScript コードを自由に実装できる.今回は kakakakakku blog の「1記事目」を意味する CSS Selectors を使ってクリックするように実装する.やはり E2E テストの実現には CSS Selectors や XPath など,機械的に要素を特定する仕組みが必要なんだと再認識させられる.例えば,レコーディング後に「もしかして "1記事目" をクリックしましたか?」という確認が出てくる未来があっても良さそう.

document.querySelector('.entry:first-child .entry-title-link').click();

最終的に JavaScript を入力したシナリオ画面は以下のようになる.

f:id:kakku22:20200504094726p:plain

3.「シナリオ」を実行する

修正したシナリオを実行すると,JavaScript を使って正しく「最新記事(1記事目)」をクリックできるようになった(右側 : 今回の結果).

5/3 に記事を公開した後に実行したシナリオ結果

f:id:kakku22:20200504103648p:plain

5/4 に記事を公開した後に実行したシナリオ結果

f:id:kakku22:20200504103706p:plain

Autify FAQs

intercom.help

まとめ

Autify の「JS ステップ機能」を使って kakakakakku blog の記事一覧から「1記事目」を厳密にクリックできるようにした.さらに Autify の特徴的な機能と言える「要確認」も確認できた.引き続き Autify を試していく!

Autify 紹介記事

Autify を使って「スマホレイアウト」をレコーディングする

先週に続き「E2E テスト自動化プラットフォーム Autify」を試す.今回は「スマホレイアウト」をレコーディングする.Autify の基本的な操作などは以下の記事を読んでもらえればと!

kakakakakku.hatenablog.com

「スマホレイアウト」をレコーディングする

今回も kakakakakku blog を題材とし,スマホを使って画面遷移をするシナリオをレコーディングする.以下のステップを試す.

  1. 「kakakakakku blog」にアクセスする
  2. キーワード「github」で記事を検索する
    • ✅ URL を検証する : https://kakakakakku.hatenablog.com/search?q=github
  3. 「プロフィール」をクリックする
    • ✅ アカウント名を検証する : id:kakku22
  4. 「ブログタイトル」をクリックする

1.「シナリオ」を作る

まず「シナリオ」を作る.現在 Autify に「スマホに特化したレコーディング機能」はなく,前回と同じようにシナリオを作る.シナリオ名は「スマホ : kakakakakku blog 画面遷移 + 検証」とする.ウィンドウサイズは 1280x1024 とする(今回はウィンドウサイズは関係なし).

f:id:kakku22:20200501220707p:plain

レコーディングを開始し,Chrome の「シークレットウィンドウ」を起動したら,まず Chrome DevTools の「Device Mode 機能」を使ってスマホレイアウトに変更する.今回は「iPhone X」とした.あとはステップを進めていく.

f:id:kakku22:20200501220726p:plain

2.「シナリオ」を確認する

レコーディング結果を確認すると,正しくスマホレイアウトになっている.

f:id:kakku22:20200501220741p:plain

3.「テストプラン」を作成する

今回は「Chrome で今すぐ実行」を使わずに「テストプラン」を作成する.今回はテストプラン名を「iPhone 実行」とし,以下の設定をした.

  • 実行環境
    • iPhone 6/7/8 (Emulator)
    • iPhone X (Emulator)
  • シナリオ
    • スマホ : kakakakakku blog 画面遷移 + 検証

f:id:kakku22:20200501220759p:plain

実行環境は,例えば iPhone と iPad なら「計5種類」からエミュレーターを選択できる.エミュレーターではなく実機を希望する場合は Autify の Pro プランなどを検討する.契約次第と言える.

f:id:kakku22:20200501220819p:plain

4.「シナリオ」を実行する

「テストプラン」から「シナリオ」を実行する.「テスト結果」を確認すると,正しく実行されている.

f:id:kakku22:20200501220837p:plain

Autify FAQs

intercom.help

まとめ

E2E テストでは,デバイスのバリエーションを増やすことにより,サービスの品質を高めることができる.Autify では「テストプラン」で実行環境を複数選択することで実現できる.現状だと「スマホに特化したレコーディング機能」がなく,Chrome DevTools の「Device Mode 機能」を使う必要はあるけど,今後に期待かなと!

Autify 紹介記事

「iPad mini 4 + Elemiya タッチペン + Jamboard」で実現するデジタルホワイトボード環境

最近「リモート研修」や「リモート勉強会」も多く「デジタルホワイトボード環境」を作る必要があった.既にペンタブレット(GAOMON 製 と Parblo 製)を比較のために購入したけど,在庫がなく5月末発送になるため,暫定対応(できる限り安く)を考えていた.

「iPad + Apple Pencil」の組み合わせは評判が良く,試したかったけど,残念ながら使っているのは iPad mini 4 で Apple Pencil に対応していなかった.今回は Amazon で「Elemiya タッチペン(正式な製品名はわからない)」を購入した.現時点だと「2950円」で買えるし,在庫もある.実際に使ってみて,ホワイトボード用途であれば問題なく使えるため,紹介する.

Elemiya タッチペン

「銅製極細ペン先(メモ用途)」と「導電繊維ペン先(ゲーム用途)」があり,ホワイトボード用途だとほとんど「銅製極細ペン先」を使っている.非常に軽くスラスラ描ける.充電は Micro USB で行なう.

f:id:kakku22:20200503161725j:plain

Jamboard

「デジタルホワイトボード」として使えるサービスは複数あるけど,個人的には Jamboard を1番使っている.ザッと以下のような機能があり,とても便利!複数デバイスから同時接続をしても,レイテンシはそこまで気にならないと思う.

  • 無料
  • Web / iOS / Android 対応
  • アクセス制限
    • 非公開
    • 限定公開
    • 一般公開
  • 複数フレーム対応
  • ペン / マーカー / 蛍光ペン / ブラシ
  • 付箋
  • 画像
  • AutoDraw(AI を使った物体認識のような機能)

iPad mini 4 + Elemiya タッチペン + Jamboard

雰囲気を伝えるために「iPad mini 4 + Elemiya タッチペン + Jamboard」で描いてみた.

1. 構成図のようなもの

個人的に文字をキレイに描くのは難しく,少し揺れてしまうけど,そこそこ複雑な構成図もスラスラと描ける.以下はサンプルとして Docker コマンドの構成図を描いてみた.基本的には「マーカー」と「蛍光ペン」を使う.「ペン」はちょっと細すぎる.

f:id:kakku22:20200503160943p:plain

2. イラストのようなもの

簡単なイラストも描いてみた.そもそも絵が苦手ではあるけど,雰囲気は伝わると思う💦

f:id:kakku22:20200503160958p:plain

気になる点

iPad で Jamboard を使うと「元に戻す/やり直し」が右下にあり,右利きだと描きながら押してしまう.ツライ!

f:id:kakku22:20200503161015j:plain

まとめ

「デジタルホワイトボード環境」を作るために「Elemiya タッチペン」を購入した.Apple Pencil に対応していない iPad mini 4 を活用できるし,Jamboard と組み合わせれば,ホワイトボード用途として問題なく使えた.値段も安いし,1本持っておいても良いかと!

E2E テスト自動化プラットフォーム「Autify」を使ってシナリオをレコーディングする

2019年10月に正式リリースとなった「E2E テスト自動化プラットフォーム Autify」を試す.今回は Autify の CTO 松浦さん (@dblmkt) に期間限定の検証アカウントを作っていただいた.ありがとうございます!

autify.com

今まで Selenium や Capybara (Poltergeist) を使った E2E (End to End) テストの導入経験はあるし,最近だと Cypress や Puppeteer を使う機会もある.とは言え,技術選択よりも「E2E テストを継続的にメンテナンスすること」に対して課題を感じる.仮説検証を繰り返すためにリリース頻度を上げていくと,あっという間に E2E テストも落ちてしまう.適当に XPath を修正したり,修正を諦めた経験もある.

今回紹介する「Autify」を使うと AI にシナリオのメンテナンスを任せられる.Alchemist Accelerator Demo Day のピッチを観ると「Autify の価値と熱狂」を感じられる.Autify を試す前に見ておくと良いかと!

vimeo.com

準備

まず,Chrome 拡張「Autify Recorder」をインストールしておく.さらに設定から「シークレットモードでの実行」を許可しておく.

chrome.google.com

1. Autify : レコーディング

Autify の雰囲気を把握するために,kakakakakku blog の画面遷移をするシナリオをレコーディングする.以下のステップを試す.

  1. 「kakakakakku blog」にアクセスする
  2. 「最新記事(1記事目)」をクリックする
  3. 「Envoy」カテゴリをクリックする
  4. アーカイブから「2019年」をクリックする
  5. 「GraphQL Pokémon」の記事をクリックする
  6. キーワード「github」で記事を検索する
  7. ページネーションから「次のページ」をクリックする
  8. 「ブログタイトル」をクリックする

Autify の UI は定期的に変わる可能性もあるからリリースノートを見ておくと良さそう.今回は 4/22 リリースを前提にスクリーンショットを取得した.

docs.autify.com

1-1.「シナリオ」を作る

最初に「シナリオ」を作る.サイドメニューから「シナリオ」をクリックして,右上にある「新規シナリオ」をクリックする.

f:id:kakku22:20200429115123p:plain

次に「シナリオタイトル」と「ウィンドウサイズ」と「開始 URL」を入力する.今回は以下の値とする.

  • シナリオタイトル : kakakakakku blog 画面遷移
  • ウィンドウサイズ : 1280x1024
  • 開始 URL : https://kakakakakku.hatenablog.com/

f:id:kakku22:20200429115138p:plain

「レコーディングを開始」をクリックすると,自動的に Chrome の「シークレットウィンドウ」が起動する.右下に Chrome 拡張「Autify Recorder」が起動していることも確認できる.あとはステップを進めていく.完了したら「保存」をクリックする.

  • 赤丸 🔴 : 点滅中はレコーディング中を意味する
  • チェック ✅ : 検証を追加する
  • 矢印 ↪️ : ページ遷移を追加する

f:id:kakku22:20200429115153p:plain

1-2.「シナリオ」を確認する

レコーディング結果は Autify で確認できる.修正もできるため,誤クリックをしても消せる安心感がある.事前に考えたステップをレコーディングできていた.

f:id:kakku22:20200429115223p:plain

1-3.「シナリオ」を実行する

シナリオ画面の右上にある「Chrome で今すぐ実行」をクリックする.実行が終わり,サイドメニューから「テスト結果」をクリックすると,正常実行されたシナリオを確認できる.

f:id:kakku22:20200429115241p:plain

フェーズごとに画面比較もできる.これは便利!

f:id:kakku22:20200429115256p:plain

2. Autify : 画面遷移 + 検証

E2E テストでは,画面を検証するコードを実装する.今度は先ほどと同じシナリオに検証を追加していく.Aufity ではシナリオを「複製」する機能もあるけど,今回はもう1度レコーディングした.

  1. 「kakakakakku blog」にアクセスする
  2. 「最新記事(1記事目)」をクリックする
  3. 「Envoy」カテゴリをクリックする
    • ✅ URL を検証する : https://kakakakakku.hatenablog.com/archive/category/Envoy
    • ✅ カテゴリ名を検証する : Envoy
  4. アーカイブから「2019年」をクリックする
    • ✅ タイトルを検証する : 2019-01-01から1年間の記事一覧 - kakakakakku blog
  5. 「GraphQL Pokémon」の記事をクリックする
  6. キーワード「github」で記事を検索する
    • ✅ 要素を検証する : 次のページ
  7. ページネーションから「次のページ」をクリックする
  8. 「ブログタイトル」をクリックする

2-1.「ページ情報」を検証する

レコーディングをしながら検証を追加していく.まず「ページ情報」に関する検証は以下の「計5種類」から選択できる.今回は 「Envoy」 カテゴリをクリックした直後の URL を検証するため「URL が ○○ であることを確認する」を使う.

  • ページに指定の要素が存在することを確認する
  • ページが ○○ を含まないことを確認する
  • タイトルが ○○ であることを確認する
  • URL が ○○ であることを確認する
  • URL が ○○ を含むことを確認する

f:id:kakku22:20200429115317p:plain

2-2.「要素」を検証する

次に「要素」に関する検証は以下の「計4種類」から選択できる.今回はカテゴリ名を検証するため「対象のテキストが ○○ であることを確認する」を使う.なお,要素を選択する体験は Chrome DevTools と同じくマウスホバーを使う.

  • 対象が表示されていることを確認する
  • 対象のテキストが ○○ であることを確認する
  • 対象のテキストが ○○ を含むことを確認する
  • 対象のテキストが ○○ を含まないことを確認する

f:id:kakku22:20200429115336p:plain

2-3.「シナリオ」を確認する

レコーディング結果は検証も含めて Autify で確認できる.

f:id:kakku22:20200429115353p:plain

3. Autify : 画面遷移 + 検証(エラー)

最後は「検証時にエラーが発生する場合」を確認する.

3-1.「シナリオ」を修正する

2個目に作ったシナリオ「kakakakakku blog 画面遷移 + 検証」を複製して,URL 検証の期待値を /category/Envoy ではなく /category/Envoyy とした.意図的にエラーを発生させる.

f:id:kakku22:20200429115410p:plain

3-2.「シナリオ」を実行する

同じように「Chrome で今すぐ実行」をクリックする.実行が終わり,サイドメニューから「テスト結果」をクリックすると,エラーを確認できる.ちゃんと「期待値」と「結果」を確認できるため,問題判別も素早くできそう.

f:id:kakku22:20200429115427p:plain

まとめ

今回は Autify の雰囲気を把握するために,kakakakakku blog の画面遷移をするシナリオをレコーディングしてみた.レコーディングは簡単だし,シナリオを修正することもできた.XPath をゴニョゴニョする必要もなく,非エンジニアもシナリオが作れる点もメリットに感じた.まだまだ Autify の機能はあるため,引き続き試していく!

git diff の結果を HTML に変換する「diff2html-cli」

最近 git diff の結果を GitHub プルリクエストのようなインタフェース (HTML) に変換する必要があった.既にツールがあるだろうと思って調べたところ「diff2html-cli」を使えば git diff の結果を HTML に変換できるとわかった.今回は diff2html-cli を紹介する.

github.com

インストール

diff2html-cli は npm で簡単にインストールできる.今回は最新版 の v5.1.0 を使う.コマンドは diff2html となる.

$ npm install -g diff2html-cli

$ diff2html --version
5.1.0

今回はサンプルとして,GitHub リポジトリ redash-hands-on の v7.0.0 リリース (Tags) と v8.0.0 リリース (Tags) の差分を使う.

github.com

diff2html-cli を試す

まず,以下のように git diff の結果(標準出力)を diff2html コマンドと --input stdin オプションにパイプする.すると GitHub プルリクエストのような HTML に変換できる.便利!

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin

f:id:kakku22:20200427121105p:plain

スプリットモードにする

diff2html のデフォルトスタイルは line(GitHub だと Unified)となる.--style オプションを使って side(GitHub だと Split)を指定すると,GitHub で個人的によく使う「左右比較スタイル」になる.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --style side

f:id:kakku22:20200427121121p:plain

Files changed を初期表示する

他にも --summary open オプションを使うと,デフォルトで閉じている「Files changed」を初期表示できるようになる.GitHub プルリクエストの画面だと「Jump to...」をクリックすると表示される.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --summary open

f:id:kakku22:20200427121137p:plain

書き出す HTML ファイルを指定する

Mac で diff2html を実行すると,デフォルトだと /private/var/folders の下に diff.html を書き出す.--file オプションを使うと,任意の場所を指定して HTML ファイルを書き出せるようになる.以下の例だと,カレントディレクトリに redash.html を書き出す.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --file redash.html

独自フォーマットを使う

デフォルトだと HTML に Diff to HTML by rtfpessoa という不要な文章も含まれてしまう.「diff2html-cli」を個人的に使うなら無視できるけど,HTML を公開するシナリオだと微妙だなと感じた.調べたところ,独自フォーマットを使うためのオプションとして --htmlWrapperTemplate も実装されていた.使うのは簡単で,以下のように事前に用意したテンプレートを指定する.

$ git diff v7.0.0 v8.0.0 | diff2html --input stdin --style line --file redash.html --htmlWrapperTemplate template.html

README.md を読むと,テンプレートに Git 情報を埋め込むプレースホルダを実装すると書いてあった.プレースホルダの例も README.md に載っている.以下にサンプルとして template.html を載せる.<!--diff2html-css--> や //diff2html-highlightCode などをプレースホルダとして埋め込んでいる.

<html>
  <head>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/highlight.js@9.18.1/styles/github.min.css">
    <link rel="stylesheet" href="./template.css">
    <!--diff2html-css-->
    <!--diff2html-js-ui-->
    <script>
      document.addEventListener('DOMContentLoaded', () => {
        const targetElement = document.getElementById('diff');
        const diff2htmlUi = new Diff2HtmlUI(targetElement);
        //diff2html-fileListToggle
        //diff2html-synchronisedScroll
        //diff2html-highlightCode
      });
    </script>
  </head>
  <body>
    <div class="header">
      <h1>kakakakakku/redash-hands-on</h1>
      <img src="./images/logo.png">
    </div>
    <div id="diff">
      <!--diff2html-diff-->
    </div>
  </body>
</html>

センタリングをするサンプル CSS template.css も載せる.

.header {
  text-align: center;
}

img {
  width: 200px;
  text-align: center;
}

diff2html を実行すると,独自フォーマットを使えるようになった.

f:id:kakku22:20200427121155p:plain

まとめ

git diff の結果を GitHub プルリクエストのようなインタフェース (HTML) に変換する場合は diff2html-cli が便利!最近まさに diff2html-cli を使う場面があって導入した.HTML を公開するシナリオだと独自フォーマットを使うと良さそう.

github.com