はじめに Rails 5.1で導入されたSystemTestCaseを使ってみたので、その記録を残しておきます。 この記事ではユーザーマスタメンテ画面で、JavaScriptを使った郵便番号自動検索機能をテストします。 Rails 5.1のSystemTestCaseとは？ いわゆるエンドツーエンド（E2E）テストを実行するためのテストケースクラスです。 このテストケースクラスを使うと、JavaScriptを利用する画面のテストが書けるようになります。 また、サードパーティgemを使う従来の方式ではDatabaseCleanerやDatabaseRewinderを使って、テストデータのトランザクション管理に関する設定が必要でした。 しかし、SystemTestCaseはフレームワーク内でトランザクション管理をしてくれるので、こうした設定も不要になります。 対象バージョン この記事では以下の

はじめに 去る2017年2月23日、Rails 5.1.0.beta1が公開されました。 Rails 5.1.0.beta1: Loving JavaScript, System Tests, Encrypted Secrets, and more - Riding Rails Rails 5.1ではマイナーバージョンアップと言えど、かなり大きな変更点が多数入っているようです。 そこで上記公式ブログの内容を僕なりにまとめてみます。 おことわり この記事は公式ブログやpull requestの内容を読んで、筆者が個人的にまとめたものです。 実際に動かして試したりはしていないので、おかしな内容や誤解している内容が含まれている可能性もあります。 もし、「これは明らかにおかしい！」という内容を見つけた場合は、コメントや編集リクエストで優しく指摘してやってください。 サンプルコードについて この記事

CREATE TABLE users ( id INTEGER PRIMARY KEY, joined_on DATE NOT NULL, left_on DATE NULL ); INSERT INTO users VALUES (1, '2014-08-01', '2014-08-10'); INSERT INTO users VALUES (2, '2014-08-01', '2014-08-05'); INSERT INTO users VALUES (3, '2014-08-03', NULL); INSERT INTO users VALUES (4, '2014-08-03', '2014-08-10'); INSERT INTO users VALUES (5, '2014-08-10', NULL); 解答方法 実行方法は自由ですが、SQL Fiddleを使うとお手軽かも

はじめに 先日、スタック・オーバーフローを見ているとこんな質問が載っていました。 Ruby On Railsで質問に対してのBA機能 - スタック・オーバーフロー 「BA機能」というのはどうやらベストアンサー機能の略らしいです。（BAって略し方は一般的なの？？） それはさておき、僕が気になったのは質問の最後の部分です。 Processing by BestAnswersController#best as HTML Parameters {"authenticity_token"=>"DtGJ+4qzzG2PqEJpa7GH9Fb8pQhGDX0cg+w+qhf0tP/9HIIVYabiJeW0rEiL7iydpa5PpjrdR1V1LeGzfOeJjw==", "comment"=>"43", "note_id"=>"36"} Note Load (0.2ms) SELECT "note

RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違いRubyRails 2021.2.11追記：DateTimeクラスは非推奨なクラスになりました DateTimeクラスは非推奨なクラスとなり、DateTimeクラスではなくTimeクラスを使うよう、公式にアナウンスされました。 参考1 But we consider use of DateTime should be discouraged. - matz (Yukihiro Matsumoto) https://bugs.ruby-lang.org/issues/15712#note-4 参考2 DateTime は deprecated とされているため、 Timeを使うことを推奨します。 https://docs.ruby-lang.org/ja/latest/class/DateT

はじめに こちらの記事が面白そうだったので、僕もコードを考えてみました。 Rubyで英語記事に含まれてる英単語を数えて出現数順にソートする（改良１） - Qiita 記事の最後に「かっこ良く書けるようになりたい」とあったので、カッコ良く書いたつもりです！（注：自分基準） どんな問題なの？ テキストファイルの中から英熟語や英単語を抜き出してカウントする、という問題です。 入力に使うテキストファイルはこんな感じです。 Interior design and decorating resource Houzz is the overall best Android app of the year, according to Google, which this evening announced the results of the first-ever Google Play Awards a

はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ

はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて

はじめに: 遠回りせずに「近道」を探す RubyやRailsを始めたばかりの人は、もっと短く書く方法や便利な標準ライブラリの存在を知らずに遠回りした書き方をしてしまいがちです。 そこで、RubyやRails初心者の人によく見かける「遠回り(または車輪の再発明)」と、それを回避する「近道」をいろいろ集めてみました。 2013.11.06 追記 この投稿を書くに至った経緯などを自分のブログに書きました。 こちらも合わせてどうぞ！ 昨日Qiitaに投稿した記事は普段のコードレビューの副産物 - give IT a try Ruby編 以下はRubyの標準機能を使ったイディオムやメソッドです。 Railsプロジェクトでもそれ以外でも使えます。(Ruby 1.9以上を想定) 後置ifで行数を減らす