How to get Started with TDD
I also have created a tutorial for learning TDD. It's a bit larger than yours (a Tetris game) and has much more pre-written tests before it's time to write your own tests. Checkout the "tutorial" branch from http://github.com/orfjackal/tdd-tetris-tutorial and follow the instructions in the README file. This far I've used that as an exercise on one course (http://www.cs.helsinki.fi/u/luontola/tdd-2
和田卓人――TDD伝道師を生んだ読書会と「心の師匠」 － ＠IT自分戦略研究所
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 時代は、UMLが出始め、オブジェクト指向が全盛期を迎えたころ。大学生の和田氏はマーチン・ファウラー氏の著作『アナリシスパターン』に出合った。同時期、難解なことで有名なこの書籍を読もう、という読書会がオージス総研のWebサイト「オブジェクトの広場」で企画される。「参加してみよう」――これが、和田氏の読書会初体験となった。 2000年に開催されたこの「アナリシスパターン読書会」には、錚々（そうそう）たるメンバーが参加していた。『アナリシスパターン』の翻訳を担当した友野晶夫氏と児玉公信氏、オブジェクト指向開発の泰斗である藤野晃延氏や平澤章氏……。和田氏にとって、彼らは「雲の上の存在」だ
TestLinkメモ - 科学と非科学の迷宮
今週の金曜にShibuya.tracに参加しようと思います。 手ぶらで参加するのもあれなので、この3ヶ月ほどTestLinkを使って気づいたことをまとめようと思います。 使ったきっかけ テスターの要員確保してないプロジェクトで、いきなりテストしてくれって言われてどうしようかと悩んでいたときに、「そういや昔TestLinkってのをブックマークしたっけ」と思い出し、使ってみようと思ったのが始まり。 書き方メモ tracとの対応 tracのコンポーネントとトップレベルスイートを大体1:1対応させる。 trac上でタスクとして定義しているチケットごとにテストスイートを作成する。 テストケースには以下の内容を書く。 概要:対応するチケットへのリンク貼るだけでいい。補足説明いるなら追加。 実行方法:どのユーザでログインするか、どのブラウザを使うか、どのオブジェクトを対象にアクセスするかを明確に書く。例
【コラム】攻略! ツール・ド・プログラミング (13) JavaScript用のユニットテストフレームワーク「JsTestDriver」」 | エンタープライズ | マイコミジャーナル
JsTestDriverとは JsTestDriverはオープンソースで開発されているJavaScript用のユニットテストフレームワークである。JavaScriptの場合、通常は実行エンジンがWebブラウザに依存するため、ブラウザごとに個別にテストしなければならないという難点がある。JsTestDriverを使うことでその悩みは解消できるだろう。 JsTestDriverはWebサーバとして動作するフレームワークである。テストコードはJavaScriptで記述して指定されたディレクトリに配置する。WebブラウザからJsTestDriverの特定のパスにアクセスすると、そのブラウザがテストを実行する環境として登録される。Webブラウザは複数同時に接続しておくことができる。 実際にテストを実施すると、接続されているすべてのWebブラウザのJavaScriptエンジンそれぞれでテストコードを実
第1回 レガシーコード前夜 | gihyo.jp
はじめに 「レガシーコード」――この言葉を聞いて何を思い浮かべますか？ もしかしたら、COBOLで書かれたコード、Windows NT 4.0用のコード、書いた人がわからなくなってしまったコードなどが思い浮かぶかもしれません。 しかし、このレガシーコードをメインテーマとして正面から扱っている書籍『Working Effectively with Legacy Code』（WEwLC ※1）では、レガシーコードについて異なった見解を示しています。そう、「明日自分の書くコードもレガシーコードになるかもしれない」というWEwLCが発するメッセージは、私たちに切実に迫ってくるのではないでしょうか。 この連載では、WEwLC読書会の有志が、WEwLCが語りかけるものや、現実の課題への活かし方などを対談形式で紹介していきます。この本が発するメッセージについては連載の中でおいおい明らかにしていきたい
Software Testing Categorization
What kind of tests take under 1ms? And if you've got 100 functions, then are 20 tests per function enough to do something useful? Probably yes, but then who actually writes 20 test per function? (In another post you talk about people not knowing how to write, that is plan and design tests.) But you're right that fast is essential at the IDE. One way to turn slow into faster is to have tests run in
Webinar: How to Create Secure Test and Dev Environments on the Cloud | Amazon Web Services
AWS News Blog Webinar: How to Create Secure Test and Dev Environments on the Cloud Amazon Web Services, CohesiveFT, and RightScale will participate in a webinar titled “How to Create Secure Test and Dev Environments on the Cloud.” Along with Michael Crandell and Edward Goldberg of RightScale, Simone Brunozzi of Amazon Web Services and Patrick Kerpan of CohesiveFT will show you how you can save tim
Yet Another JavaScript Testing Framework
It is a very nice implementation of a great idea. Thanks for sharing! ReplyDelete Cool stuff! Do you have any information on writing tests against asynchronous APIs? I've made heavy use of jquery events for testing asynchronous calls with ScrewUnit, but I don't see anything here to cover that. I guess if jquery loads you could just use that on top of this. Speaking of ScrewUnit, if you came up wit
信頼性 - koichiro516の日記 - Land of Hope and Dreams
デバイスの信頼性の評価というのは、大事に大事に動かして○○時間動作を達成することじゃないんだよ。どうやったら壊れるかを見つけ出して、どうやったらそれを防げるかを考え出して、それをインプリメントすることによって信頼性を獲得することなんだよ。言い換えれば、デバイスをトコトンいじめ抜かなきゃならん。 で、デバイスが壊れるかもしれない要因＝ポテンシャルリスクに当たりをつけられるかどうかが、研究者・開発者の知識・経験がまず最初に試されるところ。もちろんその次はそれを防ぐ方法を考え出すところに知恵を絞る。 大事に大事に動かして長時間動きましたと言ったところで、顧客が顧客なりの使い方をすればすぐ壊れるし、その壊れるのを防ぐ、避ける方法を考えなければ陳腐な技術（＝研究者のオモチャ＝特許も取れない）のままで終わる。 と言うことを職場の若い衆に、つい熱くなり延々と話してしまったので、簡潔に書いておく。 ついで
TotT: Be an MVP of GUI Testing
Hi I enjoy the blog! HW IP verification has a lot of interesting tools and methodologies such as for instance constrained random testing. Another interesting aspect of this is that it enables metric driven verification since not only line and branch code coverage are measured but also functional and cross functional coverage. Another interesting aspect of this is that there are tools that inserts
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Properties of a good unit test: 柴田 芳樹 (Yoshiki Shibata)
「実演テスト駆動開発」 WEB+DB PRESS Vol.35特集 特設サイト
コミュニケーションとしてのレガシーコード
Google Code Archive - Long-term storage for Google Code Project Hosting.
Why are we embarrassed to admit that we don't know how to write tests?
なぜTDDとペアプログラミングで生産量が増えるのか
Recommended TDD Tutorials
Seasar Conference 2009 White にて 「テスト駆動開発のこころ」というタイトルで登壇させていただきました - t-wada の日記（旧）
書籍『Agile Testing』: 柴田 芳樹 (Yoshiki Shibata)
Article: JavaScript Test Driven Development with JsUnit and JSMock