Railsでブラウザテストを「正しく」行う方法（翻訳）｜TechRacho by BPS株式会社
Rubyでテストがこれほど盛んな理由のひとつはRailsの存在にあると私は信じています。Railsフレームワークはテストをできる限り楽しく書けるようにしてくれます。ほとんどの場合、網羅的なRailsテスティングガイドを参照すれば事足ります（少なくとも最初のうちは）。しかし物事に例外はつきものです。私たちの場合「システムテスト」がそれでした。 テストをページのマークアップから切り離す方法については、「Railsシステムテスト」シリーズの次の記事『System of a test II: Robust Rails browser testing with SitePrism』をご覧ください。 Railsアプリケーションでシステムテストを書いたりメンテしたりするのは、正直「楽しい」からほど遠い作業です。この問題に対処するために用いた私のアプローチは、今を去ること2013年に初めてCucumber
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法 - Qiita
# トレーニングジムの予約システムを開発していると仮定してください describe 'キャンセル処理' do let(:user) { create :user } let(:reservation) { create :reservation, user: user, start_at: '2017-08-10 10:00'.in_time_zone } context '24時間前をすぎるとキャンセル料が発生する' do before do travel_to '2017-08-09 10:00'.in_time_zone reservation.cancel! end after { travel_back } let(:billing) { user.billings.first } it { expect(user.billings.count).to eq 1 } it {
【初心者向け】レビュワーをイライラさせるRSpec集と解決方法 - メドピア開発者ブログ
こんにちは。メドピアにjoinして3ヶ月目の保立です。 毎週のように新しい開発が進むため、毎日楽しくソースコードを書かせてもらっています。 テストコードを制するものは、Railsを制す!!! ということで、今回はメドピアのRSpecについてです。 メドピアでは、RSpecを用いてテストコードを書いており、 - 1) models配下に記載するビジネスロジックに対するUnitTest - 2) 機能ごとのEndToEndTest (E2E Test) の2種類のテストコードを書いています。 RSpecについて、書こうと思ったきっかけ RSpecは（というかRuby自体が）様々な書き方で動かすことができるため、統一したルールがないと、書いた人によってバラバラなテストコードになります。 私も初めてRSpecを書いた際に、参考書やソースコードによって書き方がバラバラで、どのRSpecを参考にすれば
テストしやすいGoコードのデザイン
テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ！ 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency
テストなんか書かなくて良い！？ エンジニアたちの反応まとめ
リンク http://mosa-siru.hatenablog.com/ テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog 世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定
悩んでるポイントはみんな同じ！？「Rubyistのためのテストコード相談会」の質疑応答まとめ - give IT a try
はじめに 先週の土曜日（2015年5月16日）に西脇.rb＆神戸.rbで「Rubyistのためのテストコード相談会 ～テストの書き方に悩んでいませんか？～」という勉強会を開催しました。 この勉強会は「テストコードに関する疑問や悩みをみんなで持ち寄り、みんなで解決すること」を目的にした勉強会です。 勉強会中はいろいろと興味深い議論が出たので、今回のエントリではその内容を簡単にまとめてみます。 勉強会で挙がった質疑応答 よく使うフレームワークは？ RSpecが大多数、Minitestが若干名。 gemを開発するときはMinitest、RailsはRSpec、というように開発内容によってフレームワークを使い分ける、という人もいた。 Minitestってどうなの？ 導入が簡単。assertメソッドだけ知っていればなんとかなる。 Railsにも対応している。Capybaraも使える。 RSpecのs
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
RSpec 3の重要な変更 - 有頂天Ruby
Myron Marston » Notable Changes in RSpec 3の雑な訳です。 誤訳・雑すぎる訳がありましたら、Twitterで@nilp_までご連絡頂けると助かります。 RSpec 3.0.0 RC1が2日前にリリースされました、そして最終的な3.0.0のリリースが目前に迫っています。 我々はβ版をここ6ヶ月にわたり使ってきました、我々はそれらを皆さんと共有できることにわくわくしています。 これが新しいとこだよ: すべてのgemたちにわたって Ruby 1.8.6と1.9.1のサポートがなくなりました これらのバージョンのRubyはかなり前に寿命を迎えました、RSpecはこれらをサポートしません。 Ruby 2.xのサポート向上 最近のRSpec 2.xのリリース(すなわち2.0がリリースされたあと出たやつ)はRuby 2を公式にサポートしています、しかしRSpec
Rails でテストをどう書くべきか備忘録
今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100％カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。（※） ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる
私がRSpecを書く場合のやり方について | 自転車で通勤しましょ♪ブログ
今日は木曜日だったので、ハンバーグの会（Okayama.rb）に参加してきました。 今日は@mako_wisにテストの書き方について相談を受けたので、粒度とかについて説明しましたが、私は説明し始めると早口になってしまうので詰め込みすぎたかもしれないと思ったのでちょっとまとめておこうと思いました。ちなみに、書き方といってもRSpecの始め方とかではないです。その点はあしからず。 Railsプロジェクトのいいところは、テストがとてもしやすいところだと思います。 私は今の会社に入るまで、テストは書きたいけれど、どう書けばいいのかわからなかったのと、頑張って書いてみたものの、成果が周りに評価されなかったのでこのままでいいのだろうか？と思い悩んでいました。しかし、既にテストがあるプロジェクトに入って書き方を学べた事と、同僚とThe RSpec Book読書会を社内で開いて勉強したおかげで、結構綺麗に
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - goldbergyoni/javascript-testing-best-practices: 📗🌐 🚢 Comprehensive and exhaustive JavaScript & Node.js testing best practices (July 2023)
外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck
組織にテストを書く文化を根付かせる戦略と戦術 / Strategy and Tactics of Building Automated Testing Culture into Organization
組織にテストを書く文化を根付かせる戦略と戦術
レガシーコード改善の戦略と戦術
