実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜 / ATDD by genba example
ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。 PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。 トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。 ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テス
10年目を迎えたBDDツールCucumber - 作者のAslak Hellesøy氏に聞く
Cucumberは、プロジェクトチームの非技術メンバと技術メンバの両方を対象に、不明確な要件や誤解を克服する手段として開発された。しかし、もしもCucumberがテストツールだと考えているのならば、それは誤りだ — 2008年にCucumberを開発したAslak Hellesøy氏は数年前、このように述べていた。InfoQとのインタビューで氏は、振る舞い駆動開発(BDD)とCucumberを使用した自身の経験と、10年目を迎えた同ツールの今後について説明してくれた。 InfoQ: 現在のCucumberと振る舞い駆動開発(BDD)との関係性について、簡単に説明して頂けますか？ Aslak Hellesøy: Cucumberは、TDD(テスト駆動開発)の一種であるBDDをサポートするツールです。BDDでは、テストは*すべて*ユーザによる受け入れテストです。技術者でないステークホルダでも理
C++ の BDD-Style なテストフレームワーク igloo を使ってみた - WebService::Blog->new( user => ’hide_o_55’ )
C++ のテストフレームワーク igloo を使ってみました。 Loading... igloo の特徴 ヘッダファイルのみなので導入が楽 iglooはヘッダファイルのみで構成されているため、テストフレームワーク自体のコンパイルが必要ないので導入が簡単でした。iglooのソースはgithubにあるので、 git submodule https://github.com/joakimkarlsson/igloo extlib/igloo のようにして、"extlib/igloo" をインクルードパスに含めるようにするだけです。 Travis-CI などのCIサービスで使うのも簡単です。 BDDスタイルでテストを書ける BDDスタイルでテスト/サブテストを書くことができます。これによりテストが構造化され、テストコードの見通しが良くなります。スタイルは以下の3つが使用できます。 Context/
Groupon: Node.js向け結合テストツールtestiumをオープンソースで提供 - ワザノバ | wazanova
https://engineering.groupon.com/2014/misc/i-tier-testium/1 comment | 0 pointsGrouponが、Node.js向けの結合テストツールtediumをオープンソースとして提供しました。 What is testium BDD (振舞駆動開発) 構文で書ける。 CoffeeScript/JavaSacriptで書かれている。 同期APIがある。 Seleniumを利用できる。 Why Create a New Tool RailsではCucumberをセットして、実際のブラウザでSeleniumを使ってテストができたが、Node.jsではフィットするものが見つからなかった。 Exploring WebDriver 既存のSeleniumのインフラを利用するために、JavaScriptとMochaで書けて、同期APIのある
Serverspec - Home
About V2 Serverspec/Specinfra v2 has been just released. See the document about v2. About With Serverspec, you can write RSpec tests for checking your servers are configured correctly. Serverspec tests your servers’ actual state by executing command locally, via SSH, via WinRM, via Docker API and so on. So you don’t need to install any agent softwares on your servers and can use any configuration
Puppet や Chef で構築したサーバを RSpec でテストする - Gosuke Miyashita
追記 ここに書いてあることを実現する serverspec という gem をつくりました。詳しくはこちらのエントリで。 Puppet マニフェストをリファクタリングするからテスト書くぞ、ってことで、 puppet-lxc-test-box に書いたように、テストするためのシステムコンテナを簡単に作る仕組みをつくったので、今度は実際にテストコードを書くためのベースをつくってみた。 rspec-lxc-test-box こんな感じでテストが書ける。 require 'container_spec_helper' describe 'nrpe' do it { should be_installed } it { should be_enabled } it { should be_running } end describe 'nagios-plugins-all' do it { shou
PhantomJSとJasmineで振る舞い駆動開発なJavaScriptテスト
PhantomJSとJasmineで振る舞い駆動開発なJavaScriptテスト：フレームワークで実践！ JavaScriptテスト入門（2）（1/3 ページ） しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載 前回は、JavaScriptテストの基本、今回からフレーワムークを紹介 前回の「JavaScriptテストの基礎知識と使えるフレームワーク6選」では、JavaScriptのテストを取り巻く環境や、JavaScriptのテストに使用できるフレームワークの紹介を行いました。今回からは、前回の記事で紹介されたフレームワークを使用して実際にJavaScriptのテスト環境を構築し、テストを行うまでの流れを解説します。 今回は「PhantomJS」と「Jasmine」を取り上げま
バーチャルパネル: コードとテストの比率、TDD、BDD
JB:この件について一般化するのは嫌なので、私がTDD/BDD使うときとその理由を説明させてください。 私が初めてTDDに出会ったのはミス(欠陥といってもバグといってもいいでしょう）を防ぐ方法を求めていたからです。プログラム上の多くのミスのおかげで私は完璧さの感覚を失ってしまいました。どんなことを成し遂げても仕事が完璧に近づいたと感じたことはありませんでした。そして、書いたコードをテストすれば、ばかげた小さなミスを見つけ修正できるのではないかと考えました。テストをしてミスを見つけたかったのは、愚かにみられるのを防ぐためというより、仕事に対する完璧さの感覚を失わないようにするためです。実際テストは役に立ちました。数年経って、TDDはコーディングのミスを防ぐのに役に立つだけでなく、デザインの失敗を防ぐのにも役に立つことに気づきました。そしてBDDを学び、どのような機能を実装するかについての失敗
DailyJS: Getting Started with the Chai Assertion Library
Jake Luer is a Node developer and consultant focused on helping to shape the next-generation of mobile and web applications. He is logicalparadox on GitHub and @jakeluer on Twitter. Chai (GitHub: logicalparadox / chai, npm: chai, License: MIT) is a BDD / TDD assertion library for Node and the browser that can be delightfully paired with any JavaScript testing framework. Chai aims to be an expressi
『ビルド・リリース自動化への足掛かりとしてのGroovy・Gradle・Spock』
はじめまして！Ameba事業本部プラットフォームDivでアプリケーションエンジニアをしている池田(@yukung)です。 私は2011年5月に大手SIerから転職し、サイバーエージェントへ入社しました。前職では主に金融業界をターゲットにしたBtoB向けのシステム開発に多く携わってきましたが、開発作業の中でこんな経験を割とたくさんしてきました。 ・ソースコードやドキュメントの管理にバージョン管理ツールを使わずに、Hoge_yyyyMMdd.javaとかDB設計_yyyyMMdd.xlsみたいなファイル管理をしてどれが正しいドキュメントかわからなくなりカオスになる ・ソースコードの静的チェックツール（CheckStyleやFindbugsなど）を使わずに、目視と気合でひたすらソースコードレビューする ・Excel表で書かれたテストケースを睨みながら、手でケースに沿ったオペレーションをしてデバッ
ちょっとの手間でRSpecの出力をキレイにするためにnamed_letというのを書いてみた - ( ꒪⌓꒪) ゆるよろ日記
RSpecの話です。 RSpecは、テストコードがそのまま仕様を記述するドキュメントになる、というのが大きな利点の一つです。 しかし、rspecコマンドに-dオプションを渡して出力されるドキュメントは、必ずしも読める文章になっているとは限りません。 例として、以下のようなCanCanのspecを見てみます。 require 'spec_helper' require "cancan/matchers" describe Ability do context 'an user' do let(:user) { Factory.create(:user) } let(:article) { Factory.create(:article) } let(:own_article) { Factory.create(:article, :user => user) } subject { Abil
テストフレームワーク mocha - hokaccha memo
JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの
Titanium Mobile + Jasmine + Jenkins でiPhoneアプリの自動テスト組んでみたよ - ikeike443のブログ
Jenkins Advent Calendar jp 2011の3日目です。 Titanium Mobile + Jasmine + Jenkins でiPhoneアプリの自動テスト組んでみた、っちゅう話をします。 本当はプラグインを作りたかったんですが、そこまで行かなかったので（言い訳だよ！）、せめて自動テストをどう組んだかの話をしますね。 Titaniumの自動テストを組みたい 最近Titanium Mobileを使ってiPhoneアプリなど作ってます。 Titanium Mobileについてはもう説明もいらないと思いますが、Javascriptを使ってスマートフォンアプリ（特にiPhoneとandroid）を開発することができるプラットフォームですね。 で、Jenkins野郎な私としては、Titaniumでも自動テストを組みたいんですよね。 Javascriptでテストってどう書くん
BDDについて自分なりにまとめてみた - UKSTUDIO
BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振
PHPでBDD（Behavior Driven Development）する方法
みなさんこんにちは。@ryuzeeです。 RubyであればRSpecやCucumberとか使って、むしろBDDしているケースの方が多いようですが、PHPでやっている事例はあまり聞きません。 とりあえずPHPでもBDDできることは確認できたので、その方法をご紹介します。 ※実戦投入にはもうちょっと検証は必要かもしれません。 BDDとは？BDDとはビヘイビア駆動開発（Behavior Driven Development）でテスト駆動開発から派生したものです。 テスト駆動開発とドメイン駆動設計を統合したようなイメージになります。 対象における「振る舞い」や「制約条件」の検証のために、自然言語的な記述でテストコードを記述します。 スペックファーストで仕様を作ってから実装するという流れになります（コードを書く前に振る舞いを決める）。 ということで、以下ではPHPでBDDを行う方法について解説してい
RSpec のすごいところ - kなんとかの日記
(注: 以下の内容は、RSpec ユーザの間で広まっていることでもなく、もちろん RSpec 開発チームの公式な見解でもなく、あくまでワシの個人的な見解です。) RSpec のすごいところは、コードに対してではなく仕様に対してテストを書くことを明確にしたことだと思う。何を今さらと言われそうだけど、今さらになってようやく気づいたニワトリ頭ですまんかった。 ワシも最初は、「assert_equal(expected, actual)」のかわりに「actual.should == expected」と書くかっこよさに目を奪われて、テストコードを自然言語に近い形で記述するのが RSpec のすごいところだと勘違いしてたし、それが「TDD (Test Driven Development)」から「BDD (Behaviour Driven Development)」へという新しい潮流だと勘違いしてた
Twist 2.0は振る舞い駆動の協力的なテストを支援する
原文(投稿日：2010/04/05)へのリンク ThoughtWorks StudiosはTwistの最新バージョンであるTwist 2.0をリリースした。Twistはアジャイルテスト自動化ツールだ。Twist 2.0はテスターや開発者、ビジネス分析者が協力してテストすることを支援する。振る舞い駆動開発(BDD)とドメイン特化言語(DSL)の技術を使ってテスト自動化を実現し、動的言語であるGroovyを使ってテストスクリプトを書くこともできる。 Twistは再利用可能なテスト自動化スクリプトを作成するユーザインターフェイスを提供する。このスクリプトは手動テストでも自動の機能テストでも利用できる。また、テスト実行記録をプロジェクトやチームを横断して可視化する。最新バージョンの特徴は、 ハイブリットなテスト拡張: 手動テストと自動テストの各ステップで同じテストシナリオで実行できます。これによっ
現実のプロジェクトでのCucumberの始め方 - moroの日記
セッションが終わったあと、Ask the speakerに来てくださった方((お名前を聞いておけばよかった!!)と少しお話しました。Cukeに興味が湧いたので使い始めてみたい、というとても嬉しいことをおっしゃってくださいました。 そこで話した、「すでに始まっているプロジェクトでのCuke導入法」を簡単にご紹介します。今回の私の話や、その他いろんなコトで興味を持った方の参考になれば嬉しく思います。 新規でも途中でも、プロジェクトに導入するときのポイントは、「ムリをしない」「一歩ずつ」ですが、特に開発が始まったあとから入れる場合は、簡単なところからやっていくとよいでしょう。具体的には、 1. (ログインなどもいらない)GET系の画面(index or show) まずは、アプリケーションにCukeを組み込んで、一週回すことに集中します。script/generate cucumberをしたら、
ユーザストーリーから始めるTDD - ヱビスブログ
ヱビスブログ :: ユーザストーリーから始めるTDD TDD from starting from user stories - a top-down styleを日本語でザックリまとめました。 意味を明らかに取り違えているようなところがありましたら指摘してください。 ------------- TDDのルールは最初にテストを書く事だ。現実世界のプロジェクトの多くは、ソフトウェアがGUI、Web、データベースや外部システムとの依存を含んでいる。大概これらはJUnitクックブックのサンプルほどシンプルではない。プロジェクトが異なれば、TDDの実装方法も異なる。例えばテスターが受け入れテスト記述の責務を取り、開発者はユニットテストを書く。TDDer向けにユーザストーリーから始めるトップダウンなTDDスタイルを提唱したい。 ユーザストーリーから始めるTDD What? ユーザスト
BDDIntro
2 問題 テスト駆動開発(TDD)は今や広く受け入れられている。大企業は自社のプログラマに、多くのコストを掛けてTDDを教育している。カンファレンスでTDDは人気のトピックだ。アジャイル系はもちろん、それ以外でも。 TDDについての書籍も何冊か出版されている。筆者(Dave Astels)自身の著作はJolt awardを受賞した。では、何もかもがうまくいってると言えるのだろうか？ TDDを実践している人々全てが、TDDについて深く理解し、TDDの恩恵を最大限に受けていると言えるのだろうか？ んなこたぁない！ TDDの本当の姿を正確に理解している人を私はごくわずかしか知らない。要するにTDD実践者の多くは、TDDの恩恵を最大限には受けていないのだ。何がまずいのだろうか？ 2.1 テスティングが焦点 さて...なによりもまず、みんなTDDはテスティングだと考えている。TDDはそれだけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
