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

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

RSpecで、メソッドを通ったかどうかを確認する方法です。receive matcherを利用するのですが、ちょっと癖があるので注意が必要です。 /users/show/:id にアクセスした時にUserのupdated_atを更新する処理をするコードのSpecの例はこんな感じです。 [users_controller.rb] class TourTeamsController > ApplicationController def show user = User.find params[:id] user.touch if user.present? end end [users_controller_spec.rb] require 'spec_helper' describe UsersController do describe ‘GET show’ do let(:user)

はじめに タイトル通り、RSpecにてRakeのテストを書く方法についてです。RSpecからRakeを呼び出す方法は、普通のModelやControllerのメソッドを呼び出すのとは異なっていたので、備忘録として残しておきます。 対象となるRakeとRSpec 1.Rake テスト対象となるRakeは以下の通りです。2つのtaskがあり、片方は引数なし、もう片方は引数を受け取ります。それぞれのtaskでは、別メソッドを呼び出しているだけの簡単な処理です。 /lib/tasks/start.rake namespace :start do task :exec_no_args :environment do SampleController.exec_no_args end task :exec_with_args, :arg_hoge task :exec_with_args => :en

JaSST Tokyo 2022 「アジャイルソフトウェア開発への統計的品質管理の応用」の発表資料です。（2022/03/10） http://jasst.jp/symposium/jasst22tokyo/details.html#C4 もはやふつうとなったアジャイル開発ですが、定量的な品質説明の方法が未だ確立されていないために、アジャイル開発の導入を見送る場面もたびたびみかけます。 そこで、ウォーターフォール開発で用いられてきた統計的品質管理の技法を再確認し、アジャイル開発への応用と検証を試みました。 ウォーターフォールとは異なるアジャイル開発の品質管理や品質メトリクスについて、試したことやその結果から考えたことをお話しします。

なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として　同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。　というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. I've recently finished watching the Autumn of Agile screen

先日、 Cafe.Testing で ソフトウェアテスト実践ワークブック の演習2をやりました。そこで話題になったのですが、「どうやって仕様書にないものを思いつくか？」ということです。他にもたくさんあって不十分な部分はあるのですが、そこで話した内容をメモがてら書いておきます。また、こういったことに興味があったり聞いたり話したりしたい人はきてもらえるとうれしいです！ Cafe.Testing - connpass ソフトウェアテスト実践ワークブック 作者: レックス・ブラック,成田光彰出版社/メーカー: 日経BP社発売日: 2007/01/18メディア: 大型本 クリック: 1回この商品を含むブログ (4件) を見る 発端 この書籍を持っている人はわかると思うのですが、演習2の回答例にはミドルウェアやハードウェアが起因でソフトウェアが動かなくなるようなテストケースはなかったりしました。 あと

テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う

テストエンジニアという奇異な立場にいる。 普通にプロダクトメンバーの一員だが、プロダクト自体のコードはあまり書かず、品質という観点から良かれと思ったことをする。大体グーグルのテスト本に載っているSETをロールモデルとしている。 テストから見えてくる グーグルのソフトウェア開発 作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘出版社/メーカー: 日経BP社発売日: 2013/05/23メディア: 単行本この商品を含むブログ (8件) を見る SWTは、例えばエンジニアがテストを書きやすいようにライブラリを作ったり、テストがリリースのネックにならないように高速化したり、手動テストを支援するようなサポートツールを作ったりするのが役割となる。普通に単体テストも書く。（が、それはあまり理想ではなくて、本当はそのコードを書いた人が単体テストも書くべきだ。） しかし、現

Mockery is a PHP extension that offers a superior mocking experience, particularly when compared to PHPUnit. While PHPUnit's mocking framework is powerful, Mockery offers a more natural language with a Hamcrest-like set of matchers. In this article, I'll compare the two mocking frameworks and highlight the best features of Mockery. Mockery offers a set of mocking-related matchers that are very sim

Unit testing is often talked about in software development, and is a term that I've been familiar with during my whole time writing programs. Like most software development terminology, however, it's very ill-defined, and I see confusion can often occur when people think that it's more tightly defined than it actually is. 1 Although I'd done plenty of unit testing before, my definitive exposure wa

現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。 <?php ... class OrderService { ... public function order(Order $order) { $currentHour = (integer) (new \DateTime())->format('H'); if ($currentHour >= 10 && $currentHour < 21) { ... } else { throw new OrderException('ご注文は午前10時から午後9時まで！'); } } ... 実際の現在の時刻に依存せずにif文の条件をテストする1つの方法は、DataTimeオブジェクトの生成部分をメソッドとして抽出し、そのメソッド

初登場の @tototoshi です。今回は pixiv のユニットテストで利用しているモックライブラリの紹介をします。 ここ2ヶ月くらいの間、レガシー化したとあるモジュールのリファクタリングに取り組んでいました。 リファクタリングにはテストコードが必須です。しかし今ではすっかりテストを書く文化が根付いている pixiv にもテストコードがない時代がありました。リファクタリングが必要な古いコードにはテストコードがないことが多く、そういったコードに新たにテストをつけていくのはなかなか大変です。テストの概念のないプロジェクトはテスト可能なように設計・実装されていません。テストを書くのが大変なのではなく、書けるようにするまでが大変です。 特にやっかいだったのは DB を参照したりするようなスタティックメソッドを使ったメソッドのテストでした。以下のようなスタティックな Dao を使用した Serv

個人的に趣味で Chrome Extension の開発をしていますが、最近いろいろとノウハウも溜まってきたので Chrome Extension の CI について少しまとめてみようと思います。 目次 はじめに Chrome Extension のテストを書く 何をテストするのか テストフレームワーク Jasmine のインストール Jasmine でテストを書いてみる JavaScript APIs をモックする HTML Fixture を読み込む Chrome Extension のテストを実行する テストランナー Karma Karma のインストール Karma でテストを実行する ファイルの変更を監視する コードカバレッジを出力する HTML Fixture を読み込む Chrome Extension を CI する CI サービス Wercker Wercker にリポジ

Carl Alexander, Giuseppe Mazzapica, Thorsten Frommen: An Introduction to Unit Testing (for WordPress) WordCamp Europe 2018Speakers: Carl Alexander, Giuseppe Mazzapica, Thorsten Frommen August 13, 2018 — This is a development-specific workshop, so you should have an idea about coding in general. Besides that, the workshop itself does not require any specific skill or knowledge. We’ve all had these