テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
t-wada の日記（旧）
2004 年以来 10 年弱はてなダイアリーを書いてきましたが、「はてな エンジニアブロガー祭り」登壇をきっかけとして、はてな blog に移転いたしました。 http://t-wada.hatenablog.jp/ はてな blog に移行する際に、はてなダイアリーの記事を丸ごと移行するオプションもありました。しかし、旧日記はそのままの見た目で、そのままの URL であって欲しいと考えましたので、アカウント移行はせず、当日記はそのままにすることにしました。 こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園20
【ハウツー】xUnit.NETでユニットテストをしてみよう【前編】 (1) xUnit.NETの入手と環境設定 | エンタープライズ | マイコミジャーナル
xUnit.NETは.NET 2.0以上で動作するテストツールで、MicrosoftのBrad Wilson氏とJames Newkirk氏が中心となって開発を進めています。xUnit.NETは拡張性の向上、カスタム属性の減少、メソッドごとのインスタンス生成を特徴としており、Moq、Ninject、Oxite、KiGGなどのOSSにも採用されています。以下、xUnit.NETの導入方法、テストコードを紹介します。 xUnit.NET の入手と環境設定 xUnit.NET はCodePlexから入手できます。執筆時点での最新バージョンは1.6です。「xunit-1.6.zip」をダウンロードして適当なフォルダ(本稿ではC:\Sample\xunit)に展開します。これには以下のようなファイルが含まれています。 xUnit.NETのWebサイト インストールウィンドウ(xunit.instal
tanabata.tracに参加してきました - tomo_snowbug’s diary
ブログに書くまでが勉強会です。とid:kanu-orzさんがおっしゃっていたので所感を書いてみようと思います。 Shibya.tracは初めて参加させていただきました。 知っている人が居ない状態でしたが、楽しかったです！ あと、ビアバッシュも初体験。ビール大好きなので、ぜひ、社内の勉強会でもやってみたいです。 スタッフの皆さん、スピーカーの皆さん、参加者の皆さん、お疲れ様でした！ USTのリンクも貼っておいてと。 http://www.ustream.tv/recorded/8125667 http://www.ustream.tv/recorded/8127374 以下、自分なりのメモです。 ゆかわさん id:wyukawa - 大規模受託案件(Java)でのHudsonの導入事例紹介 Hudsonをコンパイルエラーの検知のために導入した 途中から入った案件で、入った当初はコンパイルエラ
TDD勉強会 in オフィス - @ikikko のはてなブログ
サッカー日本代表がベスト8をかけて熱い戦いを繰り広げる4時間前、弊社事務所でもid:t-wadaさんを迎えてテストについて語るという熱い熱い戦いが繰り広げられました！t-wadaさん、そもそもが無茶振りにも関わらず快く引き受けていただいて、本当にありがとうございます！！ 関連リンク Twitterのハッシュタグ：#t_wada。 Yunのもり 06月30日(水) - diary そういえば、前座を終えて日本代表戦のために家に帰る途中のマックに、有名人がいました。この人ともぜひ熱い戦いを繰り広げたかったところです。 http://twitpic.com/20yxq6 メモは取っていたのですが、ざっとでしかないしお酒も入っていたので内容怪しいところあるかも。何か不備があったら、ご指摘願います。 達人プログラマー（白い方） バージョン管理・テスティング・自動化の三本立て 他の2つはちょっと賞味期
RSpec のすごいところ - kなんとかの日記
(注: 以下の内容は、RSpec ユーザの間で広まっていることでもなく、もちろん RSpec 開発チームの公式な見解でもなく、あくまでワシの個人的な見解です。) RSpec のすごいところは、コードに対してではなく仕様に対してテストを書くことを明確にしたことだと思う。何を今さらと言われそうだけど、今さらになってようやく気づいたニワトリ頭ですまんかった。 ワシも最初は、「assert_equal(expected, actual)」のかわりに「actual.should == expected」と書くかっこよさに目を奪われて、テストコードを自然言語に近い形で記述するのが RSpec のすごいところだと勘違いしてたし、それが「TDD (Test Driven Development)」から「BDD (Behaviour Driven Development)」へという新しい潮流だと勘違いしてた
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
私が、分散バージョン管理を使おうと思ったただ一つの理由
最近デビューしました。 たった一つの理由を挙げろといわれれば 今のプログラミング開発手法のマッチしているから に尽きる。 TDDやCIが良い例だと思う。 TDDの例 SVNの場合TDDのレッド⇒グリーン⇒リファクタリングのタイミングでコミットするには粒度が小さすぎる。 でもコミットしないと小さな不安が残る。だけど、コミットすると余計なリビジョンがかさむことになる。 分散バージョン管理であれば、レッド→グリーンになったタイミングでローカルブランチにコミット出来る。 そのあと、一つのTDD(設計工程)が終わった段階でまとめてメインブランチにpushする。 ※bazaarでのやり方がわからないんだけど（汗 自分で試行錯誤しているときは安心(グリーン)したタイミングでコミット。 で、ひと段落したらメインリポジトリへpushというのが自然な流れで実行できる。 CIの例 CIの場合に、SVNでよくやる
デブサミのアンケートに感動したので全部返事書いてみた 2010 - 宇宙行きたい
沢山の人に聞いてもらってその後も質問などで色々お話しが出来て 僕も勇気を貰いました!! ありがとうございます!! とりあえず資料貼っておきますね!! 三周遅れのXPView more presentations from yoshiori. で、アンケートに返事してみようのコーナー 今回は大量でした!! ありがとうございます!! 今まで聞いていたセッションの中で1番面白かった上、とてもためになりました。プログラミングし始めてからまだ3ヶ月ぐらいしかたってない自分にとってテストは品質担保のためだと思っていました。しかし、話を聞いていて「開発するためのテスト」という考えに触れて、テストに対する考え方が少しかわりました。ありがとうございます。 こちらこそありがとうございます!! 個人的には TDD で開発するのはスキルアップの近道だと思うので 是非試してみてください!! ナイス、個人からでも始め
最近の TDD 議論についてちゃんと僕の気持ちを書いてみる - 宇宙行きたい
最初に ちょっと最近，ドタバタしてて twitter だと腰を据えて話せないなと感じたので，ちょっと最近のTDD 議論についてちゃんと僕の気持ちを書いてみようと思います． これは僕が"今"感じてる事とか考えている事を書いているだけですので，誰かを論破したいとか，誰かを説得したいという意思は無いです． 本当に裏とかはなく，純粋に「"庄司嘉織"という人間は"今この時"にこういう事を感じてこういう事を考えた」というだけです． もちろん明日には考えが変わるかもしれないし，逆に過去の発言とは違うかもしれませんが，「最近はこう感じている」という事をちゃんと書いておこうと思いました． デブサミでの発表について id:babie さんにちゃんと返事をしていなかったので，まずちゃんと返事をしておこうと思います．(遅くなってしまってすいません) @kakutani は興味なくても、あのスライドだと @yosh
Mockitoノススメ テストスタイルの変化 - Fly me to the Luna
Mockitoを使うようになってから、僕はテストコードへの取り組みが変わりました。Mockitoを使うまで僕がUnit Testと思っていたものは、厳密にはUnit Testじゃないんじゃないか、と思うようになりました。なぜかというと、実装コードを書いていくと、たくさんのクラスと関連していきます。だんだんと、そのクラス、Unitをテストするのではなく、そのAPIの裏にあるクラスの状態、振る舞いも予測しなければならなくなっていきます。例えば永続化層にアクセスするクラスを開発しているのであれば、どんなに上層にあるレイヤーのクラスでも、テストデータをDBに入れないといけない、というのは、よくよく考えてみると、変な話なのです。どこかの段階で、DBを操作するクラスを参照しなくなるはずですから。大体、リズムが悪いですよね。DBの初期化用のテストデータ用意するのは大変です。 Unit Testでは、テス
TDD BootCamp 北陸1日目
※ 2日目もあります イベントに行ってきた去年の年末にあったTDD読書会＆ふりかえり（実はその日記書いてない;）からの流れも含めて、なんと！ あの！ t_wada が！ とか書いておくと follower がやってきてくれるかもしれないので名前出しを先にやってしまうけど、 3月13日 TDD Boot Camp 北陸(石川県)TDD Boot Camp 北陸についてのお知らせ - self contextsに参加してきました。トラックバックセンターは TDD Boot Camp 北陸に登壇させていただきました - t-wadaの日記 かな？ 会場白山里のウェブサイト/白山麓の自然に囲まれた天然温泉の宿、体験・研修交流館 で、分かる人は「バードハミング鳥越を越えて花ゆうゆうのもうちょい先」で分かります。ものすごい山奥を想像してたけど、地元民からすればある程度は想定の範囲内。ただし電波的にはか
TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。 そして、BootCamp と日常を重ねて思ったことなど。 大変だ！ レガシーコードの修正だ！TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。 そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。 対象はいわゆるMVCフレームワークを利用したWebアプリ最速でやってくれ（ここがもう「なんだかな」ではあるんだが）変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ できるだけここはいじりたくないいやぁ、レガシーだねぇ。 どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだなんか censor のない Camp ネタのように見えるなこの部分だけ切り出
xDDについて考える(その1)
※このブログはデブサミ後のTwitterで話題になっていた時に下書きしていたものをそのままUPしています。 先日TDDBootCamp北陸に参加して少し考えたところもあるのですが、それは別エントリに。 最近xDD(???-driven development)という言葉が色々取り上げらています。 TDD(Test-driven development) BDD(Behavior-driven development) SDD(story-driven development) DDD(Domain-driven development) ※ここでTiDD(Ticket-driven development)のような技法を含んでいないのは、ちょっと方向性が違うかなと思ったためです。 デブサミでも話題になったそうで、Twitter上でも色々議論が流れているようですが、 ちょっといま忙しくてほと
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
CSpec で BDD - Natural Software
C言語のテストフレームワークって、動かすまでが大変だよねー。 なんて話をついった上でしてたところ、CSpecの存在を思い出したので、川西さんのところを見ながら学習中。 Toshiyuki Kawanishi Toshiyuki Kawanishi インストール 川西さんのgithubから一式を落とす（toshi-kawanishi/cspec · GitHub） 展開とインストール $ cd <展開したフォルダ>/src $ make $ su $ cp libcspec.a /usr/local/lib $ cd ../inc $ cp * /usr/local/include ビルドと実行 $ gcc test.c -l:libcspec.a $ ./a.out 結果 Describe:under_test_function() - it return sum arguments. O
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
テスト駆動開発の効果はどのくらいある？
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
