あなたのコードに ハナマルを。- 〜 ぼっち開発でも出来る
プラグインテスト初めの一歩(仮) -

0 %
100 %
Information about あなたのコードに ハナマルを。- 〜 ぼっち開発でも出来る
プラグインテスト初めの一歩(仮) -

Published on November 26, 2016

Author: akiko_pusu

Source: slideshare.net

1. あなたのコードに ハナマルを。 〜 ぼっち開発でも出来る
 プラグインテスト初めの一歩(仮) 2016.11.26 redmine.tokyo 第11回勉強会
 たかの あきこ (@akiko_pusu)

2. さいきん目撃したTWEET画像。 あわわわわ…… 拙い事例ですが、 Redmineの普及を願っておはなしします。

3. たかのあきこ @akiko_pusu おはなしするひと。 20代後半 (16進ってことで) エンジニア35歳説なにそれ? 産休まえにRedmineと出会う Redmine.tokyo ロゴ描きました 趣味でプラグイン書いてます 色々あって渋谷で働いてます ココナラって会社です! ごめんなさい今回は時間なくて
 イラストなしです >< 自己紹介はさっくりと…

4. おはなしすること。 なぜやるの? なにからはじめればいい? どうやってるの? こんなものつかってます ぼっち開発でも、コードレビュー! やってみての気づきとか まとめ & 時間があったら参考画面 4

5. なぜやるの? 問い合わせが来る! インストールできないです マイグレーションできないです このプラグインとこのプラグイン
 入れてるんだけど
 エラーになっちゃいます… 5 プラグイン公開しました! でも…

6. 過去の
 クレーム(汗
 チケットの山…

7. — by @akiko_pusu “ たくさんの  Redmineかんりしゃさんを こまらせたいわけでは ないのです べんりにつかってほしい だけなんです ” はじまりは、ここから。

8. マイグレーションが通るかどうか プラグインを配置した状態での
 マイグレーションの確認 ロールバックの確認も! 8 テストコードがなくても。 まずはこれだけは。 $ bundle exec rake redmine:plugins:migrate RAILS_ENV=test
 $ bundle exec rake redmine:plugins:migrate 
 NAME=${PLUGIN_NAME} VERSION=0 RAILS_ENV=test なにからはじめればいい?

9. どうやってやるの? まずRedmine本体を取得 本体のマイグレーションする プラグインを配置して
 マイグレーションする Redmineのベースディレクトリから
 プラグイン用のテストを走らせる 9 プラグインのテストには Redmine本体が必要です。

10. 前田さんからの取れ立て情報! “Redmine本体に付属の テストも通るか ためしてみよう!” ありがとうございます さっそくCiのステップに入れます! ※ 20161127:追記
 このスライドアップ後に手元のMacで 試したら素のRedmineでも失敗しました…
 rake ci だと想定される全てのSCMプトロコル、DBに対するテストを通しで行う ようです(?)。そこまでの環境を用意するのは大変なので、失敗しても参考 情報程度がいいのかも。

11. 基本のテストは? $REDMINE_ROOT/test/ 以下を見よう テスト用データは test/fixtures/を 利用しよう まずは test/unit/*.rb 以下の
 ユニットテスト、モデルの
 テストを参考に取り組もう 自作プラグイン用のfixturesも追加 11 基本はRedmine本体の テストコードを参考に。

12. でもプラグインのテストをRspecで 書くことはできます! 自分でRspecと関連するヘルパーを
 入れちゃいましょう! 自分のプラグインのGemfileに
 rspec_rails を追加 Redmine本体のbundle install時に
 Rspec用のgemが入ります
 12 Redmine本体はまだRspecじゃない… Rspecでテスト書けるの?

13. 13 プラグイン用のspec helperや
 rails_helperはちょっと工夫すること。 Rspecでテスト書けるの? テスト用データにRedmine本体の
 fixturesも利用できるように 実行はやっぱり
 Redmineのベースディレクトリから $ bundle exec rspec -I plugins/redmine_issue_templates/spec 
 plugins/redmine_issue_templates/spec/

14. — by @akiko_pusu “ やりかたはなんとなく
 わかった …… でもめんどくさい” そこで、自動化ですよ。

15. 15 オープンソースだと無料で利用できる
 CI環境がいくつもあります! こんなものつかってます 最初はJenkins 仕事で使ってるCIツールの学習に
 drone.io や wercker に切り替え $ bundle exec rspec -I plugins/redmine_issue_templates/spec 
 plugins/redmine_issue_templates/spec/ コマンド長いのでrake taskで実行中。

16. 16 drone.io https://drone.io/ こんなものつかってます googleの開発したDocker
 コンテナを利用したCI OSS版もあり、前職で利用
 してたのをきっかけに
 ツールに慣れるため個人で
 クラウド版を利用 pushのたびにビルド実施してくれます https://drone.io/github.com/akiko-pusu/redmine_banner
 https://drone.io/github.com/akiko-pusu/redmine_issue_templates     ビルドの内容 / Statusは公開してますので、よかったら参考にしてください!

17. 17 wercker http://www.wercker.com こんなものつかってます Docker + KerbernatesベースのCI/CD 現職で利用してたのがきっかけ
 やっぱり慣れるために個人で使ってみた pushのたびにビルド実施 drone.ioではrubyのバージョンが
 限られているのでこちらをメインに https://app.wercker.com/akiko-pusu/redmine_issue_templates/runs     ビルドの内容 / Statusは公開してますので、よかったら参考にしてください!

18. 18 wercker こんなものつかってます https://github.com/akiko-pusu/redmine_issue_templates/blob/master/wercker.yml   設定は公開してますので、よかったら参考にしてください! wercker.yml というビルド用の設定
 ファイルに基づいて動きます Banner, Templateプラグインは
 werckerを使ってます 現在SQLiteですがDB用の
 コンテナと組み合わせて
 テストできたりします

19. 19 オープンなCIを使うと… あなたのコードに ハナマル(バッジ)が!

20. ぼっち開発でも、コードレビュー! 静的解析、やってみよう! — by @akiko_pusu “ひとりでほそぼそと つくってます… コードレビューして
    みたいんです……”

21. ぼっち開発でも、コードレビュー! SideCI https://sideci.com/ja 綺麗なコードと文化を作る コードレビューのためのCI 面倒な設定が要りません! 30秒で解析できちゃう!!    http://qiita.com/akiko-pusu/items/0f4cf90ab91d88e16c9d
 Qiitaの記事もよかったらどうぞ!

22. SideCI による静的コード解析 ぼっち開発でも基本は
 プルリク作ってマージ プルリクの際には
 SideCIが静的解析、
 werckerがテスト実施 キレイじゃないコードは
 ガンガンレビューが付く! どっちもパスしないと
 マージできない設定に! 自分以外のプルリクも、事前にチェック、
 テストを通して確認してもらえます

23. やってみての気づきとか。 インストール関連の問い合わせ減ったかも 本体よりもテスト用コードが増えてきた(汗 テストをしやすい単位に切り分けてコードを 書くほうがいいと実感した
 (ただいま修行中) jQueryをはじめフロントで制御する動作が
 増えてきたので、E2Eテストも必要と感じた Capybara + Seleniumのテストも追加 しているところです。

24. まとめ。 使ってくれる人が困らないようにテストを! でもプラグインテストは若干面倒 まずはマイグレーションからはじめよう 面倒な設定はCIにまかせちゃおう 静的コード解析も利用していこう あなたのコードに ハナマルを!

25. 参考:SideCI負債カンバンの例。 コード上になんらかの 難点がある場合。 コードがクリーンな場合。

26. 参考:CIでのE2Eテストの例。 wercker や drone.io で テストする場合は、 ヘッドレスブラウザの PhantomJSを使います。 wercker の場合は、 ベースのコンテナでテス トする前に、 PhantomJSをインストール する処理をしています。 テンプレートをポップアップで表示、 フィルタ、適用させる機能や、 Cheklist連携させたところを テストできるように調整中。

27. 参考:CIでのE2Eテストの例。 wercker や drone.io で テストする場合は、 ヘッドレスブラウザの PhantomJSを使います。 wercker の場合は、 ベースのコンテナでテス トする前に、 PhantomJSをインストール する処理をしています。 テンプレートをポップアップで表示、 フィルタ、適用させる機能や、 Cheklist連携させたところを テストできるように調整中。

28. 参考:個人的にこころがけてること。 無理しないで小さくやろう 追加Gemは本体と競合するので控えめに なるべくこまめにCIまわそう カバレッジやバッジでモチベーション維持! プラグインと同じ機能が本体に実装されたら、 それが一番いいことです。 本体に実装される際の参考になれたら幸せ。 なので、テストは今後も
 付けていこうと思います。

Add a comment