LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

自動システムテストツール「Bucky」OSS化までの道のり

こんにちは!LIFULLのSoftware Engineer in Testグループ(通称:SETグループ)のヒキモチです。

我々SETグループは先日、自動システムテストツール「Bucky」のOSS化を行いました!

f:id:LIFULL-hikimocr:20190829122315j:plain

github.com

github.com

Buckyは元々社内の自動テストツールとして使われていたものなので、 それをOSSとして公開するためには色々と苦労がありました。

この記事ではその苦労やそこで得た知見などを共有できたらと思います。

目次

そもそもなぜOSS化するのか

「LIFULLエンジニアの認知度の向上のため」

サービスとしての「LIFULL HOME'S」の認知はされていますが、 それを作っているエンジニアの認知度はまだまだ低いと感じています。 オープンソースとして公開することでLIFULL全体のエンジニアの認知度の向上に繋がればよいなと思っています。

「使ってほしい」

単純に自分たちの作ったものを使ってほしいと思っています。 自分たちが日々使っていて便利だと感じているからこそ、 世の中の人達にも使ってほしいという思いがあります。

「外からのフィードバックを受けることで、より使いやすいものに進化させたい」

公開はしましたが、まだまだ使いにくい部分はあります。 Buckyをよりよいものにするために、外部からの意見を積極的に取り入れたいと思っています。 Issues、Pull requests待っています。

OSS化までの道のり

1. リファクタリング

会社の冠をつけて公開するのでソースコードはある程度きれいにしておく必要がありました。 静的解析はRubocopとCodeClimateを連携させて行いました。

  1. Code ClimateとGitHubを連携し、コード解析・テストカバレッジの測定を行う。
  2. GitHub issue連携機能を使い、Code ClimateからGitHub issueを作成。
  3. SETGメンバーが分担してリファクタリング。
  4. ローカルでの確認はCode Climate CLIを用いる。

CodeClimateを使うことで、指摘事項のGitHub issue管理が容易になり作業効率が上がりました。

またmaintainabilityやtest coverageとして評価が可視化されるので、リファクタリングのモチベーション向上にも繋がりました。

f:id:LIFULL-hikimocr:20190513122938p:plain
A~Eで評価が行われる

f:id:LIFULL-hikimocr:20190513124546p:plain
maintainabilityの推移

f:id:LIFULL-hikimocr:20190516162629p:plain
バッジもいい感じになりました

codeclimate.com

2. システムテスト導入

品質向上のため、システムテストを導入することにしました。 ユニットテストでは担保できない、buckyコマンドやテスト実行の動作を保証するためです。

テストフレームワーク「Bats」を使い、bashの終了ステータスやコンソール出力を期待値として扱うことで実現しました。

github.com

仕組みは以下のとおりです。

1.GitHubへのpushをトリガーにCircleCI上に以下のコンテナを立ち上げる

f:id:LIFULL-hikimocr:20190829122400j:plain  ・テスト実行対象コンテナ(nginx)

 ・selenium-standaloneコンテナ

 ・テスト実行コンテナ(bucky)

2.Batsにより、buckyコマンドを実行しnginxコンテナ内のサンプルページに対してテストを実行し、正常な動作が行われるかどうかを検証する

システムテスト周りはこちらに実装してあります。

3. RubyGems.orgへの登録

パッケージとして扱えたほうが便利なので、 GitHubへの公開と同時にRubyGems.orgへの登録も行いました。

bucky-core | RubyGems.org | your community gem host

公開後のお話

使い手のことを考えられていなかった

公開したは良いものの、実際に使うためのドキュメントが整備されていませんでした。

具体的には以下の問題がありました。

問題
  1. READMEを見てもgem install後に何をすればいいかわからない

    当時のREADMEのUsageに従ってもテストを実行することはできませんでした。

  2. Bucky-managementをどのように利用すればいいのかわからない

    テスト実装・実行はBucky-coreの機能ですが、テストレポートはBucky-managementの機能です。

    READMEを見てもどのように連携して利用すればよいかわからない状態でした。

解決策1:ハンズオン資料を作成
解決策2:READMEの構成を変更

Setupを追加しました。

Setupにはインストールしてからテストコードを実装する手順を記載し、Usageにはテスト実行手順を記載しました。

Before

- Bucky-Core
    - Overview
    - Feature
        - Set connection infomation for database
    - Usage
        - Install
        - Run test
        - Implemente test code
~省略~

After

- Bucky-Core
    - Overview
    - Feature
    - Setup
        - Install
        - Implement test code
        - Set connecting information for database
    - Usage
        - Run test
        - Rerun test
~省略~

ruby version

gemspecにrequied_ruby_versionの指定をしていなかったため、 公開時は必要rubyバージョンが1.0.0以上となっていました。 慌てて修正を行いました。

gem release 自動化

RubyGemsへのリリースも自動化しています。

GitHub上でreleaseタグを作成するとそれをトリガーに以下の処理が行われます。

  1. バージョンファイルの書き換え
  2. masterブランチへpush
  3. gemのパッケージ化
  4. RubyGemsへリリース

詳しくは以下の記事をご覧ください。

RubyGemsリリースを自動化した話 - Qiita

最後に

開発者以外もyaml記法さえ知っていれば簡単にテストコードが書けるようになっていますので、 ぜひ使ってみてください。

詳しい使い方はGitHubリポジトリのREADMEもしくはhands-onを参照ください。

まだまだ改善すべきところはあると思っているので、 我々も開発していきますし、issue、PullRequestもお待ちしてます。