アジャイルひよこクラブ(2016.06.24)でのテスト駆動開発についての発表資料です。未経験者~初心者向けになっています。
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
■ AgileSamurai BaseCamp の TDD セッションで講演してきた @t_wada さんから、AgileSamurai BaseCamp の TDD セッションで技術的負債や組織としての取り組みについて話して欲しいという依頼がきたので、社内に公開されているあんちぽくんの資料やブログからよくまとまっている内容を切り出して、僕の考えるところを中心に講演とパネルディスカッションしてきた。 社内でも DX! DX! とか、開発者のおもしろさ、みたいのを担当しているんで、その辺をもう少し噛み砕いて話したつもり。他の講演者が純粋にTDDをどうやって組織に広げるか、チームのTDD状況というような話だったのに、一人だけハードコアな話になってしまった。ばたり。
プログラムは随時更新しています! 18:30から予定していました交流会ですが、最小催行人数にいかなかったため中止とさせていただきました 講師情報 ふりかえりトラック 向井清二 (@seiji79) フリーランス 2000年前後デザイナーとしてwebを制作。ひとりで抱えるというミステイクを経験。NPOでワークショップの設計と実施を担当、その後現在も継続して場づくりに奔走。 リフレクション・コーチとして、小規模組織のコンサルティングを楽しむ。&セルフケアの勧奨はライフワーク。 及部 敬雄 (@takaking22) 歌って踊れるエンジニア。 2011年よりアジャイル開発系勉強会に参加・発表させていただくようになり、2012年には毎年アメリカで開催されるAgileConference 2012にも参加しました。「IT業界に金の雨を降らせる」ためなら、どんな壁もぶち壊すつもりで日々精進を続けていま
Forkwell のエンジニアの1人、正徳です。先日、入社した馬です。 最近Hubotでbotを作り始めて、朝会を通知させたり、Github Issueの件数を喋らせたり、と遊んでいます。 Hubotの記事はググればたくさん出てきて、喋らせるのはとても簡単です。ところが「Hubotでテストを書く方法」となると、情報がほとんど出てきません。 ChatOpsをやっているエンジニアが、まさかテストコードを全く書かずにbotを開発してる訳がないと思いますが、不思議と記事が見つかりません。 先人のブログなどが無かったので、自分で四苦八苦しつつ、なんとかTDDでHubot開発できる環境が作れたので、ブログにまとめてみました。 目次 Hubotでbotを作る方法 テスト用にモジュールを入れる mocha の実行方法 greet のテストを書く cron のテストを書く time モジュールを使っている
「TDD(テスト駆動開発)ってどのくらい使われてるんですか?」と聞かれることがあります。それはですね、俺だって知りたいわー!というわけで、「TDDの経験と現状について」というアンケートを作りました。 10/23の段階で83件の回答がありました。ありがとうございます。TDD人気ありますね。中間報告として、これまでの回答を公開したいと思います。始めた時期と現在の状況のグラフです。 回答全体のサマリはこちらで見られます(回答したときに見られるのと同じです)。なお、こちらは随時更新されるので、本エントリの内容と一致しないかもしれません。 https://docs.google.com/forms/d/1pb29VBqO-kd10ks_x9oqvkMUy5rDW4nMoDnBPVM85yc/viewanalytics ※アンケートはまだまだ受付中です。こちらからどうぞ→ http://goo.gl/
いまさら聞けないTDD/BDD超入門(4): 開発現場で保守性の高いTDD/BDDを実現するための3つのポイント――テストレベル/網羅性とは 開発現場でTDD/BDDを導入するためのポイントを大きく三つに分けて解説。テストレベルや網羅性、サイクルタイムについても紹介します。(2014/10/17) いまさら聞けないTDD/BDD超入門(3): TDD/BDDにおける「振る舞い」の意味するところとは何なのか BDD初心者が持ちがちな3大疑問点を提示して、さまざまな角度からそれを明らかにしつつ、振る舞いを表現する2つのテクニックを紹介する。(2014/4/30) いまさら聞けないTDD/BDD超入門(2): TDD/BDDの思想とテスティングフレームワークの関係を整理しよう TDD/BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
開発現場で保守性の高いTDD/BDDを実現するための3つのポイント――テストレベル/網羅性とは:いまさら聞けないTDD/BDD超入門(4)(1/3 ページ) 連載目次 前回の『TDD/BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD/BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ?」「網羅的なテストをどうやって書けばいいんだろうか?」「テストを先に書くだけくらいにしか違いがないのではないだろうか?」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD/BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き
カバレッジが低下するとライオンがコメントを書き残してくれる GitHub Webhook Service です。 http://twada-savannah.herokuapp.com/ 経緯その1 先週末は台風19号が沖縄を襲いまして。台風が襲来するといつものあれが始まるわけです。 台風19号ボッチソン(ヴォンフォン) - eXtreme Hago | Doorkeeper 今回は抜けるまで時間もかかりそうだった(実際2日ぐらい居座ってた)ので、久々に参加してみようと思った次第です(表明はしてないけど) 経緯その2 @t_wada さんのこのスライド レガシーコード改善の戦略と戦術 を読んでると出現する twada.png について @gongoZ 作者の @yosuke_furukawa 曰く、パブリックドメインです。— Takuto Wada (@t_wada) 2014, 10月
前編はこちらです 4:テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
後編を公開しました(2014/10/8) これは、テスト駆動開発(TDD)とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2~3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
はじめに。 この連載では、エクストリーム・プログラミング(extreme programming; 以下XP)のプラクティスのひとつであるテスト駆動開発(てすとくどうかいはつ、test-driven development; 以下TDD)について、 聞いたことはあるけれど内容は知らない方 概要は知っているけれど実際に使ったことがない方 等、主に初学者を対象に、TDDの基本について全6回にわたってご説明していきます。 RSpec等のツールを使ってTDD開発をしてはいるものの、正直メリットが今一つ理解できていないという方も、もちろん歓迎です。 そしてこのシリーズは、 “少しだけアジャイルをかじった程度の開発経験の浅いプログラマ”「古谷」が、TDD開発を実践しているプロジェクトに参画するにあたって、“プロジェクトリーダー”の「高梨先輩」に、TDDについて1から学ぶ。 という想定で記述していきます
JJUG CCC 2014 Soringで行ったユニットテストハンズオンでの資料です。Read less
RailsConf 2014 Is TDD dead? Is TDD dead? [Part II] Is TDD dead? [Part III] Is TDD dead? [Part IV] Is TDD dead? [Part V & VI] (40分くらいの Kent frozen がうける) TDD is dead. Long live testing. (DHH) 翻訳 2014-04-24 - やっとむでぽん 自動化したリグレッションテスティングが存在しないという残念な業界の現状 TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている 間接的で過剰に複雑な構造を生みがちだ。「遅い」ものをすべて避けようとする 伝統的な意味でのユニットテストはほとんどしない。すべての依存関係をモックにし、何千というテストが数秒で終わるようなユニットテスト 我々は完全なシステムテス
Join us Wednesday, June 4th for our final hangout w/@martinfowler, @kentbeck&@dhh. This final hangout will be a double episode (1hr) featuring a Q&A session as well as final thoughts. https://plus.google.com/u/1/b/102046517467703229044/events/cco30ri6dpkej4h4d8mejmat98o "TDD as One True Way" versus "TDD as devil-spawned tempter" is not a productive contrast. Most of us have similar goals for dev
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く