ラクスルでSymfony Meetup#13「テスト座談会」を開催しました

エンジニアの岡田です。

ラクスルに入社して1年半ほどですが、完全に古株になりつつあります。

さて、先日弊社で勉強会を開催したのでご紹介したいと思います。

ラクスルでSymfony Meetup #13 を開催しました

DSC00720

イベントページ
https://symfony.doorkeeper.jp/events/47980

もうひと月前の話になりますが、ラクスルにて 日本Symofnyユーザー会主催の勉強会「Symfony meetup #13」の会場提供をさせていただきました。

ラクスルでもWEBアプリケーション・フレームワークであるSymfonyを利用しており、そういった経緯もあり今回会場提供させていただく運びとなりました。

ラクスルでは、今後積極的に勉強会の開催やMeetupの開催を考えており、もし技術系の勉強会やイベントを開催したい、合同勉強会をやってみたいという話があればお気軽にご連絡ください。会場提供いたします。

言語やテーマはなんでも構いません。

本題

Symfony Meetup #13 では「Symfonyにおけるテスト」をテーマとして、座談会を行いました。

前半: テスト座談会

DSC00768

ラクスルにおいてもテストを書いていくということは課題で、今回の開催は非常に楽しみにしておりました。

話を聞いているとテストに関しては各社、色々な状況で頭を悩ませているようでした。

* テストコード書けてません。もしくはテストを書く文化が根づいてませんといった方
* テスト書いてるけどどういうテストを書けばいいのか知りたいという方
* E2Eやjsのテストについて話したいという方

とそれぞれ現場のレベル感はまちまちでした。

ですので、似たような課題について話したいグループに分かれてディスカッションを行い、最後に全体発表して共有するという形式で進めていました。

普段あまりテストコード書けてないグループ

私がこちらのグループのファシリテーションを努めましたのですが、このグループからは下記のような話が挙がりました。

* どうやって導入すればいいのか?
* メリットはなんですか
* 他のエンジニアにも書いてもらえてますか?
* テストを書く文化をどう作るか
* 何のテストコードかけばいいですか?

導入といった課題に対しては、

* 他の人も書けるように布教する
* カバレッジを明確に目標に入れているといった会社
* 明確に個人の成果目標(給料に響く)といったアグレッシブな会社まで…

テストを根付かせる戦略だけみても色々なアプローチがあるのだなと改めて思いました。

また、何のテストを書けばいいのか、というところでは

* ビジネスインパクトの大きい部分(課金とか)
* 変更箇所が多いところ
* 時間のテストなど、ブラウザテストしにくいところ

という話がありました。

普段からテストコード書けているグループ

* どんなテストがいいか?
* テストの粒度どうしてる?
* 何をテストするのか
* ブラウザテストどうしてるのか
* テストの費用対効果ってどう?
* jsのテストどうしてる?

といった話が上がっていたようです。

どのグループでもよく出てた話題として「何をテストしたらよいのか?」というのがありました。

これについては、「不安をテストする」といのが挙がりました。

* テストは不安を克服するツールである
* 課金部分などビジネス的にクリティカルなものをテストしよう

というのは納得感が得られたのではないかと思います。

開発効率のためにテストする

また、もう1点「テストコードでないとテスト(再現)しづらいものについて書いた方が効率がいい」という話がありました。
(私の意見です)

例として
* 時間に依存したコード
* ブラウザテストするにはデータを用意するのが大変なもの(メールの送信テストなど)
* 例外系(例えば外部通信の失敗)のハンドリング

「普通にはテストしづらい問題であったり、ブラウザテストだと全パターン実行するのに時間がかリ過ぎてしまうもの等、に対してはテスト書いたほうが開発効率がいいよねと」いうお話だったのですが、わりと受け入れられたように感じました。

1時間ほどの座談会で少し話し足りない感じもしましたが、色々と意見交換ができたようで良かったように思います。

後半: LT(ライトニングトーク)

テストことはじめ

トップバッター @hanahiro_aze さん

スクリーンショット 2016-09-01 16.15.03
https://speakerdeck.com/hanahiroaze/tesutokotohazime

* テストが必要な理由(継続的デリバリーより抜粋)
* なぜテストが書けないのという考察
* 実際にテスト書いてみて体感したメリット

などが紹介されており、非常に良い資料だと思いました。

AJAXなサイトをスクレイピングしてみた

@k_nakahashi さん

残念ながらスライドを見つけることができませんでした・・・

goutte というPHPのスクレイピングライブラリを使って苦労された話をされていました。

単純なHTMLのサイトでない場合は、ブラウザベースのcasperjsのようなブラウザベースの
スクレイピングツールのほうが向いてそうですね。

ファンクショナルテストでメモリと時間を削減した話

@kalibora さん

残念ながらスライドを見つけることができませんでした・・・

SymfonyでFunctionalテスト書いていて memory leakに遭遇した時にした対処方に関するお話

* 実務における知見が共有されるというのはいいですね。

SymfonyでFormとEntityのインピーダンスミスマッチを解消する

@nunulk さん

スクリーンショット 2016-09-01 16.21.56

http://qiita.com/nunulk/items/37586890572217cd5fe3

SymfonyでFormを利用したいけれど、FormView と Entityがマッチしない場合にどうするかというお話。

どんなFWを使っているもよくあるお話で、非常にためになるお話でした。
私も Form\Model というForm用のDataObject的なものはよく作ります。

fluent-plugin-monologをrubygems.orgに公開しました

@imunew さん

http://qiita.com/imunew/items/fe6057692a73d1fdbea3

Symfonyでも採用されているMonologというLoggingライブラリーをfluentdで収集できるようにpluginを公開されたのですが、その際にハマったことなど共有されていました。

一度公開するとアップデートするしかないそうで、bugfixしていたらどんどんバージョンが上がってしまったようです。

レガシーコードのテストを書いていくテクニック

@okapon_pon (私です)

http://qiita.com/okapon_pon/items/056c65a69cc5fa182fde

一部の方から話を聞いてみたいというお話があったので即興で書き起こしました(笑)

普段の業務にて得られた知見をご紹介いたしました。
classベースのコードであれば、だいたいの物はこれでクリアできると思います。

以上、6名のLTでした

まとめ

* テストに関しては各社色々課題を抱えているところは多い
* メリットを理解し、取り組むのが吉
* ディスカッション形式で色々意見交換できる場はいいですね

P.S. 勉強会後にオフィス見学会もしてました

Cm_iLKeUcAAANiC

DSC00820

最後に

もう一度書きますが、もし技術系の勉強会やイベントを開催したい、合同勉強会をしてみたいという話があればお気軽にご連絡ください。
言語もテーマもなんでも構いません。

またエンジニアも積極採用中です!!