技術的負債とならないテストコードを書くために考えること - Qiita
概要 プロダクト開発を行う上で、テストコードは重要な要素であるかと思います。 ユニットテストコードを書くことで、クラス単位の動作保証を行うことが出来ます。また、E2Eテストやインテグレーションテストを書くことで、DBアクセスや外部連携を含めた、プロダクトにおける一気通貫の動作を確認することが可能になります。 作成したテストコードは、CICDと組み合わせて、自動テストとして定期的に実行させます。これにより、既存のソースコードを変更した際の品質を (ある一定レベルにおいてですが) 担保することが出来るようになります。結果として、開発メンバーは積極的なリファクタリングを行えるようになり、健全な開発のライフサイクルが回る・・・という流れになります。 テストコードも、プロダクションコードと同様に、継続的に保守・開発していく必要があり、一定のお作法に則って開発していく必要があります。無秩序で設計が不十
『Go言語でTestableなWebアプリケーションを目指して』
はじめまして@shohhei1126です! 2016年1月にリリースされたAmebaFRESH!のサーバサイドを担当しております。 ここ1、2年社内でもGo言語を使うプロジェクトが増えてきているのですが（Go Lang in Cyberagent こちらもどうぞ）AmebaFRESH!でもGo言語をメインに使っています。 今回はGo言語のテストへのアプローチについて考えたいと思います。 テストの書きやすさGoでは言語レベルでテストをサポートしている（https://golang.org/pkg/testing/#pkg-overview）のでテストを書くという敷居は他の言語より低く感じます。実際これまでのプロジェクトの中で一番テストを書いていますし、やっぱりテストがあると安心感ありますね(・∀・) Mock化の難しさテストの取っ掛かりとしての敷居は低いですがデータアクセスまわりのテストを書
Railsでテストを書く場合、FactoryGirlなDB接続するかmock_modelなモック作成か(Ebisu.rb#8) - tchikuba's blog
前回のEbisu.rb#7に引き続き、 Ebisu.rb#8も参加しました。 勉強会の形式は前回同様で飲みながらRuby関連ネタを語り合う感じでした。 前回は19:30集合でしたが前回のKPTから20:00から開始でした。 今回は事前に仕込んだLTネタが3件あり話題が豊富でしたね。 当日の雰囲気はハッシュタグ#ebisurbの 4/25の参加者のつぶやき見てもらえればイメージ湧くかと。 後半ひと通りLT的な発表が終わってからお酒も進んでの雑談の中でRailsでのテストをどんな感じで書いてるか？ という話題になりました。個人的に今回LTネタ的な感じで発表してみようかなと思っていて結局できなかったので 考えを整理する為にも書き残しておこうと思います。 結論から言うと私が関わるプロジェクトの場合はpoltergeist+turnip+Capybara+FactoryGirlで受入テストを、 Rs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
