2017/12/10 システムテスト自動化カンファレンス2017-2 「GebとSpockではじめるシステムテスト自動化」
「TDDはじめて物語」 #tddbc
2017/12/10 システムテスト自動化カンファレンス2017-2 「GebとSpockではじめるシステムテスト自動化」
最近行ったTDDの講演や寄稿について - t-wada の日記（旧）
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
RSpec の入門とその一歩先へ、第2イテレーション - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第2イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 #coffee.rb の写経会に招かれた(というよりは押しかけた?)ので、先日の RSpec チュートリアルの続きを記します。このエントリは写経会に参加しながらのライブ更新でした。 (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 前回終了時点のコードと実行結果 前回終了時点でのコードを以下に記します。 message_filter.rb class MessageFilter def initialize(word) @word = word end def detect?(text) text.include?(@word) end end message_filter_spec.rb r
軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ
これは、TDD Advent Calendar jp:2012 の16日目のエントリーです。前日のエントリーは、@pocketberserkerさんの「Specs2のParameterized Testのはなし」でした。 ご存じの方も多くなっていると思いますが、「テスト駆動開発（以下、TDD）」とはテストコードを先に書くテストファーストを基盤とした開発手法です。先にテストコードを書く事により、これからどのようなプロダクションコードを書こうとしているかを明確にすることができることが特徴です。このため、テストの技法というようりは設計の技法です。 テスト駆動開発を実践することにより多くのメリットを得ることができます。このことは2011年のAdvent Calendarで言及しました（TDDを学ぶべき10の理由 #TddAdventJp）。TDDは簡単に導入することができる一方で、実践するのは非常
実践TDD! テスト駆動開発入門
となっています。実際にどんなことをやるかは後ほど触れていきます。 それでは、始めていきましょう！ * QUnit導入 まずはQUnitを使うべく、以下のHTMLとJSを用意しました。 index.html <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>QUnit Example</title> <link rel="stylesheet" href="http://code.jquery.com/qunit/qunit-1.10.0.css"> </head> <body> <div id="qunit"></div> <script src="http://code.jquery.com/qunit/qunit-1.10.0.js"></script> <script src="tests.js"></script
TDD Boot Camp(TDDBC) - TDDBC大阪3.0/課題
用語集 http://devtesting.jp/tddbc/?TDDBC%E4%BB%99%E5%8F%B002%2F%E8%AA%B2%E9%A1%8C%E7%94%A8%E8%AA%9E%E9%9B%86 対象 飲み物自動販売機 Ver 2.0 課題を解くにあたって大事な事 課題を全部解くのを目標するのではなく、ワークショップの学習成果を最大化するように心がけましょう！ ペアプロはこまめに交代するようにしましょう！10分ぐらいが目安です！ TDDは「きれいで動くコード」を目指します。必要に応じて各自独自にリファクタリングを心がけましょう！ 課題の箇条書きはTDDのRED->GREENの１サイクルに対応している訳ではありません。やりやすいように仕様を整理・分割して、スモールステップで進めましょう オブジェクト・モジュールはこまめに分割しましょう（たとえば自販機、在庫管理、金銭管理という
TDDの準備としてのサンプルコードテストのすすめ
//主にJSのTDDを想定してますが、JSに限らないと思うのでTDDとしてます。 TDDでコード書くのは色々はかどっていいけど、TDDしたことない人がいきなりTDDから入ると挫折する可能性が高いのでおすすめできない。 TDDでコードを書くには「テストフレームワークに関する知識」、「テスト手法に関する知識」、「テスト対象に関する知識」が必要なので、以下の順番で進めていくといいと思う。 1. サンプルコードをテスト形式で書く 最初はライブラリやアプリ自体の主要な機能を説明したサンプルコードをテスト形式で書こう。 サンプルコードの目的は主要な機能の説明なので、テストは簡単なほどいい。 まずはテストフレームワークに慣れるのが目的なので、こったテストを書く必要はないし、よく分からなければ「実際こうは動かないけど」と断った上でテストっぽくコードを書いてもいい。 とにかくまずは普通にコードを書いて、その
テスト駆動開発は戦略である - 偏見プログラマの語り！
本稿は、前回の記事 『テスト駆動開発について僕は誤解していた』 を踏まえた上で僕が TDD について思うことのまとめです。 どうも TDD は「あらゆる開発現場で適用できる」「大掛かりな仕掛けは不要である」「やった方が良いらしい」ことが見えてきました。ということは、世間は「TDD を実践するのが当たり前」になっているはずです。しかしどうもそうなっていないようです。何かがおかしい気がします。 Siri に聞いてみましたが教えてくれませんでした。 1. 手間がかかるから実践されていないのだろうか。 テストコードを書く手間はゼロではありません。お金儲けをしている以上、かける手間は少なければ少ないほど良いわけですよね。「手間がかかるからやらない」という意見はありえそうです。もしかして、これがネックになっているのでしょうか。 2. みんながやってないから実践されていないのだろうか。 前回の記事を書い
the rspec book - Chapter 12 Spec::Example その１ - おもしろwebサービス開発日記
The RSpec Bookを読んでの自分用メモです。サブアカの方にメモっていこうかと思いましたが、RSpecの情報はあまり世に出ていないけど需要はありそうな気がしたのでこっちに書きます。意訳と感想がごっちゃになっているし、自分が知ってる情報については省略しているので見づらいかもしれませんがご了承ください。 今のところ本の全部についてメモしようと思っていますが飽きたら終わります。あと順番も適当です。 基礎知識 BDD用の言葉とrspecのメソッドの対応でこんがらがるのでメモ describeメソッド example groupを定義するメソッド itメソッド exampleを定義するメソッド shouldやmatcha expectationを定義するメソッド DSLを使うメリット RSpecはDSLでテストを書いていく。code exampleを(describeやitを使わずに)クラス
かっこ悪くて面倒でもテストコードを書こう - 今川館
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
例で覗くテスト駆動開発(TDD)
テスト駆動開発(Test-Driven development = TDD)については、以前からTest Firstという名で知っていましたし、実践しようともしていたはずなのですが、Kent Beckの"Test-Driven Development by Example"を読むまでは、やっぱりわかっていなかったような気がします。 それでは今ならわかっているのかというとそれも心もとないので、自分の理解を確かめるためにもmini Test-Driven Development by Exampleを書いてみることにしました。 使用している言語はRubyです。私はRubyが得意なわけではないのですが、Rubyなら処理系によるエラーメッセージの違いやIDEの操作方法の違いに惑わされずに済むかもしれないと思いRubyにしてみました。必要最低限の説明は入れましたのでRubyを良く知らない人でもわかっ
逆引きソフトウェアテスト関連技術まとめ - >& STDOUT
「Software Test ＆ Quality Advent Calendar 2011」の8日目。アドベントカレンダーということで、普段と少しトーンを変えてソフトウェアテストにあまり造詣のない方へ向けて何か役に立つ記事を考えてみました。先の記事でも述べたとおり、ソフトウェアテストの関連技術を表す用語はそれが何に使えて、何に役立つのか、門外漢にはとってもわかり難いので、そちらを軸にした紹介があると便利かもしれないということで、関連技術を目的別に整理し、参考になる記事や資料にリンクする形でお届けします。 テストの戦略を定めたい ソフトウェアテストプロジェクトの最上流工程と考えられているテスト分析の方法論です。プロダクト、プロジェクトに対してそれぞれ独自の方式で戦略を検討します。テスト計画と一部被る部分もありますが、プロジェクトの予算やスケジュールをひとまずおいて技術的な視点から本当に必要な
理想のJavaScript入門書 - L'eclat des jours(2011-12-08)
_ 理想のJavaScript入門書 アスキーの鈴木さんから、テスト駆動JavaScriptをいただいた。 これは、実に良い。おれが考える理想のJavaScript入門書に限りなく近い（というか、おれが書くより良いから上方向から近い）。 まず、これはTDDの本であり、JavaScriptの問題点は、それがRubyなどのスクリプト言語より、固いプログラミング言語（JavaとかCとか）に近い構文を持っているのが原因だと思うけど、どうしても変数とか関数名とか長く書きたくなるし（これは不思議な心理的な要求による）、言語が持つ予約語自体が長いし（functionだよ）、つまりいやでもタイプミスして死ぬ。 どうすれば良いかといえば、解決方法は2つしかない。プリプロセッサを用意して未定義変数とか利用していないかチェックするか、あるいはテストするかだ。前者よりも後者のほうがまあ有意義だ。というわけで、TD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Test driven node.js
Test Yourself - テストを書くと何がどう変わるか
PerlでTDD(テスト駆動開発)するなら覚えておきたいCPANモジュール群 | hirobanex.net
Shared examples: Variables can be set using a block
TDDBC横浜に参加しました - 223 Software
TDD研究会 デブサミ2012 コミュニティLT
