TDDや自動化について色々話した
Kenichiro Ota @oota_ken 井芹さんも書いていたようになぜ日本にはテスト自動化スペシャリストがここまで少ないのか。いや、開発者がやっちゃうのかとどっかで議論したい。デブサミ後の囲む会できょんさんとかなあ。 2012-02-02 00:06:02 みかまま @mikantsuki @oota_ken 毎年、新しく入ってきた卒論生に自動テスト環境の構築をさせてみると、しみじみ大変そうだなぁと実感できます。基礎知識がないとけっこうはまるみたいねぇ 2012-02-02 00:16:28
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
テスト駆動開発チートシート - やさしいデスマーチ
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でもたぶん作れると思います。
TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？ - プログラマの思索
チケット駆動開発を運用していると話すと、必ず「チケットの粒度はどれくらいが妥当ですか？」という質問が来る。 僕はまだその質問に完全な回答は持っていない。 その質問について考えていることをメモ。 【1】RedmineやTracで、全てのタスクからQAまでチケットを起票してから作業を始めるようにすると、チケットの粒度がかなり細かくなってしまう。 粒度が小さいと作業しやすいが、チケットの完了速度よりもチケットの登録速度が上回ってしまう時が多いため、どんどんタスクが増えていってしまうような感覚に陥ってしまう。 かと言って、チケットの工数が5人日以上になってしまうと、進捗がはかどっているのかどうかも分からない。 チケットの粒度が問題になる状況は、顧客へ進捗報告を出したい時だ。 RedmineやTracによるチケット管理はあくまでも開発者のためのタスク管理が目的だから、粒度が細かすぎて、顧客から見れば
TDD BootCamp 北陸2日目
昨日の続き。 ハヤオキクラスタ数名がご飯の前にお風呂でウダウダ。ここでもちょっと愚痴ってしまう。いかんいかん。 ブレックファストセッション朝ご飯を食べながら今日の方針をうだうだと。悩みは多いがやはりレガシーの方向に向かうことに。 ウェイクアップセッション - レガシー vs TDD デモ報告。なぜか急に腹が緩くなった。 Ioke という JavaVM 上の言語へのコマンドを Twitter から投げられる bot のレガシーコードにテストを付加し、機能追加を考えながら、手法の解説を行うという、かなり @t_wada 頼みのセッション。 検体の活きが良すぎて若干消化不良ながらも以下の解説が繰り広げられる。 まずバージョン管理、そしてブランチを切る現在の動作を Characterization Test で浮き彫りに密結合の class をぶった切る。コンパイラに怒られるかどうかでメドをつけて
TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。 そして、BootCamp と日常を重ねて思ったことなど。 大変だ！ レガシーコードの修正だ！TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。 そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。 対象はいわゆるMVCフレームワークを利用したWebアプリ最速でやってくれ（ここがもう「なんだかな」ではあるんだが）変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ できるだけここはいじりたくないいやぁ、レガシーだねぇ。 どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだなんか censor のない Camp ネタのように見えるなこの部分だけ切り出
TDD BootCamp 北陸1日目
※ 2日目もあります イベントに行ってきた去年の年末にあったTDD読書会＆ふりかえり（実はその日記書いてない;）からの流れも含めて、なんと！ あの！ t_wada が！ とか書いておくと follower がやってきてくれるかもしれないので名前出しを先にやってしまうけど、 3月13日 TDD Boot Camp 北陸(石川県)TDD Boot Camp 北陸についてのお知らせ - self contextsに参加してきました。トラックバックセンターは TDD Boot Camp 北陸に登壇させていただきました - t-wadaの日記 かな？ 会場白山里のウェブサイト/白山麓の自然に囲まれた天然温泉の宿、体験・研修交流館 で、分かる人は「バードハミング鳥越を越えて花ゆうゆうのもうちょい先」で分かります。ものすごい山奥を想像してたけど、地元民からすればある程度は想定の範囲内。ただし電波的にはか
テスト駆動開発の効果はどのくらいある？
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
TDD、TDDと言うけれども。TDDのダークサイドについてそろそろ一言語ってみる。 - Fly me to the Luna
id:t-wadaさんの話の中で、TDDが品質を保証するわけではない、という話があったんですが、それについて私見をつらつらと。ちなみに自分は2年くらい仕事でTDDをやってきました。 やってきた中で下記のTDDの利点を感じることができました。 その時に気づいた最もシンプルなコード、クリーンなコードができる テストコードからコードを書く、と言うのはプロダクトコードの利用方法が考えられるのでとても有効に作用します。id:t-wadaさんもリファクタリングが一番重要と話されていましたが、テストコードがあれば安心してリファクタリングができます。 より高い品質のコードが書けるようになる これはt-wadaさんの話の中でもありましたね。なぜかと言うと、プロダクトコードが実行される時の前提条件を知ろうとすると、結構いろいろなコードに目を通すことになります。コードに目を通すことで優れた先人の知恵を見つけるこ
Trac + SVN + IRC の良さ - LukeSilvia’s diary
ちょっと考える機会があったのでメモ。僕の仕事環境だと、Trac, SVN, IRC(, あとplagger) を中心に開発している。 これらを使っていて思うこと Trac と連動しているとタスク管理が楽だよねー!……違うよ!全然違うよ!それだけなんて勿体ない > < ↑ぶっちゃけ最初はこう思ってた。 とはいえタスク管理(Trac) チケット書くことでタスクを細かく分割しようとする チームの人同士進捗が見られる ロードマップ機能で長期マイルストンの管理も ロールバックできる(SVN) なんか変な修正したけどどこ変えたか忘れた ファイル消したーーーー! そこでsvn revert ですよ! SVN diff で良質なコードを(SVN) 前回のコミットから変更したコードだけをレビューできる 変なコードがあったら修正してからコミット チケット駆動開発(Trac + SVN) コードに時間の概念を導
Google App Engineでテスト駆動開発を行うための3つのTips | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記
Google App Engineの開発ではPythonを使います。GAEを使ったWebアプリの開発でテスト駆動開発を行う際にも，Python的なユニットテストの文脈を活用できます。 ただし，GAEでユニットテストを行うためにはいくつかのツールやトリックが必要です。ここでは，そのテクニックを簡単に紹介します。 その1 : NoseGAEを使う Pythonのテスト用ツールにNoseがあります。このツールは，複数のディレクトリを渡り歩いて，複数のテストコードを一気に実行してくれる便利なツールです。 NoseのプラグインNoseGAEをインストールすることで，GAEアプリのテストを楽に行うことができます。「nose --with-gae」というようにオプション指定をすることでNoseGAEを利用できます。NoseGAEでは，テストコード上でGAEのモジュールやパッケージをインポートするために必
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの
Mint's log: Frozen Perl 2008メモその3：Introduction To Testing with Perl（実例で学ぶPerlのテスト駆動開発）
2008年4月2日 Frozen Perl 2008メモその3：Introduction To Testing with Perl（実例で学ぶPerlのテスト駆動開発） 資料が公開されている。テストを先に書くというテスト駆動開発。概念はわかりやすくても実際に行ってみるとなかなか難しい。この発表は簡単なモジュールを開発する場面を見せてくれるという点で実にわかりやすかった。問題の設定分譲マンションのような共同住宅を考える。この建物の延べ床面積のうち各世帯が所有する面積の割合を計算する。たとえば、延べ床面積が10000平米のマンションにある1000平米の住居なら10%。これを算出するモジュール、PercentOwnership.pmを作る。テストその1：use_okを使ってモジュールが使えるかどうかテストするモジュールPercentOwnership.pmを作らずに、いきなりテストを作る。tとい
「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必
TAPの話 - Unknown::Programming
http://d.hatena.ne.jp/tokuhirom/20080305/1204677112 404 Blog Not Found:「同じコード」の同じって何さ - TAPのススメ 弾さんの記事見て思い出した。 以前、id:tokuhiromさんに教えてもらったTAPの話ですが、折角なので導入しよーかと。 PHP版HTML_FillInFormのテストをTAP形式に。ってかもともと出力はTAP形式になってたので、今回の変更点としては、 #!php <?php error_reporting( E_ALL ); require_once 'Test.class.php'; plan(1); require_ok('HTML/FillInForm.class.php'); こんな感じで一行目に#!にphpを指定しとけばOK。 これでPerlのproveコマンドが使えるお！素晴らしい！
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト駆動開発ハンズオン前編
InfoQ: TDDを根づかせる:導入の問題と解決策
TDD/BDDは不完全なユニットテストを招くか？
