新訳版『テスト駆動開発』が出ます - t-wadaのブログ
テスト駆動開発の考案者 Kent Beck が記した原典『Test-Driven Development by Example』を新たに訳し直し、新訳版『テスト駆動開発』としてオーム社から復刊しました。ただ訳し直すだけではなく、初めての方にも旧訳版をお持ちの方にも読んでいただけるための工夫を凝らしました。 テスト駆動開発 作者: Kent Beck,和田卓人出版社/メーカー: オーム社発売日: 2017/10/14メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 電子書籍版は Kindle 版は Amazon Kindle ストア、 PDF 版と EPUB 版は 達人出版会 から発売されています。 テスト駆動開発 作者: ＫｅｎｔＢｅｃｋ出版社/メーカー: オーム社発売日: 2017/11/13メディア: Kindle版この商品を含むブログを見る テスト駆動開発【電
三年予測 | 「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。 | dodaエンジニア IT
「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。
Test Yourself - テストを書くと何がどう変わるか
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
不具合にテストを書いて立ち向かう - t-wadaのブログ
テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか？ 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
#tddbc (TDD Boot Camp) in Tokyo 開催します!! | Act as Professional
TDD Boot Camp in Tokyo の開催を正式に宣言します。 僕はテスト駆動開発（TDD）に出会って、本当にソフトウェアのつくり方や設計や考え方が変わりました。 コードを書く人間として、さらなる上のステージに上れたことを実感できた体験でした。 そしてそれは、もっと上のステージへいくための土台となるスキルなのだと考えています。 体験しないとわからないことが多いでも、“本当のTDD”は実際に手を動かして、見て、体感しないと理解しにくいものなんです。 だから、TDDを実践している人たちと一緒にプログラミングできるイベントをやります。 前回のTDDBC2009年12月に開催されたTDDBCでは、PHPの言語チームがなかったとな。 「PHPerよ。恥ずかしくないのか。」と、あえて喧嘩売ることにします。 そして、Symfony2でPHPUnitが正式採用されたからBoot Campしてスパ
WEB+DB PRESS vol.61 Rails3テスト最前線がすばらしい - tech-kazuhisa's blog
WEB+DB PRESS vol.61の「Rails3テスト最前線」という記事がかなり良かったので、注釈を交えて紹介したいと思います。 何が良かったのか？ 自分はRails2系でTest::Unitを実践していました。AutoTestとYAMLによるデータ投入でおおむね満足していましたが、次のポイントが気になっていました。 YAMLによるデータ投入は重複が多いのでコピペでデータを作成していた。 Test::Unitはログイン処理など共通の処理をくくり出すのが難しかった。 Viewのテストの方法が分からなかった。 しかしこの記事で気になる点がスパッと解消されました。私と同じような人はこの雑誌の記事が役に立つと思います。 ちなみに私はMacのSnow Leopard上でRuby1.9.2を使ってこの記事の内容を試しました。1.8.7を使う前提で書かれている箇所もあるので注意してください。（後で
js テスト放浪記
Wandering about JavaScript Testing - Mar 8, 2011 at Test.js, presented by Shibuya.js
#devsumi【18-B-1】プログラマが知るべきたったひとつの大事なことがら - tmtms のメモ
デブサミ2011の id:t-wada の講演のメモです。嘘書いてあるかもしれません。 タイトルは釣り きのこ18. 学び続ける姿勢 読む/書く/話す サッカーファンが得意なことは二年単位でものを覚えること 1996/07/22 マイアミの奇跡 アメリカにいた 初めてコンピュータに出会った ホームステイ先の子供と仲良くなりたい ファミコンでマリオ3をやってみせた 本当に没入したものは体が覚えている 無限1UP 「ニンテンドーの国からきた男は違う」 心をつかんだ 原体験 ひとを動かすためにはやってみせる 2000年 OO厨をこじらせる RDBの世界は汚いから俺が正す テスト大嫌い 俺が書いたコードにバグがあるわけがない でもバグや手戻りが多い 完璧主義の呪いにかかった ただしいモデルがわかるまでコードを書いてはいけない 2002/06/07 日韓ワールドカップでアルゼンチン対イングランド 技
ユニットテストの保守性を作りこむ, xpjugkansai2011
3. 自己紹介 • 井芹洋輝（いせりひろき） • 扱っているもの – 組込み開発/ソフトウェアテスト/開発者テスト • 所属 – WACATE実行委員/TDD研究会/ATECなど • 対外活動 – JaSST’11 Tokyo/WACATE2011冬/Androidテスト祭り等 – ソフトウェアテストPRESS総集編/Ultimate agile Stories
レガシーコードをライブで扱う際のポイント試案
twitter で TDDBC Hokuriku (2010) のレガシーコード改善を Coding Dojo で行った際の Ruby チームは比較的うまくいってたけど、あれって○○な流れだっけ的な話をしているうちに気になってることをまとめておこうと思い立ったので、できるだけ書き出してみる。 何かのきっかけになれば嬉しい。 素材（レガシーコード）のポイントまず動くこと触ったことがあること1ある程度でいいので機能別に書かれていること オブジェクト指向であるとなお良い（使える技が増える）小規模であること ただし完全に単機能だと余地が少ないのでテストを足しにくい外部 API 依存しまくりの場合は単なるレガシーコード改善とはまた別なテクニックの習得に繋がってよいかも自動実行できるテストがないこと :-)1 については「えっ」て思うかもしれないけど、放置してるものは依存ライブラリの関係や、そもそも動
RSpec の入門とその一歩先へ、第3イテレーション - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第3イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 大きく時間が開いてしまいました(すみません…)、RSpec 入門の第三イテレーションです。 (第3回 coffee.rb の開催に合わせたライブ更新で書かれましたので、まだ詳細の説明は途中のところもあります。) 第1イテレーション 第2イテレーション 前回終了時点のコードと実行結果 この「RSpec 入門とその一歩先へ」シリーズでは、メッセージフィルタを RSpec を使って開発することで、 RSpec の機能と TDD を同時に学ぶことを狙いとしています。 前回終了時点のコードと実行結果をまず記します。 message_filter.rb class MessageFilter def initialize(*w
TDD勉強会 in オフィス - @ikikko のはてなブログ
サッカー日本代表がベスト8をかけて熱い戦いを繰り広げる4時間前、弊社事務所でもid:t-wadaさんを迎えてテストについて語るという熱い熱い戦いが繰り広げられました！t-wadaさん、そもそもが無茶振りにも関わらず快く引き受けていただいて、本当にありがとうございます！！ 関連リンク Twitterのハッシュタグ：#t_wada。 Yunのもり 06月30日(水) - diary そういえば、前座を終えて日本代表戦のために家に帰る途中のマックに、有名人がいました。この人ともぜひ熱い戦いを繰り広げたかったところです。 http://twitpic.com/20yxq6 メモは取っていたのですが、ざっとでしかないしお酒も入っていたので内容怪しいところあるかも。何か不備があったら、ご指摘願います。 達人プログラマー（白い方） バージョン管理・テスティング・自動化の三本立て 他の2つはちょっと賞味期
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
Joshua Kerievsky 氏講演会「リファクタリングの戦略と戦術」 - 科学と非科学の迷宮
概要 URL http://patterns-wg.fuka.info.waseda.ac.jp/JK2010.html 日時 2010/03/18 18:30 - 20:30 場所 国立情報学研究所（学術総合センター） 12階 会議室 twitterハッシュタグ #PWG_JK 講演タイトル Refactoring Strategies & Tactics 講演者 Joshua Kerievsky (Industrial Logic, Inc. and Cutter Consortium) 「パターン指向リファクタリング入門」の著者。 パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法 作者: ジョシュア・ケリーエブスキー,小黒直樹,村上歴,高橋一成,越智典子出版社/メーカー: 日経BP社発売日: 2005/08/04メディア: 単行本購入: 11人 クリック: 31
TDDを真面目にやってみて気付いたこと - Masatomo Nakano Blog
何を今更、なことかもしれないないのだけど、もしかしたらこれを知ることでTDD(Test-driven development)をやることのハードルが一気に下がる人がいるかな、と思ってメモ。 特に、ある程度プログラマとして経験があるけど、どうもTDDは慣れないという人向き。 “TDDとは、TDD以前に脳内や機上でやっていたことをコードに落とすことに過ぎない” このことが解ってから、TDDをするのが一気に苦痛ではなくなり、むしろ楽しくなった。 TDDでなくても、コーディングをするとき、temporaryなテストコードを書いたり、目視でのチェックはしたりするものだろう。たとえば、一時的に変数の値をハードコードして挙動を変えてみて、それを目視で確認したり、printデバッグとかもその一部だ。 つまり、このtemporaryなコードや目視している部分をpermanentにするのがTDDで書くテストコ
RSpec の入門とその一歩先へ、第2イテレーション - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第2イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 #coffee.rb の写経会に招かれた(というよりは押しかけた?)ので、先日の RSpec チュートリアルの続きを記します。このエントリは写経会に参加しながらのライブ更新でした。 (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 前回終了時点のコードと実行結果 前回終了時点でのコードを以下に記します。 message_filter.rb class MessageFilter def initialize(word) @word = word end def detect?(text) text.include?(@word) end end message_filter_spec.rb r
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
