【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
Webブラウザの操作をJavaScriptで自動化。Headless Chromeのフレームワーク「Puppeteer」がバージョン1.0に到達。ChromeのDevToolsチームが開発
UIを持たずスクリプトから操作可能なWebブラウザのHeadless Chromeを利用するためのフレームワーク「Puppeteer」がバージョン1.0に到達した。Webアプリケーションの自動テストなどに利用可能だ。 GoogleのWebブラウザ「Chrome」は、ユーザーインターフェイスを持たずコマンドラインやリモートデバッグ機能を通じてWebブラウザを操作できる「Headless Chrome」機能を備えています。この機能は2017年6月にリリースされた「Chrome 59」から実現されたものです。 Headless Chromeを利用すると人間がWebブラウザをマウスやキーボードで操作することなく、プログラムでHeadless Chromeを起動し、特定のWebページを読み込み、画面キャプチャの取得や、指定された場所をクリックし、値を入力し結果を取得する、といった操作を自動的に行わせ
【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法 - Qiita
【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法RubyRailsRSpec # トレーニングジムの予約システムを開発していると仮定してください 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)
初めての自動テスト
Webシステムの自動テストを始めたい方を対象に、自動テストの考え方やフレームワークを解説する書籍です。テストのピラミッドやユーザーインターフェイステストの概念など、基礎的な事柄から、レガシーシステムへのUIテストの追加、RESTfulなWebサービスのテスト、ブラウザ上のJavaScriptの挙動をユニットテストでテストする方法など、実践的な事柄までを豊富なイラストとサンプルを使って分かりやすく解説します。さらにテストファーストやモックの活用法、テスターに向けた自動テストのためのプログラミング基礎知識なども詳述。自動テストを書くためのノウハウを網羅した本書は、自動テストをマスターしたいエンジニア必携の一冊です。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では
--headless時代の本命？ Chrome を Node.jsから操作するライブラリ puppeteer について - Qiita
--headless時代の本命？ Chrome を Node.jsから操作するライブラリ puppeteer についてJavaScriptChromee2e puppeteer はHeadless Chrome をNode.jsで操作しやすくしたライブラリです。今日(※ 2017/8/17)一日で凄い勢いでGitHubのトレンド入りしており、TLでも話題になっていたので、早速触ってみました。 Node.jsでChromeを操作するというコンテキストにおいては、Nightmare.jsと同じレイヤに属するプロダクトですね。Nightmare.jsはElectronを介在させることで、Chromeの操作を実現していましたが、今年の5月にChromeでheadlessモードが利用可能になって以降1、headless Chromeを直接操作するライブラリが色々と出始めていますね。この系統は、chr
RSpecの入門とその一歩先へ ～RSpec 3バージョン～ - Qiita
はじめに 有名な初心者向けのRSpec入門記事として、和田卓人さん(@t_wada)の「RSpec の入門とその一歩先へ」という記事があります。 僕もRSpecを全く知らなかった頃に参考にさせてもらいました。 今読んでもとても素晴らしい資料なのですが、RSpecのバージョンが古く、現状の書き方とマッチしなくなってきているのが少しもったいないところです。 そこで、この記事では和田さんの記事をRSpec 3バージョンに書き直してみようと思います。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション(本記事) 第2イテレーション 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter1 本記事のライセンスについて 本記事は クリエイティブ・コモンズ 表
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
RailsのRESTful APIをテストで理解する - ワザノバ | wazanova
http://www.commandercoriander.net/blog/2014/01/04/test-driving-a-json-api-in-rails1 comment | 0 pointsPivotal LabsのEno ComptonがRailsでJSON APIをテスト形式で理解できるように紹介してくれてます。「Railsアプリをてがけると、いずれ、シングルページアプリ、モバイルクライアントのためにRESTful APIが必要になるだろうから練習用に。」ということで、コードはGithubで公開されています。 GET /movies POST /movies GET /movies/:id PUT /movies/:id DELETE /movies/:id 上記のrouteをサポートするために、Railsアプリ + RSpec + FactoryGirlを用意したら、
puppet-lxc-test-box - Gosuke Miyashita
新たな Puppet のベストプラクティスを求めて、マニフェストの大規模なリファクタリングを行っています。 で、リファクタリングするからにはテストが必要だよね、ってことで、rspec-puppet でテストを書いてるんだけど、rspec-puppet はマニフェストがコンパイルされた「カタログ」というものに対してテストするもので、実際にマニフェストを流し込んだ状態が正しいかテストするわけではないので、これだとテストとしては不完全。 というわけで、Test Kitchen みたいに、同時にいくつも VM を立ててテストを走らせる、ってなことをやりたいんだけど、会社では KVM ベースの VM を利用してるので、VirtualBox ベースの Vagrant は使えないし、そもそもテストを動かす大元のホストも VM なので、VirtualBox どころか KVM も利用できない。 なので、まず
不具合にテストを書いて立ち向かう - t-wadaのブログ
テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか？ 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
時計オブジェクト（ドメインクロック）を導入してテスト容易性と意図性を高める
現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。 <?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オブジェクトの生成部分をメソッドとして抽出し、そのメソッド
require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー
先日書いた自分用アプリケーションのひな形 http://d.hatena.ne.jp/naoya/20130503/1367581629 http://d.hatena.ne.jp/naoya/20130504/1367640512 これに、JavaScript のテスト環境も追加したい。 結論からいくと、フレームワークには mocha + expect、ランナーは testem を使うことにした。ついでにテストダブルライブラリとして Sinon.js も有効にした。 ちなみに今回の文脈は End to End のテストではなくてユニットテスト周りのおはなしです。 mocha + expect JavaScript のこの辺のテスト周りは今もいろいろなツールの整備が進んでいて、今回採用した以外にも Jasmin や QUnit そのほか色んな物がある。昨今の状況に関しては 先日の HTML
RSpecのshouldはもう古い！新しい記法expectを使おう！
というように書くようになりました。 別にshouldを使った記法がなくなったわけではありませんが、 https://github.com/rspec/rspec-expectations のREADME.mdには、もう新しいSyntaxの説明しか載っていないし、今後はexpectの方を使っていくほうがいいでしょう。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax には、新しいSyntaxを導入した背景が説明されています。 簡潔に書くと、shouldだとBasicObjectを継承したクラスのテストを書くときに不具合が起こるみたいですね。 移行方法 基本 基本的には、上に書いたように、 foo.should を expect(foo).to に foo.should_not を expect(foo).
CI as a Service ブラウザを使ったJavaScriptのテストをCIサービスで動かす方法のまとめ
Travis CIを始めとするウェブサービスとして使えるCIを使って、 JavaScriptのブラウザテスト(ブラウザ上でJavaScriptを走らせて行うユニットテスト)をやる方法をサービスごとにまとめてみました。 テストフレームワークとして Buster.JS を使用して行います。 Karma (旧Testacular) では公式サイトにも Karma – Travis CI でCI Serviceとの連携方法が記載されているのでそちらも参考にして下さい。 今回紹介するCI Servicesは以下のものです。 Travis CI drone.io BuildHive Jepso CI テスト実行の流れ Jepso CI を除いては、テスト実行の流れ自体は同じなので先に解説します。 Capture用のローカルサーバを立てる テストしたいブラウザで capture URL へアクセスする
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
timecop のちょっと便利な書き方について - おもしろwebサービス開発日記
みなさん、 timecop 使ってますか？timecop は、テストで時間を扱う時に必須と言えるライブラリです。テスト中の時間を止めたり(Timecop.freeze)時間を移動させたり(Timecop.travel)できます。似たようなライブラリとして delorean があります。RailsCasts でも紹介されています。 さて、timecop の README には下記のようなコード例が書いてあります。 t = Time.local(2008, 9, 1, 10, 5, 0) Timecop.travel(t) 僕はこれまで上記のように書くしか方法が無いと思っていたのですが、今日下記のようにも書けることに気づきました。 Timecop.travel(2008, 9, 1, 10, 5, 0) また、ブロックを使うこともできます。 Timecop.travel(2008, 9, 1,
RSpecとCapybaraでJavaScript/Ajaxをテストする
さて、このRailsアプリケーションがJavaScript/Ajaxを利用していて、「span#touchmeをクリックしたら、p#messageの中に動的に「Hello!」というテキストが現れる」という仕様であった場合は、どうテストすればよいでしょうか。単にa#touchmeをspan#touchmeに変えるだけではだめです。CapybaraはJavaScriptを理解しないので、テストは失敗します。 ここで登場するのがcapybara-webkitというドライバです。WebKitはオープンソースのHTMLレンダリングエンジンで、Google ChromeやSafariがこれを使っています。このドライバを使えばJavaScriptのテストが可能になります。 capybara-webkitをインストールするには、例によってGemfileに gem "capybara-webkit" と書い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Test Yourself - テストを書くと何がどう変わるか
