Timers Tech Blog

カップル専用アプリ「Pairy」, 子育て夫婦アプリ「Famm」を運営している Timers inc. の公式Tech Blogです。

テストフレームワーク Codeception にプチコミットした話

みなさん、こんにちは。サーバエンジニアの長南です。

今回は業務でオープンソースのソフトウェアを使っていくなかで、ささいな恩返しをした体験を紹介したいと思います。

そういえば、みなさんテストコード書いていますか?

Timers のサーバーサイドのコードにはテストプラットホームとして、Codeception を使っています。テストコードを書くことがどれだけ大切なのかというのは、Timers Tech Blog でも過去に「テストに投資した時間が、チームにどのような利益をもたらすか?」という記事で紹介いたしました。

techblog.timers-inc.com

もちろん日々の開発の中ではテストコードも書いて、CI環境にも取り入れてコードの品質を高める努力を継続的に行っています。

そんなある日に事件が起こりました。

あれ、何かおかしいぞ

そのとき私は少し込み入ったケースを想定したテストコードを書くために、共用の環境を使ってテストコードを書いていたのですが、

「Redisの内容が消えているけれども誰か何かやった?」

という声が聞こえてきました。私はテストコードを必死にいじっていたので多分違うだろうなと思っていたのですが、関係者の話を総合してみるとどうやら私が犯人のようです。その証拠に Redis モニタを起動しているところで私が書いていたテストを実行すると、執拗かつ鮮やかに flushdb が実行されているではありませんか!!

調べてみると、Codeception の Redis モジュールでのデフォルト設定が「テスト毎に Redis データベースを初期化する」挙動となっているのが原因と分かりました。設定ファイルに「データベースを初期化しない」旨の設定を入れてみたら、テスト毎に flushdb される挙動はなくなりました。

これで一件落着、やれやれといいたいところですが、それで本当に良いのでしょうか?

あなたが踏んだ罠は、他の誰かも必ず踏む

Timers の中の話であればここまでで問題解決といえるかもしれませんが、この罠は他の誰かも踏んでしまいそうです( もちろん「他の誰か」というのは未来の自分である確率が高いのですが... )。そして設定を書いていないデフォルト状態で Redis の内容が消されるというのは初心者にはきびしいところがあります。

Codeception は MIT ライセンスのオープンソースなテストフレームワークなので、デフォルトの挙動を変えた方がよいなと感じて Codeception 側のコードを変更してもらおうと考えました。オープンソースのプロジェクトでは貢献の方法がそれぞれ違って手順を誤ると見てくれないのですが、Codeception の場合は「小さな変更なら直接 Pull Request 出しても良い」ということだったので、私の貧弱な英語でこんな Pull Request を作ってみました。

github.com

まあ、とりあえず開発陣に伝わればというくらいで気長にかまえていたのですが、予想に反して迅速に対応していただき、次のリリースの Codeception 2.3.0 に反映されることになりました。

オープンソースの恩恵に恩返しを

今回は本当に些細なところの修正ですが、それでも日頃使っているソフトウェアが良くなることは嬉しいものです。むりやり貢献をするためにヘンな努力をするのは本末転倒な気がしますが、今回のような自然な流れで日頃使っているオープンソースのソフトウェアに貢献できる環境は私達が想像した以上に大切なのだなと感じました。

積極採用中!!

子育て家族アプリFamm、カップル専用アプリPairyを運営するTimers inc.では、現在エンジニアを積極採用中! 急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください! 採用HP : http://timers-inc.com/engineerings