BDD on Haskell チュートリアル その1 : HUnit で TDD を
すこし日が空いてしまったけど，BDD on Haskell チュートリアルの続き． 前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 今回は HUnit を使って，基本的な TDD (BDD でなく) の進め方について． 例 商と，小数の余剰を返す関数 を定義してみる今回のチュートリアルで適当に「ある程度需要があって，あるとそれなりに便利なもの」として，Scheme の RSR6 で採択された div mod をやってみる． Haskell の mod についてHaskell の標準実装である mod rem は整数型しか受付けず，また返りも整数型なので，たとえば，Javascript や Ruby のように小数の余剰を返すことは無い． $ ghci Prelude> :t mod -- mod
C言語でもレガシーでも、TDD をやってやれないことはない(レガシーコード改善成分90%、TDD成分10%) - yujioramaの日記
id:goyoki さんの次になるTDD Advent Calendar jp: 2011の9日目です。 まったく自重しない素敵エントリが続いているので、ここらで息抜きをしましょう。 TDD についての理論、情緒、実践についてはすでに語られてしまったので、現場で使われた話を書きたいと思います。 前提 このお話は フィクション です。 現実によく似た光景を見たり聞いたりしたとしても、それは幻想です。幻想のはずです。幻想ということにしてくださいお願いします。 はじめに そこには C 言語のシステムがありました。 規模にして数万行の中規模なシステム。 24時間365日動き続けることが要求されるもので、僕の仕事は、このシステムの中枢部をうまいこと改修することでした。 テストコードはあるものの、設計に大きな変更が入る前のプロダクトコードが対象となっていて、ユーティリティ関数以外のテストは全滅という、
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
TDDのはじめかた #TddAdventJp - 千里霧中
本エントリはTDD Advent Calendar jp: 2011の12/8の担当分の記事で、id:t-wadaさんの「右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記」に続くものです。 はじめに TDDはシンプルな原則に則った手法ですが、とっつきの悪さもしばしば持たれがちです。また一連のTDD Advent Calendarで起こった議論や会話の中でも、TDDの始め方はどうすれば良いかという話が散見されましたので、自分の担当枠では「TDDのはじめかた」についてまとめたいと思います。なお紹介するのはあくまで数ある入門方法のうちの１つです。たぶん他にも色々な良い入門方法があると思います。 全体像 紹介する入門方法は以下のようなステップバイステップの構造となります。 いつでも軽快に使えるユニットテスト環境を構築する 必要と感じたらすぐテストを活用する テスト並行を
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
Ubuntuでもコードやテストを保存したら自動でPHPUnitを実行して通知する環境 - jiska
@HIROCASTさんが書いた記事「コードやテストを保存したら自動でPHPUnitを実行しGrowlへ通知する環境」に感銘を受けました。 僕が使用しているUbuntuでも同じように通知する環境を用意します。 まずUbuntuでGrowlのように通知を表示してくれるnotify-sendをインストールします。 sudo apt-get install libnotify-bin次にhttps://github.com/mynyml/watchrを参考にしつつwatchrをインストールします。 sudo gem install watchr sudo gem install revこのままだとwatchrにパスが通っていないので、.bashrcなどにパスを追加するように設定しておきます。 PATH="/var/lib/gems/1.8/bin:$PATH"設定した内容を反映させて、watchr
１３さいの備忘録 : rcovでテストガバレッジをグラフ表示
2011年08月28日22:25 カテゴリrailsテスト rcovでテストガバレッジをグラフ表示 RailsはTDD、BDD！...とは分かっていも運用してるアプリのバグが発生した場合はfirefoxのfirebugとかで動かしながら直してし まいがちなんですよね。 で直した後にテスト書いたり、書かなかったり... これじゃあダメなのでもう少しテストをガッツり書きましょうと思いテストのガバレッジツールであるrcovと使ってみた。 rcovはどんなものか簡単に書くと、既存コードからテストの漏れをグラフ化してHTML形式で出力してくれます。まぁ素敵！ これがあると、テストを書くのが面白いですね！100％を目指したくなります。 でも、本当はrcov走らす前に100%じゃないといけないんですけどね さて、インストールです。 今回の環境は以下です。 Rails 3.0.8 rcov 0.9.10
TDD Boot Camp in Tokyo 1.5 に参加しました | 48JIGEN *Reloaded*
TDD Boot Camp in Tokyo 1.5 に参加しました 2011/07/09 どこよりも早いブログ！・・を書こうと思ってたものの、@shinyaa31さんのブログとか@tomy_kairaさんのブログとか内容てんこもりでお届け済みなことを確認したので、僕の方は写真メインでTDD Boot Camp in Tokyo 1.5に参加してきた感想などまとめていきます。（USTの録画はこちら。@brtrvierさんありがとうございます！） 大事なことを最初に ・渋谷の会場に集まれた皆さん、ustでサテライト参加されていた皆さん、お話を熱心に聞いて頂いてありがとうございました！失敗談を交えてお話して少しでも背中を押すことができればとLTを申し出ましたが、話しているうちにやっぱり、こちらが勇気づけられているように感じました。 ・@t_wadaさん、講演ありがとうございました！いつも講演の
TDD BOOT CAMP in TOKYOに行ってきました！ - ShiroKappa Blog
2011/07/09に開催された「TDD BOOT CAMP in TOKYO」に行ってきました。 まずは、Symfonyしゃべりばでのひょんなきっかけから、この素晴らしいイベントの主催をされた[twitter:@HIROCAST]さん、会社でもお世話になっておりますが、開催協力と講演をしてくださった[twitter:@t_wada]さん、各言語をサポートいただいた[twitter:@shishi4tw]さん、[twitter:@setoazusa]さん、[twitter:@kyon_mm]さん、[twitter:@sue445]さん、設営から運営をサポートしてくださった方々、LTをしてくださった[twitter:@remore]さん、[twitter:@tomy_kaira]さん、Ustの配信にご尽力いただいた[twitter:@brtriver]さん、[twitter:@gilbite
Act as Professional |
プログラマは1日のほとんどを座った状態で生活している人がほとんどではないでしょうか？ この「座りすぎ」の毎日は病気のリスクを高くすることが明かになっています。 座りすぎは病気のリスクを高める この「座りすぎ」の生活は2型糖尿病、心血管疾...
BDDについて自分なりにまとめてみた - UKSTUDIO
BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振
#php_tdd_ci に参加して知った仮実装の付加価値と、例外処理のプラクティス | 48JIGEN *Reloaded*
#php_tdd_ci に参加して知った仮実装の付加価値と、例外処理のプラクティス 2011/06/21 今週末に食べる地元札幌、大心のラーメンが楽しみで楽しみで震える@remoreです。 ※本文と写真は関係ありません 昨日GREEのセミナールームで行われた「PHPでTDD&CIワークショップ」に参加させて頂いて、本当に光栄にも@t_wadaのFizzBuzzを書くデモのペアプロパートナーをやらせて頂きました。帰宅したけどまだ手を洗えない状態です。※握手はしていません ※オーラか何かがまだ残ってる さて、会場でRedbullをうっかり2本も飲んだせいで色々と学びの多かった勉強会だったので興奮が覚めず寝れそうにないので、今日学んだことを書き残しておきます。内容はいまTDDを勉強している人向け。 テストコードをテストできる。仮実装の付加価値 仮実装ってご存知でしょうか。こんな感じのコードの事で
Google Slides: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more
既存システムでTDDするのが難しい理由 - くろまほうさいきょうでんせつ
TDDしたい、CIしたいと思ってもなかなか導入できない。何でだろう？ PHP製WebアプリケーションでのTDDを学び始めた現時点の気持ちまとめ。 Seleniumを使うような高いレイヤーのテスト どんなテストを書けばいいのかわからない 例えばDBから商品情報取ってページ生成する場合。 商品カテゴリごとに異なる趣きのページを作るのでそれぞれにviewのテストを書いたとする 各ページ内の商品詳細URLにパラメータが追加されることになった URL生成は共通のモデルで行っている 修正は一ヶ所で簡単なもの だったとしてもviewのテストはそうは行かない。 先に用意したテストケースを全部書き直さなきゃならない。 小さな変更にかかるコストが大きくなる 単純に時間がかかるというより めんどくさくなる → どうせやらなくなる という思い。 コントローラーとか中間くらいの層のテスト viewよりは下、ユニット
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://atnd.org/events/22027
はてなブログ | 無料ブログを作成しよう
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ