並び順

ブックマーク数

期間指定

  • から
  • まで

321 - 360 件 / 3196件

新着順 人気順

rspecの検索結果321 - 360 件 / 3196件

  • RSpecでRequest Describer - Qiita

    WebアプリケーションのHTTPレベルでの振る舞いに対してテストを記述するとき、皆さんはどのような考えを持ってテストコードを記述しているでしょうか。この投稿では、この手のrequest-specと呼ばれるテストについて考えながら、テストを書くときの幾つかの方針と、RSpec::RequestDescriberを利用してテストコードを簡略化する方法を紹介します。 request-specとは request-specという、HTTPにおけるリクエストとレスポンスの組み合わせを、言わばブラックボックスとして扱うテスト形式の呼び名があります。リクエストを入力、レスポンスを出力として扱い、ある入力に対して期待される出力が返されるかどうかをテストします。rspec-railsの中では、request-specに対して以下の説明が与えられています。 Use request specs to speci

      RSpecでRequest Describer - Qiita
    • ウノウラボ Unoh Labs: アジャイルな開発をチームでやってみた(2010年版) - その2

      テストコード書いてますか? HIROKIです。 murahashiに続いて、テストファーストを導入してみての振り返りをします。 まず、どうやってチームにテストファーストのスタイルを持ち込んだのか。 1.テストが重要だという共通認識を持つ。 前のプロジェクトではテストコードは、ほとんどありませんでした。 その中で、開発になれていない人や新たに人が投入され、 極少数ですが、デグレーションが起きました。 その経験を元にテストが重要だという共通認識を持つことができました。 2.プロジェクト開始時からテストファーストに踏み切る気持ちが必要 テストコードを書かなければコミットさせない。ぐらいの気持ちが必要です。 実際に何度も、本格的な実装が始まる前から口にしていました。 「うちのチームはテストを書かなければコミットを許さない。」と。 3.でも、テストコード書いたことないよ? テストコードを書いたことの

      • GitHub - willnet/rspec-style-guide: 可読性の高いテストコードを書くためのお作法集

        You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

          GitHub - willnet/rspec-style-guide: 可読性の高いテストコードを書くためのお作法集
        • Rubyを勉強する上で有用な情報源まとめてみた - Qiita

          Rubyを勉強する上で役立つ情報源をまとめてみました。まだ仕入れていない情報源があれば価値がある記事なんじゃないかと思います。 書籍 Everyday Rails - RSpecによるRailsテスト入門 Rubyでテストコードを書くときは多くの人がRspecを使っていると思いますが、そのRSpecを学ぶ上で実用的な書き方が学べます。実践で頑強なプログラミングを書けるようになり、チームの人たちも安心して仕事を任せてもらえます。 メタプログラミングRuby Ruby力を高める上で必要な知識がメタプログラミングです。コードを読むのにも書くのにも知っているかどうかで大きく影響します。これを読みきった頃には中級者に達していると言っても良いでしょう。 パーフェクトRuby ここまで学んだ知識の穴埋めをしてくれるでしょう。実践力向上に役立ちます。 パーフェクトRubyOnRails Rubyを使う上で

            Rubyを勉強する上で有用な情報源まとめてみた - Qiita
          • Mochaを使ってJavaScriptのテストをブラウザで実行してみよう

            対象読者 JavaScriptの基本をある程度理解している方 テストコードをこれから書こうと考えている方 JavaScriptのテスティングライブラリの分類 JavaScriptには、テストを記述するためのライブラリが多く用意されています。ライブラリには、大きく分けて「テスティングフレームワーク」と「アサーションライブラリ」があります。まずはこの2種類の違いについて説明します。 テスティングフレームワーク テストを記述する関数群を提供し、それらの関数を使って書かれたテストの結果を判定、集計した上で結果を表示する機能を持ちます。ブラウザでのテストの場合、ブラウザ上でグラフィカルにテスト結果を表示することもありますし、サーバサイドのJavaScriptであるNode.js向けにはコマンドラインで実行し、結果を表示する機能も持ちます。 アサーションライブラリ テスティングフレームワークは、テスト

              Mochaを使ってJavaScriptのテストをブラウザで実行してみよう
            • Watir - Overview

              description goes hereAutomated testing that doesn’t hurt Watir is a simple open-source library for automating web browsers. It allows you to write tests that are easy to read and easy to maintain. It is optimized for simplicity and flexibility. Watir drives browsers the same way people do. It clicks links, fills in forms, presses buttons. Watir also checks results, such as whether expecte

              • 東大法学部卒・31歳無職はなぜ第一線プログラマになれたのか──freee平栗遵宜の「仕事の流儀」|CodeIQ MAGAZINE

                クラウド型会計ソフトで躍進中のfreee。スタートアップならではのユニークな人材が豊富だ。 ユニークさで群を抜くのは、東大法学部卒、31歳無職職歴なしからのfreee第1号社員。プログラムはまったくの素人だったのに1年足らずで欠かせない戦力になった平栗遵宜さんの例だろう。 彼はいかにしてプログラマになれたのか。 by 馬場美由紀 (CodeIQ中の人) 31歳・職歴なし、プログラミング経験全くのゼロ 弁護士の父の法律事務所を継ぐべく、東大法学部に入学。司法試験を受けつつも、大学生の時にとある出来事がきっかけで大金を手にし、ニートを決め込んでいました。31歳まで生きながらえるも、サブプライムローンやリーマンショックの影響で予定より早く資金ショートに陥り、就職を決意。 どうせだったらこれまでと全く関係のない仕事をしようと職を探していたところ、友人の知り合いが最近スタートアップを始めたという話を

                  東大法学部卒・31歳無職はなぜ第一線プログラマになれたのか──freee平栗遵宜の「仕事の流儀」|CodeIQ MAGAZINE
                • Vows « Asynchronous BDD for Node

                  Asynchronous behaviour driven development for Node. There are two reasons why we might want asynchronous testing. The first, and obvious reason is that node.js is asynchronous, and therefore our tests should be. The second reason is to make tests which target I/O run much faster, by running them concurrently. Write some vows, execute them: $ vows test/* --spec Get the report, make sure you kept yo

                  • Rails / RSpec テスト書いたことない メンドクサイ(n´Д`)という時のチートシート

                    テストを書かないようになってしまっていた。 大きなアプリケーションではないし一人で作ってるし… まぁいいか的な。 ただ、コードの量が増えていくにつれやっぱりちょっと辛い。 書き方すっかり忘れたので、RSpec再入門。 環境 Vagrant + CentOS (centos64box) Ruby 2.2.1 Rails 4.1.1 最終的なGemfile(テスト関係だけ) テスト用のDBの設定をお忘れなく。 gem 'pg' group :development, :test do gem 'rspec-rails' gem 'factory_girl_rails' gem 'guard-rspec' gem 'spring-commands-rspec' end group :test do gem 'faker' gem 'capybara' gem 'database_cleaner'

                      Rails / RSpec テスト書いたことない メンドクサイ(n´Д`)という時のチートシート
                    • Route 477(2009-06-09)

                      ■ [ruby] Rubyのテスト環境大戦争 おまいらは本当にテストが好きだな!というわけで、Rubyのテスト関係のライブラリを並べてみた。 テストフレームワーク Test::Unit Ruby標準添付のユニットテスト用フレームワーク。 RSpec DSLを使う、「BDD」という概念を流行らしたユニットテスト用フレームワーク。 Cucumber 自然言語を使って、ブラックボックステストを記述する。RSpecの「Stories」と呼ばれていた機能が独立した。 あとはShouldaとかbaconとかいろいろありますけども。 モック・スタブライブラリ モック=あるオブジェクトに期待したメッセージが飛ぶかどうかテストするためのオブジェクト、 スタブ=ネットワークが絡むとか、実際のオブジェクトが使えない場合に使う偽オブジェクト。 と思ってるんですけどどうなんですかね(more: モックとスタブの違い

                        Route 477(2009-06-09)
                      • Railsのテスト実行時間を1/3まで短縮した話 (Rspec + CircleCI)

                        背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。 業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。 おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。 こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して

                          Railsのテスト実行時間を1/3まで短縮した話 (Rspec + CircleCI)
                        • 【iOS/Android】最新事例から学ぶ!モバイル向けテスト手法勉強会に行ってきた - 悪あがきプログラマー

                          【iOS/Android】最新事例から学ぶ!モバイル向けテスト手法勉強会 - connpass 会場は名刺共有サービスで有名なSansan株式会社さんでした。 とってもおされ。 いつもは資料のまとめとか他力本願なのですが、自分でもひと通り観直したかったのでまとめてみました。 今回の勉強会はiOSとAndroidの両方を対象としたモバイル向けの内容となっています。ただ、僕はAndroidには明るくないのでコメントはiOS寄りになります。 資料がないものは公開され次第追加します。 「テストの種類とBDD」『iOSアプリ テスト自動化入門』著者 長谷川氏 テストの種類とBDD #33testing from Koji Hasegawa iOS自動化入門の著者さんです。僕も買いました。 iOSアプリ テスト自動化入門 作者: 長谷川孝二出版社/メーカー: 秀和システム発売日: 2014/03/18

                            【iOS/Android】最新事例から学ぶ!モバイル向けテスト手法勉強会に行ってきた - 悪あがきプログラマー
                          • RSpec の feature spec でヘッドレス Chrome を使う - Speee DEVELOPER BLOG

                            Speee エンジニア組織推進室の服部 (yhatt) です。 みなさん E2E テストされていますでしょうか。弊社の Ruby on Rails プロダクトにおいては、RSpec、Capybara、 Poltergeist を組み合わせ、 feature spec で E2E テストを行う構成が一般的でした。 そんな中、Chrome 59 に ヘッドレスモード (--headless) が搭載 されたことで、テストや CI 環境において、最新の Chrome 環境による E2E テストを実施できるようになりました。それに合わせて、PhantomJS のコアメンテナーがメンテナーを降りる ことを発表し、PhantomJS のアップデートや、継続的サポートは期待できない状況となっています。 ヘッドレス Chrome ことはじめ  |  Web  |  Google Developers [A

                              RSpec の feature spec でヘッドレス Chrome を使う - Speee DEVELOPER BLOG
                            • クックパッドアプリの開発を支援する Appiumの話し 2014/10/18 第2回 日本Seleniumユーザーコミュニティ勉強

                              去年のデブサミの「日本Seleniumユーザーコミュニティ」のLTが真面目すぎてイマイチだったので、今年は何とかしようと色々がんばった結果wwNozomi Ito

                                クックパッドアプリの開発を支援する Appiumの話し 2014/10/18 第2回 日本Seleniumユーザーコミュニティ勉強
                              • RSpecのテストコードを実行時に書き換えて実行速度を改善した話 - STORES Product Blog

                                CTOの藤村です。つい最近まで STORES ブランドアプリ のチームでRailsを書いていました。 STORES ブランドアプリ のRailsリポジトリではdatabase_cleanerを(strategy = truncationで)使ってテスト中のデータベースをリセットしており、このことがテストコードの品質、速度などで重荷となっていました。 これを、テスト実行時にテストコード自体を書き換えて改善する仕組みを作り、先日無事Transactional Testへの移行が完了しました。ということで気分がとてもよいので、どうやったか共有させてください。 課題 STORES ブランドアプリのRailsのテストコードは速度に課題がありました。 テストデータを片付ける仕組みとして、 Railsエンジニアにはお馴染みのdatabase_cleanerというGemを使っていました。database_

                                  RSpecのテストコードを実行時に書き換えて実行速度を改善した話 - STORES Product Blog
                                • Swift界隈で話題沸騰中のテストフレームワーク Quick とは? - Qiita

                                  Quickとは? QuickはSwiftが発表された2日後にGithubにコミットされた、世界で一番最初のSwiftのテストフレームワークです。ビヘイビア駆動開発(BDD)指向のテストフレームワークで、SwiftとObjective-Cの両方の言語に対応しています。RSpec, Specta, Ginkgoの影響を受けているそうで、記述がしやすく可読性の高いケースを表現できるのが特徴です。 ロゴもSwift調のデザインで素敵です。 開発者は? 開発者はmodocache (もどかしい)さんという日本にいらっしゃるエンジニアさんが作られています。ハンドルネームがとってもお洒落ですね。 期待度は? まだ開発開始から2週間弱ですが、とても活発に開発が行われており今後Swiftのデファクトテストフレームワークになるのではと期待が寄せらています。 また既存のObjCテストフレームワーク(※)はSwi

                                    Swift界隈で話題沸騰中のテストフレームワーク Quick とは? - Qiita
                                  • 「フカシギの数え方」の問題を解いてみた

                                    先日、「『フカシギの数え方』 おねえさんといっしょ! みんなで数えてみよう!」という動画を見た。格子状のマスの左上から右下までの経路が何通りあるのかを調べて、格子が多くなればなるほど組み合わせの数が爆発的に増えることを教えてくれる動画だ。これは自己回避歩行(Self-avoiding walk)と呼ばれている問題らしい。 これだけ聞いてもそれほどインパクトはないのだが、動画に出てくるおねえさんの経路を調べあげる執念がもの凄く、ネット上でも結構な話題になっている。執念と言うよりも狂気に近い。しかし、話題になった割には動画内で言及されている高速なアルゴリズムを実装したという話を聞かなかったので、自分で確かめることにした。 動画のおねえさんは深さ優先探索によるプログラムを使っていると思われるが、それだとスパコンを使っても10×10マスの格子を解くのに25万年も掛かってしまう。そこで、高速化のため

                                      「フカシギの数え方」の問題を解いてみた
                                    • 過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方

                                      さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介 伊藤淳一氏:リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。

                                        過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方
                                      • Rails勉強会まとめ -- 非同期処理/RSpecなど|TechRacho by BPS株式会社

                                        こんにちは、hachi8833です。 今回は棚卸しとして、弊社CTOのbabaさんによるRails勉強会スライドから引用して記事にします。 勉強会自体はRails 3.x時代のものなので既出が多くなっていますが、棚卸しも兼ねて今のうちに記事にいたしました。 非同期処理 言うまでもなく、リクエストからレスポンスまでの時間が長くなるほどユーザー・エクスペリエンスの質が低下します。これを改善するためにさまざまな工夫が必要になるわけですが、その中の一つとして、時間のかかる処理をバックグラウンドで実施しておくというのがあります。 cron 最も素朴な方法はやはりunix標準のcronを使って定時に出力データを準備することでしょう。この場合、起動用スクリプト(rakeなど)やジョブ管理は自分で作成する必要があります。 delayed_job delayed_job gemを使用すると、ジョブをActi

                                        • あるRuby on Railsプロジェクトのふりかえり - yuum3のお仕事日記

                                          昨年末から始めた、Ruby on Rails を使ったある仕事がひと段落したので、ふりかえってみました。 この仕事で作ったWebアプリの詳細は書けませんが、画面数 60、テーブル数 15 と小規模のものでした。システムはところどころに難しい部分はありました、UIは一部に Ajax(JQueryを使用)を導入し使い勝手を高めています。 1. ソースコードが少ない! 書いたRubyコードの行数を合計すると 約3600行 しかありませんでした! 1画面あたり 60行しか書いてない !! ・・・「あんまり仕事してないじゃん!」と思わずつぶやいてしまいまました ^^); やはり、Ruby on Rails は生産性が高いと言われる通りです。 ただし、だらだらとコードを書かないように以下のように注意しました。 共通部分はモジュール化しMix-inで共有 継承による機能の共有は設計が難しくなりますし、委

                                          • 私がMinitestとRailsのFixturesにハマった7つの理由 - 有頂天Ruby

                                            Brandon Hilkertの7 reasons why I'm sticking with Minitest and Fixtures in Railsの雑な日本語訳です。 誤訳が雑すぎる訳やあれば、Twitterで@nilp_までお声かけいただくか、コメントやブコメで指摘してもらえると幸いです。 私がMinitestとRailsのFixturesにハマった7つの理由 私は先月グリーンフィールドのRails 4.1アプリの唯一の開発者として過ごす機会に恵まれました(訳注: なんの制約もないことをGreenfieldと言うそう)。 既存のコードをメンテするのにかなりの時間を費やしたことのある人にとって、 パターンを設け、ツールを選択する自由があることは非常に喜ばしい変化です。 私が行った選択の1つがMinitestとRailsのfixturesを使うことです。 端的にいうと、それは最高で

                                            • ノーフレームワークのレガシーPHPがCIに乗るまで

                                              ついに仕事で触っている PHP のコードがほんの一部のテストとは言え CI に乗った。 正直これは感動ものだ。 今回はここに至るまでの長大な物語をダイジェストでお届けしようと思う。 有史以前PHP 3 で作られた 1 URI : 1 スクリプト + 共通関数 時代 当然のように PHP と HTML と SQL 混在まともなテスト環境がなかったので似た環境をどうにか作るパスとか絶対で埋め込みまくりなのでとりあえず共通のパス情報の変数に差し替えまくりテスト環境用のコードと本番環境用のコードが違うオール目視 つらかった。 みなさんの予想通りバージョン管理なんてものは存在しなかった。 素朴なPHPを徐々にclassにclass になれば phpdoc を書きやすくなるいきなり実行しないようにすればテストしやすくなる これは後から気づいたんだけど、結局フロントはロクに自動テストできてない一時期 p

                                              • "rspec の書き方がわからない"

                                                _ko1 @_ko1 やっぱり spec の書き方がわからない、のは理解が足りていないからだと思うんだが、書籍でも読むといいんだろか 2014-04-17 15:24:18

                                                  "rspec の書き方がわからない"
                                                • [Ruby on Rails]FactoryGirlによるテストデータの準備 | DevelopersIO

                                                  はじめに RSpecを使ってテストを記述している際、テストの実行前にデータをテーブルに登録しておきたいケースが多々あるかと思います。RSpec内でActiveRecordを使ってデータを登録することもできますが、複数のテストケースで同じデータを使いたい場合、データの定義は一箇所で行いたいところです。 この様な場合、Factory Girlを使用すると、一箇所でテストデータを定義できます。今回はこのFactoryGirlの使い方について書きたいと思います。 使い方 使い方の大まかな流れとしては、 FactoryGirlが使用できるようにする 定義ファイルにデータを定義する 必要とするテストケースにてファイルを読み込み、データを適時加工して登録する という感じとなります。尚、この定義したデータを「Factory」とも言います。以下、手順です。 1.Gemfile Gemfileに以下を記述し、

                                                    [Ruby on Rails]FactoryGirlによるテストデータの準備 | DevelopersIO
                                                  • Front page - APIdock

                                                    Choose a project RSpec Behaviour Driven Development framework for Ruby 6 imported versions - 25 notes - Browse - Search Ruby on Rails The open source web application framework for the Ruby programming language 26 imported versions - 1313 notes - Browse - Search Ruby A dynamic, open source programming language with a focus on simplicity and productivity 12 imported versions - 370 notes - Browse - S

                                                    • Search

                                                      Releases, Offers & More Be the first to hear about our newest content, best promotions and upcoming events. Plus get 25% off your next purchase. Newsletter Sign Up Download Accounts Your email address is your account identifier. You can create a password, or just download from the links sent via email. My Orders (Resend order emails) How We're Different Hands-on instructions Solutions to real-worl

                                                      • gemを作る時に気をつけていること - くりにっき

                                                        公私含めて2年間でたぶん30個以上はgemを作ってますが、なんとなく体得はしたもののこういうことは誰も教えてくれなかった気がするので残しておきます アンダースコアとハイフンを使い分ける gemを作る第一歩は bundle gem <作りたいgemの名前> ってやると思いますが、単語区切りであればアンスコ、ネームスペースの区切りだったらハイフンを使います アンダースコア区切り $ bundle gem go_princess_precure Creating gem 'go_princess_precure'... create go_princess_precure/Gemfile create go_princess_precure/.gitignore create go_princess_precure/lib/go_princess_precure.rb create go_pri

                                                          gemを作る時に気をつけていること - くりにっき
                                                        • 『Javaプロジェクトでテストをたのしく書くための試み』

                                                          こんにちは、Ameba事業本部ゲームプラットフォーム室の山田(@stormcat24)です。 自分のミッションは主にゲーム部門の開発の改善で、最近はScalaでモナ・・・しながらツールを書いてたりClojureに手を出したりしています。 はじめに ところでみなさんJava書いてますか?サイバーエージェントでは最近node熱が高いのですが、Javaプロジェクトもまだまだ根強く存在します。僕も隙あらばScalaをぶっこもうとしてますが、大人の事情でまだまだJavaを書くシーンも多いのです。 で、そんなテンションが上がりにくいJavaプロジェクトをやっていく上で、せめてテストくらいはなるべくたのしく書きたい!ということで、今のプロジェクトで取り入れた施策を簡単にですが紹介します。 めちゃくちゃ尖った技術を使ってるわけではないですが、これらをやっておけばそれなりに楽しく書けるかなと思ってますので、

                                                            『Javaプロジェクトでテストをたのしく書くための試み』
                                                          • Rails使いよspork, zeusからspringへ! | Act as Professional

                                                            Rails application preloader といえば spork や zeus を使っている人もいるかと思います。 今後、期待できる preloader として spring を教えてもらいました。 springはzeusと類似していますが、springはrubyで実装されています。Railsに綿密に統合されているのが他のプリローダーと比較すると大きな特徴です。 Railsコミッターが開発していることからも、今後期待できるpreloaderです。 インストールGemfileにspringを追加します。 group :development, :test do gem 'spring' end$ bundleこれでgemが導入されます。 利用方法springの簡単な使い方です。 $ bundle exec spring Usage: spring COMMAND [ARGS] T

                                                              Rails使いよspork, zeusからspringへ! | Act as Professional
                                                            • APIテスト自動化ツールKarateをBDDツールとして使う - まっつんの日記

                                                              Karateとは Karateは主にe2eテストを自動化するツール。cucumber的なfeatureファイルを書くとそれを実行できる。WebAPIのテストがその中心的ターゲット github.com graalvmのjsライブラリで実現しているっぽいので、featureファイルからJavaも呼べる。 個人的にBDDというのが結構いいと思っていて、ビジネスルールの仕様なんかをビジネスサイドと意識合わせする場合に使えると思っている。アンクルボブはFitnesseというツールを作っている。 FrontPage Fitnesseは名著『実践アジャイルテスト』でも紹介されていたもの 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践) 作者:Janet Gregory,Lisa Crispin発売日: 2009/

                                                                APIテスト自動化ツールKarateをBDDツールとして使う - まっつんの日記
                                                              • give IT a try

                                                                お知らせ 先日拙著「プロを目指す人のためのRuby入門 改訂2版(通称・チェリー本)」が増刷されました!🎉 【Rubyを知れば,Railsはもっと楽しくなる】伊藤淳一さん 執筆の『プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで』が好評につき第3刷の増刷が決定!あのチェリー本がRuby 3.0に完全対応しました!https://t.co/5wMqpobn08— 技術評論社販売促進部 (@gihyo_hansoku) 2024年4月24日 いやあ、嬉しい!いやあ、めでたい! 本書を買っていただいたみなさんのおかげです。どうもありがとうございます! そもそも「増刷」って何なん? 増刷(ぞうさつ)というのは、簡単に言うと「本の在庫がなくなってきたから、在庫を補充するために追加で印刷すること」です。 「え、それだけ?」と思われるかもしれませんが、商業出

                                                                  give IT a try
                                                                • Webサービスの品質向上のために導入しているサービス・ツールまとめ - LCL Engineers' Blog

                                                                  LCLが運営しているWebサービスは、品質向上のために、複数のサービスやツールを利用しています。今回はそれらのサービス・ツールをまとめてご紹介します。 品質向上のためのプロセス それぞれのサービス・ツールは以下のタイミングで利用しています。 各サービス・ツールの紹介 各サービス・ツールについて、一つずつご紹介します。 なお、今回はコードレビューや手動テストについては取り上げません。 SideCI SideCIとは、コードレビューを自動化してくれるサービスです。GitHubのプルリクエストを自動で解析して指摘してくれます。 Ruby, PHP, JavaScript, CSS, Java, Python, Go, Swiftなどに対応しているようです(2018/02/15現在)。 詳細は以下の記事でご紹介しています。 techblog.lclco.com SideCIは、プルリクエストが作ら

                                                                    Webサービスの品質向上のために導入しているサービス・ツールまとめ - LCL Engineers' Blog
                                                                  • Rails API Testing Best Practices

                                                                    Writing an API is almost a given with modern web applications. I’d like to lay out some simple guidelines and best practises for Rails API testing. We need to determine what to test and why it should be tested. Once we’ve established what we will be writing tests for, we will set up RSpec to do this quickly and easily. Basically we’ll be sending HTTP requests and testing that the response status c

                                                                    • テストを書くときに気をつけていること - m_nakamura145’s diary

                                                                      この記事はトレタ Advent Calendar 2016の8日目です。 それなりの規模のサービスだとテストを書くと思う。 テストコードはテストデータの準備なども含めると、コード量が多くなりやすい。そのため、読みやすく意図が通じやすいテストを書くように意識しないと初めてテストコードを読む人が理解し辛い。 テストを書くときに考えていることを言語化して他の人と議論したことが無かったため、今回のエントリでは普段自分が気をつけていることについて書いてみる。 例として、予約を更新する PUT /reservations/:id について述べる。リクエストを受け取ったらJSONを返すAPIとする。 describe "ReservationsController" do describe "PUT /reservations/:id" do let(:reservation) do FactoryGi

                                                                        テストを書くときに気をつけていること - m_nakamura145’s diary
                                                                      • vagrant-serverspecを使ってプロビジョニング結果をテストする

                                                                        全国1000万人のVagrant利用者のみなさんこんにちは。 Vagrantいいですよね!そしてインフラの状態をテストするserverspecもいいですよね!この2つがシームレスに統合されるとかなりうれしいですよね! ということで本日12/2にvagrant-serverspecというプラグインがリリースされたので早速紹介します。 インストールインストールは簡単です。いつも通りvagrant plugin install vagrant-serverspec としてください。 コード自体は https://github.com/jvoorhis/vagrant-serverspec で公開されています。まだバージョン0.0.1なので、問題を見つけたらPR送るなりIssueを切るなりすると良いと思います。 使い方使い方も簡単です。まずVagrantfileを見てみましょう。 これは何をやって

                                                                          vagrant-serverspecを使ってプロビジョニング結果をテストする
                                                                        • メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ

                                                                          その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの

                                                                            メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
                                                                          • 【ハウツー】速攻解説! JUnit 4.4 - 新アサーションメソッド「assertThat」の用途とは | エンタープライズ | マイコミジャーナル

                                                                            18日(米国時間)、JUnitの最新版となるJUnit 4.4が公開された。JUnitはJavaで開発されたユニットテストフレームワーク。Common Public License Version 1.0のもとに公開されているテストフレームワークで、ユニットテスト用のフレームワークとしては事実上の標準。後発のユニットテストフレームワークに比べて扱いが難しいと批判されることもあるが、4系からはアノテーションを導入するなどしてシンプル化が進められてきた。4.4ではいくつか新機能が導入されているのでここで紹介したい。 新しいアサーションメソッドの導入: assertThat JUnitではテストを記述する方法としてアサーションメソッドを提供している。Assert.assertArrayEquals(...)などがそれにあたるもので、ほかにもassertEquals、assertFalse、ass

                                                                            • Capybara の README 意訳 - おもしろwebサービス開発日記

                                                                              注意 この訳はだいぶ古い(2011年7月時のREADME)です。最新版の訳をgithub上に載せたのでこちらをご覧ください。 はじめに Rails のエンドツーエンドテスト用のデファクトスタンダードプラグイン Capybara の README 意訳です。いつもと比べて直訳成分多めです。 テスト関連はどうにも日本語の情報が少なくて、覚えるのが大変ですね>< 概要 Capybara は Rack アプリ(Rails, Sinatra, Merb等)の統合テストを簡単にするのが目的です。Capybara は現実のユーザがウェブアプリとやりとりするのをシミュレートします。テスト用のドライバを選択できます。デフォルトでは Rack::Test と Selenium ドライバをビルトインでサポートしています。HtmlUnit, env.js は外部の gem としてサポートしています。 完全なリファ

                                                                                Capybara の README 意訳 - おもしろwebサービス開発日記
                                                                              • FactoryGirlのtransientとtraitを活用する - Qiita

                                                                                FactoryGirlでテストデータを定義する時に、transientとtraitを活用すると色々捗るという話。 transientは実際に作成するデータと直接関係無い新しいattributeを定義する機能。 そこで定義されたものは実際のmodelにはセットされないしattributes_forでも出力されません。 何のために使うかというと作成時に挙動を変更するためのフラグや追加データとして利用するのが一般的です。 traitは属性の定義を一纏めにして名前を付けられる機能です。 parentを指定したfactoryの継承とは違い、traitは単体ではfactoryとして機能しません。 あるfactoryの特定の状態に名前を付けて、付け外しできるようにする、というのが主な使い方になります。 例えば、あるfactoryをある時はadminある時は非adminで作りたい時等に有効です。 個人的に

                                                                                  FactoryGirlのtransientとtraitを活用する - Qiita
                                                                                • Chai

                                                                                  Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.