とあるStartupに勤めるエンジニアの技術ブログ

Salesforce、テスト関係の技術ブログなどを書く予定

CI/CDが好きな奴ちょっと来い

CI selenium React.js

はじめに

2017年2月9日（肉の日）に株式会社チームスピリットで開催されたCI/CD NIGHTに参加＆LTしてきました。CI/CDに関連する話題をLTする勉強会＋懇親会でCIサービスの旬など面白い話題を聴くことができました。

teamspirit.connpass.com

LT発表

発表したLT資料はこちらになります。

www.slideshare.net

掻い摘んで内容を紹介すると、SeleniumでE2Eテストしたいのであれば、idやclassを適切に振ってあげましょう、という話です。
特に、React.jsではDOMを操作する意識をしなくて済むような仕組みになっています。そのため、意識してidやclassを付けてあげないとDOMベースのSeleniumとは相性が悪くなってしまいます。

そこの辛みを緩和するために、React.jsで作ってSeleniumでE2Eテストを自動化しようとしたときに苦労しないように、どこにidやclassを仕込んでおけばテスト自動化しやすくなるかリストを作ってみました。

あまり良い言葉でリストをまとめることができなかったですが、ブラッシュアップしていきたいと思いますので、優しいご意見・ご要望をお待ちしております。

むすび

CI/CDでどれくらい人が集まるのかと思いましたが、思いの外満員御礼でびっくりしました。登壇者について言えば、こんな感じでした。

「CI/CDが得意なフレンズなんだね！すご〜い！」

あと、懇親会ではピザと寿司が出て、美味しくいただきました！

「たのし〜！」

逆転の発想で考える2017新年会

Salesforce

最近、ブログ更新が滞っており、久しぶりの投稿です。
ちなみに、タイトルはホッテントリ―入りを目指して（ない）ホッテントリ―メーカーで作ってみました。
ということで、2017年1月25日に開催されたTokyo Salesforce Developer Group 2017新年会に参加＆LTしてきました。

www.meetup.com

LTでは、昨年末に開催した Advent Calendar をふりかえりました。昨年は3投稿させてもらったのですが、1つはPodcast収録方法で、1つはPodcast配信で…。まぁ、それはいいや。

Salesforce App Cloud Advent Calendar でQiitaのいいねをもっとも集めた投稿(2017年1月25日時点)は、以下の2つでした。

  • UI/UX変更の際に、サービス、ユーザ、実装者という3つの観点で気をつけていること(shokolatedayさん)
  • 開発組織（Developer Edition）をサインアップした後にやることリスト(stomitaさん)

ただし、Qiitaではない外部のブログに記事を投稿してもらったものについては集計できないので、対象外になっています。外部のブログに書いてもらった記事も面白いものがたくさんありました。

LT資料はこちらです。

www.slideshare.net

今年もmigration.fmともどもよろしくお願いします！
一応、新年の抱負としてPodcast配信月一回ペースで、という話をしたので、もう少し頑張っていきたいと思います。
migration.fm

第3回 日本Seleniumユーザコミュニティ勉強会に参加してきた！

selenium

今日は久しぶりの日本Seleniumユーザコミュニティ勉強会の日！

seleniumjp.connpass.com

調べてみたら、前回は2014年10月じゃないですか。ちなみに第2回の勉強会に参加した時のブログ投稿はこちら。
ということで、ヤフー株式会社にお邪魔してきました。

セッション

セッションの振り返りをざっくりと。詳細は後日資料が発表されるはずなので、そちらを確認するということで。

「Seleniumデザインパターン & ベストプラクティス」の勘所

発表者：太田健一郎さん & 玉川紘子さん (SHIFT)

実践 Selenium WebDriver

実践 Selenium WebDriver

「Selenium実践入門」で学ぶテスト自動化の世界

発表者：伊藤望さん (TRIDENT)

  • ずっと手元に置いておきたい一冊
    • ファイルダイアログ、Basic認証、HTTPヘッダ、HTML5 などの細かなノウハウが書かれている
    • ウィンドウ・タブ、ブラウザログ、@FindBy などマイナーな機能が紹介されている
    • CSSセレクタ・XPath、コマンド文法のチートシート
  • Geb、FluentLenium、Capybara が紹介されている
  • サイボウズさん、DeNAさんの事例が紹介されている

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

E2Eテストフレームワークを使用したテスト自動化事例

発表者：太田邦昭さん (ヤフー株式会社)

  • AngularJSを使っている開発でテスト自動化するフレームワーク選定から導入までやった話
  • ヘッドレスブラウザはPhatomJSを導入検討
    • リアルブラウザでは動作するが、PhantomJSでは動作しないことが
      • ヘッドレスブラウザ(PhantomJS)はまだ早かった
    • XVfbでリアルブラウザをヘッドレス化

STFとAppiumをもちいたAndroidアプリの自動テスト

発表者：平田敏之さん (DeNA)

  • Selenium実践入門に書いたときはまだ課題だったが、この発表は解決編だ！
  • STFでデバイス管理ができる
  • ブラウザからしか操作できなかったから、社内のコミッターとAPIを実装したった
  • 次に書籍を書く機会があったら、解決編まで書く
  • STFの開発を手伝ってくれるエンジニア、ハードを収める箱をデザインしてくれるデザイナーを募集中

Azureを使って手軽にブラウザテストをはじめよう

発表者：小島直也さん

  • 爽やかにテストエビデンスをごまかしたことによる悪循環を解説
  • 頑張ってテスト自動化を進めた
    • 自動テストに立ち向かう人がぶち当たるあるある話
  • Azure上にWindowsServer立ち上げて、スクリーンショットを撮るように
  • テストエビデンスを

Gebに実践入門するために

発表者：PoohSunnyさん (株式会社リクルートジョブズ)

  • Geb愛に溢れる発表
  • Gebを知ってる人、思ったより多い
  • Selenium実践入門の特に素晴らしいところ、Gebの章があること！
  • Geb のハードル1：環境構築周り
    • Grade、Groovyの習得が必要
      • Geb の公式サンプルで勉強するのがいい
  • Geb のハードル2：Groovy習得
    • IDEにサポートしてもらう→IntelliJ IDEAだと少し賢くサポートしてくれる
  • 今日の発表資料は公開に時間がかかるので、リンクなどはあとでツイートしておきます

エビデンス取るのも自動化したい！

発表者：桑原雄一さん (Monocrea)

  • 「テストエビデンス撮るの嫌な人、拍手」
    • 会場から大きな拍手がｗww
  • テストエビデンスを撮るためのツールの紹介

Seleniumアンチパターン

発表者：宮田淳平さん (サイボウズ株式会社)

  • 自動化しちゃうおじさん
  • アンチパターン：なんでもSelenium
    • テストケース数が増えてメンテコスト増大→メンテ不能
      • Seleniumを避ける(適切な自動化方法を選択する)
  • アンチパターン：手動テストの代わり
    • 実装期間中のUI変更で放置、そしてメンテ不能に
      • 自動テストを開発プロセスに組み込み、放置しないようにする
      • なので、推進役が必要
  • アンチパターン：クロスブラウザがんばりすぎ
    • ブラウザの組合せで実行すると、毎日どこかで問題が起き、メンテ不能に
      • ブラウザを絞る(Chrome/Firefoxは比較的安定している)
  • アンチパターンの兆候を感じたら、先人の知恵を活かして解決しよう

薄っすい話百八式

発表者：戸田広さん

  • githubinaoのお話
    • rebuild.fmで@naoyaさんが話してたやつ
  • ポート番号にネタが仕込まれている、それも味わい深い
  • CIの結果の通知は、「音声」で
  • 仕事にもユーモアが大事

まとめ

出版された書籍の読みどころの紹介、実際の開発での活用方法から始まり、テストエビデンスにまつわる苦労と解決、事例に基づいた知見などなど盛りだくさんの勉強会で楽しかったです。特に、「自動テストを始めることは開発プロセスを変えること」という視点は、いろいろ考え始めてしまい発表に集中できないほど刺激を受けました。
発表していただいた方々、会場準備・運営していただいた方々、ありがとうございました。

おまけ

なんと、じゃんけん大会に勝ち残り、出版されたばかりの書籍＆ステッカーをいただきました！
技術評論社さん、ありがとうございます！！！

f:id:a-kura:20160206232745j:plain

※SeleniumJPステッカーは会場で配っているのをもらってきました

Lightning Componet でページ遷移する〜LightningRouter の提案〜

Lightning Component のページ遷移の問題点

Lightning Component は「 Single-Page-Application (SPA) を構築できるフレームワークだ！」なんて触れ込みもありましたが、実のところ1ページ内でViewを切り替えるための Router をライブラリに持っていません。
また、ページ内でのView切替するための仕組みもなく、以前紹介し唯一の可能性であった navigateToComponent() もお蔵入りになってしまっています。
 
つまり、Lightning Component のページ遷移を考えたときによい解決策がない状態でした。
 

LightningRouter の提案

 
実は、Winter'16 で aura:locationChange イベントが追加されました。このイベントは、URLのクエリー文字列やハッシュが変更されたタイミングで発火するものです。この機能追加によって、待望の Router 機能を実装できるようになりましたので、Lightning Component を実現する LightningRouter コンポーネントをサンプル実装してみました。
 

サンプル実装

ルーティングを処理するコンポーネントのサンプル実装です。
初期表示するコンポーネント、ルーティング情報を属性として与えられることで、動作するようになっています。ルーティング処理自体は、locationが変化した際に発生するイベントを受け取り、ルーティング情報に従って{v.body}に表示するコンポーネントを切り替えているだけで単純なものです。
 
```xml:src/aura/LightningRouter/LightningRouter.cmp
<aura:component>
  <aura:handler event="aura:locationChange" action="{!c.render}" />
  <aura:handler event="init" action="{!c.render}" />
  <aura:attribute name="init" type="String" access="global" />
  <aura:attribute name="route" type="String" access="global" />
 
  {!v.body}
</aura:component>
```
 
```js:src/aura/LightningRouter/LightningRouterController.js
({
  render : function (component, event, helper) {
    var token = event.getParam("token");
    var querystring = event.getParam("querystring");
 
    var route = JSON.parse(component.get("v.route"));
    if($A.util.isUndefined(token)) {
      token = component.get("v.init");
    }
    var cmpName = route[token];
 
    $A.createComponent(
      "c:" + cmpName,
      {
        "aura:Id": cmpName,
      },
      function(newCmp){
        if (component.isValid()) {
          var body = component.get("v.body");
          body.pop();
          body.push(newCmp);
          component.set("v.body", body);
        }
      }
    );
  }
})
```
 

利用方法

下記のように呼び出します。init 属性には初期表示する Lightning Component、route 属性には、ハッシュとそのハッシュがセットされた場合に表示する Lightning Component をJSON(連想配列)で記述します。
 
```xml:src/aura/LightningRouterApp/LightningRouterApp.app
<aura:application>
    <c:LightningRouter
        init="Sample1"
        route='{
            "Sample1" : "Sample1Cmp",
            "Sample2" : "Sample2Cmp"
        }'
    />
</aura:application>
```
 
あとは、ページとして表示する Lightning Component を用意し、下記のようにアンカータグでハッシュを呼び出せば、表示する Lightning Component を切り替えてページ遷移します。
 
```xml:src/aura/Sample1Cmp/Sample1Cmp.cmp
<aura:component>
  <div>
    Hello, Sample1!
    <a href="#Sample2">Sample2</a>
  </div>
</aura:component>
```
 
```xml:src/aura/Sample2Cmp/Sample2Cmp.cmp
<aura:component>
  <div>
    Hello, Sample2!
    <a href="#Sample1">Sample1</a>
  </div>
</aura:component>
```
 

GitHubリポジトリ

サンプルソースコードについては、ここで公開しています。
 

おわりに

以上のように、 Winter'16 で追加になったイベントを用いて、これまで Lightning Component になかった Router機能を実装しました。
今回実装したものは、単純に Lightning Component を切り替えるシンプルな実装となっています。
 
実際に製品開発などで利用する場合は、Salesforce1で動作するように修正する、ページ遷移時のアニメーションを追加する、など必要に応じて拡張していく必要があります。
 

SlackにTokyo Salesforce Developer GroupのTeamを作ってみた

Salesforce slack heroku

毎年のようにサービス名が変わって毎年新鮮な気持ちで Advent Calendar に挑める今年も大盛り上がりの Salesforce App Cloud Advent Calendar 2015 ですが、1日埋まっていない日があるので代打しようとキーボードを叩いています。
とはいえ、Winter'16のアップデートを見てもLightning Componentの機能拡充も少なく諸先輩方の素晴らしい投稿がたくさんあり、なかなかネタが…。

じゃぁ、どうする？

そこで、Slackの登場です。
会社勤めをしているとなかなかFacebookアカウントを取りにくい人もいたりします。そんな方も気軽に参加して雑談できるスペースになればいいなぁ、という空想で自分を励ましながらSalesforce DUG JapanTokyo Salesforce Developer Groupのチームを作ってみました。

tokyosalesforcedg.slack.com

salesforcedugjapanはすでに使われていたけど、誰だろう…。

招待してもらわないと参加できないよね？

そんな声もあろうかと、Invite用のWebページも用意しました！
（但し、テストしていません！）

slackin-tokyosalesforcedg.herokuapp.com

URLからも分かるようにHerokuで動いています。なんとHeroku Buttonのおかげで調査から設置まで30分もあればできてしまいました(参照：参考文献)。Heroku、すごいですねぇ。もちろんFreeプランなので無料！

よって、30分すると寝ます！
一回アクセスすると起きてくるはずなので、少し間をとって再度アクセスしてもらえばInvite用のWebページが表示されるはずです。

ところで、何を話すの？

Slackでぶっちゃけ何をやるか決まっておりません。
Facebookページよりは話しやすい場になると思いますので、例えばリリースノートの感想を書き込んで雑談したり、テーマを決めて雑談したり、できればと考えております。

以上、Salesforce App Cloud Advent Calendar 2015 の12月20日分の代打投稿でした。

参考文献

qiita.com

Lightning Event は3度死ぬ

Lightning Salesforce

Lightning Event とは

Lightning Event とは、Lightning Component において、コンポーネント間でイベント処理を実行するための仕組みです。Lightning Event では、イベントを定義する、イベントを発火するコンポーネントに定義を記述する、イベントを受け取り処理するコンポーネントに定義を記述する、の3ステップが必要となります。

First Impact

問題点

それは、Lightning Component をまともにコンポーネント分割してコンポーネント間のイベント処理を Lightning Event で行おうとしたときに訪れます。
Lightning Event も Lightning Component などと同様にバンドルという単位で扱います。このバンドルにイベントの定義だけを記述します。問題はこのバンドルがすべて1階層内で管理されるため、まともにコンポーネントを分割し、イベント処理を書いていくとものすごい数のバンドルが作成されることになり、管理不能になっていきます。

対応策

対応策としては、下記の2つが考えられます。

  • まとめにコンポーネントを分割しない
  • Lightning Component はあくまでも外側とのI/Fの定義に徹して、内部は別ライブラリ(React.jsなど)を利用する

前者はコンポーネント志向を捨てることになるので、後者のほうが優れたやり方ではあります。ただし、モダンJavaScriptのスキルが必要となるので、JavaScriptが得意ではないエンジニアがいきなり採用するには少しハードルがあります。トレンドは、モダンJavaScriptを利用して開発する流れとなっているので、頑張って覚えていってもよいかもしれません。

Second Impact

問題点

それは、別のパッケージにある Lightning Component を Lightning Event で連携しようとしたときに訪れます。
Lightning Event は型付け言語に相応しく、ソースコード中にある場合は定義を参照してバリデーションしており、定義が見つからない場合はソースコードをSalesforce組織にデプロイすることができません。

そのため、他のパッケージ中にあるコンポーネントを参照すると、自動的に基本パッケージと拡張パッケージというような主従の関係となってしまいます。これは、 Lightning Event でも同様に機能しますので、他のパッケージの Lightning Event を呼び出すパッケージを作ろうとすると、呼び出し元のパッケージに依存するようになってしまい、単独ではインストールすることができなくなってしまいます。

対応策

対応策としては、Lightning Event を利用する場合は、直接的なイベントのワイヤリングを諦めるしかありません。それぞれのパッケージでは別々に Lightning Event を発火・受け付ける処理を作成し、2つのパッケージのコンポーネント間のイベントを受け渡すワイヤリング用のコンポーネントを作成することでやりたいことができるようになります。

自動的にイベントをワイヤリングできなくなってしまうところですが、このワイヤリングコンポーネントを2つのパッケージの拡張パッケージとして作成してやることで、コーディングする必要はなくなります。
2つのパッケージにある Lightning Component を Lightning App Builder で配置し、合わせてワイヤリングコンポーネントを配置してやることでイベントの受け渡しを実現できます。

Third Impact

もうすぐ ltng:sendMessage イベントが実装されるようです。
このイベントを利用すると、新しいイベントを定義せずに ltng:sendMessage イベントでメッセージ(JSON形式)をチャンネルを指定してイベント発火し、 で受け取りハンドルして対応する処理を記述できるようになるようです。これによって、ひとつ目、ふたつ目の問題点を回避できそうです。

ところが…

おぅ…。
希望の光と思われた ltng:sendMessage も解ではないと…。
問題として認識されて、解決に向けて対応中とのことなので、もう少し様子を見ましょう…。


Enjoy Lightning!