[TDD] スタート地点で止まらない為のTDD TIPS - 2012-01-10 - ぽにくすじゃないだいありー
10:50 | 皆さんは設計という名の「下手の考え休むに似たり」をして時間を無駄にしてしまったり、作りたいモノがあるんだけどどうやったらそれを作れるのかのイメージを組み立てられずに結局は何も作らずに無為に時間が過ぎたような事ありませんか？僕はあります。最近になってTDDはそんな人がスタートを切るための有効な技法なのではないかと気づきました。ここでは最近そういった状況を打破する為に試した事をTIPSとしてまとめてみます。TDDがどういう物かは知っているというのが前提です。TDDを知らない人はTDD BootCampとか参加してみるといいかもしれません。もしかしたら今回のTIPSはTDD的には邪道かもしれません。TDDについて詳しい人の突っ込みお待ちしております。 今回の記事に直結するTDD原則のおさらい1. TDDはクォリティテストの為の技法じゃないです。製品のクォリティを維持する為のテスト
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
なんかばんざい | TDDはYAGNIと矛盾しない。必要だからテストを書く。
TDDはYAGNIに矛盾する？ - u_1rohのカタチ Joel Spolskyの意見とコメント欄でのやりとりがどっちも面白かった。 僕のテストの書き方としては、テストファーストではなく、思いつきで処理を実装していくうちに仕様のようなものが見えてきたらテストを書いて保証する、というスタイルが多い。 「仕様のようなもの」というのは、「このメソッドはこういう値を返すべきだ」というような挙動の定義を指す。RSpecが「obj.foobar.should == "barbaz"」のように「should（〜すべき）」といった形式でテストを書かせ、テストをまとめたファイルを「spec（仕様）」と呼ぶのはたぶん偶然ではない。 これらは厳密な意味でのTDDとは違う（ただのユニットテスト論?）かもしれないけれど、とりあえずはこういうスタイルでやってて上手くいってる。 概念や私見はこれくらいにして、実際にど
ヽ( ・∀・)ノくまくまー(2009-04-08)
やはりテストの話題になって stubとmockの違いを1行で！ 今のテストフレームワークのお薦めは？ RRが熱いよ！(英語ぽく書くのが目的じゃない、rubyぽいdslが必要なんだ！) mock で should_receive でガチガチにサブオブジェクトに介入してくる人って何なの！ duck type の考え方からしても、何をやるかは相手に任せるベッキー mock は探針であるべきだ stub しか使わないよね ごめん、俺、最近は実データ派に戻ってきたんだ（Fixtureラブ） Fixture はシナリオ別に使い分けるのが面倒じゃない？ そこで FactoryGirl ですよ 何が嬉しいの？ テストデータを ruby コードで動的に書きたいときがある それって、もし fixture を簡単に切り替えられる機能があれば不要じゃね？ 動的なら YAML でゴリゴリ書く方法もあるし 切り替え、
rake statsを晒してみる - 那由多屋 開発日誌
こんにちは。那由多屋の加藤です。 みなさん、今日も元気にテストコード、書いてますか？ 那由多屋では、Webアプリケーションの開発にRuby on Railsを使っています。そんなRailsプロジェクトのテストコードの変遷を、ここに晒して見たいと思います。 なお、各プロジェクトのメトリクスは「rake stats」の出力結果で、テスティングライブラリにはtest/unitを使用しています。 Nayuzonβ（ナユゾン） 2007年3月に公開。プロダクトコードは457行、テストコードは89行、コード比は0.2。Subversionのリビジョン番号は434。 この時点で、Rails歴2ヶ月くらい。テストコードはほとんど無いに等しい。 NTTドコモのJavaアプリケーション（iアプリ）であり、Java側のソースコードは2,014行（空行、コメント含む）。 +--------------------
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
なぜ人はテストを書かないのか? - kなんとかの日記
「スーパープログラマー」という単語に過敏に反応する人がいたのをきっかけに、プログラマーとして一流であるための条件というのを考えてみたんだけど、難しくてわからんかった。しかし一流じゃない条件ならいろいろ思いつく。 たとえば、今なら「テストを書かないプログラマーは一流でない」ということは言えるだろう。これはどんな凄腕プログラマーだとしても当てはまる条件だ。 そして、これだけテストの重要性が叫ばれている中でもやっぱりテストを書かないプログラマーというのは存在する。これは初心者だろうが上級者だろうが関係なく一定数存在する*1。 で、なぜテストを書かないかということだが、いちばんの大きな理由は、テストを書かないのではなくて、テストが書けないだけなんじゃないかと思ってる。 テストを書いた方がいいなんてのは、誰だって分かっている。でも実際には書かない人が結構な数いて、その人たちは「ロジックは書けるけどテ
RSpecの標準Matcher一覧表 - 本当は怖いHPC
追記2（2015/09/08）ありがたいことに、未だにこの記事をブックマークしてくださる方がいらっしゃいますが、2008年に書いた記事なのでご注意下さい。内容はアップデートしていません。私自身はすでにRubyを使っていません。 追記：古い情報ですので、記事の日付とお使いのRSpecのバージョンを見比べて、参考程度にご覧ください。大部分は通用するはずですが。 Matcherをいちいち調べるのが面倒になって、公式のリファレンスマニュアルは一覧性が低いから、自分で一覧表を作った。 RSpecそのものについては、スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)などをどうぞ。そのうちRSpec on Rails版も作る予定。 名前 not((should_notで使えるかどうかという意味。)) 意味・機能 == ○ ==演算子を利用して比較する。ex
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
バグ見つけた→それってどんなテスト？もしくは、なんでＭＶＣなんて使うの？ - D-6 [相変わらず根無し]
バグ見つけた→それってどんなテスト？もしくは、なんでＭＶＣなんて使うの？ 最近ソフトウェアエンジニアリングに置ける開発手法に関して考えている。 ぶっちゃけ言ってしまうと「やっぱりTDDっぽいのがいいな」というところに落ち着きつつあるのだが、厳密にTDDをしたほうがよい、と思ってるわけではない。TDDとかExtremeプログラミング、Agileプログラミングにしても理想はいいんだけど、原理主義っぽい使い方は現実にそぐわないと思ってるからだ。 前置きはこれくらいにしておいて・・・重要だと思うのは以下の点： 開発サイクルに自動テストツールを組み込むエンジニアによるバグ／不具合発見時には「動かない」は許可しない。必ず再現コードを提出してもらうテストを自動テストツールを組み込む（＝次回リリース前にはかならずテストを実行できる状態にする）テストが通るまで修正を続けるという開発サイクルを取るべきだ、とい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜTDDとペアプログラミングで生産量が増えるのか