TDDや自動化について色々話した
Kenichiro Ota @oota_ken 井芹さんも書いていたようになぜ日本にはテスト自動化スペシャリストがここまで少ないのか。いや、開発者がやっちゃうのかとどっかで議論したい。デブサミ後の囲む会できょんさんとかなあ。 2012-02-02 00:06:02 みかまま @mikantsuki @oota_ken 毎年、新しく入ってきた卒論生に自動テスト環境の構築をさせてみると、しみじみ大変そうだなぁと実感できます。基礎知識がないとけっこうはまるみたいねぇ 2012-02-02 00:16:28
InfoQ: SplkskyとBobおじさんの対決
ここ数週間、Joel Spolsky(リンク)とRobert C Martin(リンク)(Bobおじさんと呼ばれている)の間で議論が交わされている。そもそもの発端は、Jeff Atwood (リンク)とJoel Spolskyの「38:th Stack Overflow」 (リンク) というポッドキャストで、Joelの「よくユニットテスティングをJoelテストの13番目の項目に加えるべきだと言われるんだけど、それには反対なんだ」という発言だった(Joelテストとは、「Joelテスト: よりよいコードのための12のステップ」のことだ) (リンク)。Joelはこのように説明している(リンク)。 テスト駆動開発について議論されていることですが、すべてはユニットテストすべきだという意見があります……たくさんの人が私に、Joelテストを読んだ後で、「13番目の項目としてユニットテスティングを加えるべ
[TDD Advent Calendar jp: 2011] TDD とアジャイルを支えるバックボーン #TddAdventJp - TDD.NET
てっきり bleis さんが立ち上げてくれてると信じたのに～～～ f(^^; 昨日までの記事で TDD の中身に関しては語りつくされた感もあるので、 最終日にあたるこの記事では、 TDD を支えるバックボーンの話をしてみたいと思います。 TDD は (それとアジャイルソフトウェア開発プロセスも)、 ソフトウェアの開発に特有の技法です。 ハードウェアの開発 (機械、 電子機器、 建築など) では、 できません。 なぜか? それを知るためには、 少しハードウェアの開発プロセスを見る必要があります。 ハードウェアも、 ソフトウェアと同様で、 複雑なものをいっぺんに作ることはムリなので、 最初は大雑把に考えてそれからだんだんと詳細を詰めていって、 最後に個々の部品の設計へと落とし込んでいきます。 代表的なハードウェアとして自動車の製品開発プロセスを取り上げると、 次の図のような流れでやっています。
![[TDD Advent Calendar jp: 2011] TDD とアジャイルを支えるバックボーン #TddAdventJp - TDD.NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/6514362542013a74f686fce4f36649cd2cdc7d9b/height=288;version=1;width=512/http%3A%2F%2Fwww.tdd-net.jp%2Fimages%2F2011%2F12%2F25%2F20110920_automobile_development_pro.png)
TDDに関する記事のリンク集|ネスケラボ
こんにちは、青木です。 これは、TDD Advent Calendar jp: 2011の12/24分のエントリーです。 前日は@irasallyさんのエントリ「職業プログラマに贈るTDDのススメ」です。 翌日は@biacさんのエントリ「TDD とアジャイルを支えるバックボーン」です。 このエントリーではTDD(テスト駆動開発)に関する記事を、一覧に整理しています。 TDDには素晴らしい記事が多く、100を超えるリンク集になっています。 そこで目的に近い記事を探しやすいように、大まかな区分で分類して、内容について簡単なコメントを追記しました。また、昔の記事か最近の記事かわかるように掲載年月も記載しました。 TDDを学ぶときにこのリンク集が役立てば幸いです。 TDDとは ［動画で解説］和田卓人の“テスト駆動開発”講座(Gihyo.jp) http://gihyo.jp/dev/serial/
職業プログラマに贈るTDDのススメ #TddAdventJp – 寺子屋未満
このエントリはTDD Advent Calendar jp: 2011のエントリーとなります。 前日の@yuri9976さんのエントリ「TDDと共に（成長記録としてのTDD）」に続く23日目の記事です。 23日目はTDDを初めて2年目のオム子がエントリを担当します。 ラスト3の座をゲットしてしまい、さらに電子書籍化の話…と気が遠くなりそうになっていましたが、がんばります。 まずは、タイトルの「職業プログラマ」って何さ、って話からしましょう。 職業プログラマとは（※オム子定義による） 「プログラミングを職業としているので勤務中はコードを書くがプライベートではほとんど書かない」 「詳細設計書通りにプログラムができていればそれでよい」 「与えられた環境と技術以外のことは求めない」 「コードよりもExcelと向き合っている時間が多い」 「割と大規模なプロジェクトで昔からの文化に染まり、それが常識だ
TDDと共に（成長記録としてのTDD） | YRL（Yuri Research Lab.)
この記事は、TDD Advent Calenderの22日目のエントリです。 前日は Tugu Katagiriさんの素晴らしいエントリ「私、MVCでTDDやってます。」です。 私は先月TDDBC横浜に初めて参加したばかりのTDD超初心者です。 しかもソフトウェアエンジニアをやっているのに、コーディングが大の苦手です。 エディタに向かって、さあこれからコードを書こう、という時点で、大勢の見知らぬ人々の前でいきなりスピーチを迫られたはにかみ屋さんの気持ちになってしまうのです。#現実の私は全然はにかみ屋さんじゃないのに（苦笑） そんなコンプレックスが邪魔をしてか、一人でレガシーコードに立ち向かうだけの勇気が出ないので、ならばチーム内で仲間を作ろう、いや本音を言えば私を引っ張ってくれる人を育てるべく、TDDの良さを伝えるにはどうすれば良いか、現在画策中です。 そこで、周囲の人にTDDとは何
Testing と 私と 苦い出来事 - haru01のめも
この記事は、TDD Advent Calendarの20日目。 cubeon さんの 後になります。 http://atnd.org/events/22027 http://d.hatena.ne.jp/cubeon/20111219 今日は、Developer Testing について私の過去の苦い経験を１つお話しします。 この体験は私の中で Testing について強く印象に残っている５本のエピソードの中の１つです。 この出来事は、時々思い返します。 （Testingの苦い経験とか、ちょっと趣向の違う記事あってもいいよね！） はじまり あれは今から数年前、私が社会人２-３年目で、 TDDや XPに初めてトライした プロジェクトのでした。Java開発者向けに、とあるフレームワークをつくるというプロジェクト。このプロジェクトには、XPやTDDを強く支持している外部コーチや先輩の人たちがいま
アジャイルにTDDしようとしてペアプロして失敗した話 - 水まんじゅう2
これはTDD Advent Calendarの18日目。 記事としては @mao_instantlife さんの TDDやってみてコメントが減った話 のあと、@cubeon さんの きっと方眼の理から逃れられないお前たちにも告げる！テストコードを手に入れるのだ！ の前となります。 最近、新しい開発手法の一貫としてTDDを採用しようとするプロジェクトが出始めている印象があります。 ただし、とりあえず取り入れてみたけれどもうまくいかなくて結局ウォーターフォール方式に逆戻りという例も多いのではないでしょうか。 以前、アジャイルにTDDをしようとしてペアプロして失敗したプロジェクトの話を聞いたことがあるので書こうと思います。 その時のプロジェクトでは数百人月前後の工数をかけてそれまであったレガシーシステムをJavaでリプレイスしようとしていたようです。 それなりの規模のプロジェクトに多いように、さ
TDDやってみてコメントが減った話 - 冥冥乃志
この記事はTDD Advent Calendar jp: 2011 : ATNDのためのエントリです。前日は @masaru_b_cl さんのDartUnitができるまで | be freeです。真面目でもなく緩くもない中途半端な記事です。ただ、TDDを練習していく中で、個人的に面白い気づきだったので、少し取り上げてみたいと思います。 注意事項 個人の経験感想に基づくものです。あなたがそもそも同じようなコードを書いてきたのでなければこの考察はなんのお役にもたてません。ご了承ください。 コメント、書いてますか? TDD以前、私が書いていたソースは以下のような感じでした。 private String hogeMethod(String param) { // 初期処理 initLogic(); // 主処理 mainLogic(); // 後処理 endLogic(); } オーバーでも何で
#107 TDDに対して思っていること « TDD « a wandering wolf
このエントリは TDD Advent Calendar 2011 の15日目です。 先月11月は26日と27日に、TDDBC 福岡 2に参加してきました。 私にとって、初めてのTDDBC参加になります。 今まで仕事でもTDDを導入する余地がなくて(今年は開発じゃないことをやっていることが多かった) 、個人作業だけぼっちTDDしてました。 なので、こういう場でTDDをちゃんとやれて、しかももう一つ念願だったペアプロまでできて、 本当に得るものが多い2日間でした。 で、このTDDBC 福岡 2に参加して、あるいはそれ以前から思っていたことがいくつかありました。 それを雑記の形でつらつらと綴っていこうと思います。関数型言語とTDDの相性は？TDDBCの1日目にこんなツイートをしました。 これは、1日目にあったディスカッションの中で、 id:t-wada さんが発言されたことを自分なりに整理したも
例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
うさぎ組
本エントリーはScrapboxアドベントカレンダー2021の2日目の記事になります。 adventar.org 前日はsatoryuさんの Scrapboxの好きな理由 でした。Scrapboxっていろんなユーザーがいると思うのですが、アドベントカレンダー立ち上げよう！っていうファン度合いがよくわかる内容でした。 自分はScrapboxを仕事でも、プライベートでも、コミュニティでも使っていて感謝感謝ーって感じなのですが、今回はコミュニティでの利用について紹介します。 コミュニティと言っているのは、いわゆるオンライン勉強会のことです。 私がオンライン勉強会にグッと力を入れるようになったのは2020年頃からで、現在週5-6回勉強会をオーガナイズしています。 そのうちの全てでDiscord、そしてそのうちの3つでScrapboxを使っています！（ScrapboxとDiscordがなかったらって思
テストと言うパートナー #TddAdventJp - 日々常々
TDD Advent Calendar jp: 2011の 12日目です。 前：あなたは写経しますか - pocketberserkerの爆走 次：TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組 テストはパートナー 「何を言ってるんだ？」な感じかもしれませんが、私にとってテストはパートナーです。 私がTDDのコンテキストで言う「テスト」はDeveloperTestです。このテストは開発者の開発者による開発者のためのテストであり、つまり開発者たる私のためのものです。私だけのためにテストは働いてくれます。 テストに対する不安 TDDや自動テストと言う言葉に触れ、「いざテストを書こう」と思った時。もしくはよく知らないままテストコードを書かなければならなくなった時。テストに対して不安を感じると思います。TDDは「不安をテストにする」とか言いますが、そもそもテス
あなたは写経しますか - pocketberserkerの爆走
@katzchangさんの次となるTDD Advent Calendar jp: 2011の11日目記事になります。 登録者一覧を眺めるたびに「他に学生がいない…」と嘆きつつ、ハードルが上がり続けたタイミングでの担当回というこで胃に穴があきそうです。 11月時点では「TDDBCについて書こう」と思っていたのですが、12/1の素晴らしい記事によって書くことがなくなったり*1、日々追加されていく素敵記事を眺めながらどんな内容にするか悩んだ結果、釣り気味なものになってしまいました… はじめに とりあえず、この10日間に書かれたTDD Advent Calendar記事を振り返ってみましょう。まだ読んでない方は、まずは10日目までの読んでみてください。 まず、TDD少年の想いや学ぶべき理由を知ることができます。そしてTDDを学ぶ前に身に付けておくといいと思う基礎体力が提示され、TDD入門方法の１つ
C言語でもレガシーでも、TDD をやってやれないことはない(レガシーコード改善成分90%、TDD成分10%) - yujioramaの日記
id:goyoki さんの次になるTDD Advent Calendar jp: 2011の9日目です。 まったく自重しない素敵エントリが続いているので、ここらで息抜きをしましょう。 TDD についての理論、情緒、実践についてはすでに語られてしまったので、現場で使われた話を書きたいと思います。 前提 このお話は フィクション です。 現実によく似た光景を見たり聞いたりしたとしても、それは幻想です。幻想のはずです。幻想ということにしてくださいお願いします。 はじめに そこには C 言語のシステムがありました。 規模にして数万行の中規模なシステム。 24時間365日動き続けることが要求されるもので、僕の仕事は、このシステムの中枢部をうまいこと改修することでした。 テストコードはあるものの、設計に大きな変更が入る前のプロダクトコードが対象となっていて、ユーティリティ関数以外のテストは全滅という、
TDDのはじめかた #TddAdventJp - 千里霧中
本エントリはTDD Advent Calendar jp: 2011の12/8の担当分の記事で、id:t-wadaさんの「右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記」に続くものです。 はじめに TDDはシンプルな原則に則った手法ですが、とっつきの悪さもしばしば持たれがちです。また一連のTDD Advent Calendarで起こった議論や会話の中でも、TDDの始め方はどうすれば良いかという話が散見されましたので、自分の担当枠では「TDDのはじめかた」についてまとめたいと思います。なお紹介するのはあくまで数ある入門方法のうちの１つです。たぶん他にも色々な良い入門方法があると思います。 全体像 紹介する入門方法は以下のようなステップバイステップの構造となります。 いつでも軽快に使えるユニットテスト環境を構築する 必要と感じたらすぐテストを活用する テスト並行を
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
実録！TDD風景 #TddAdventJp - sue445's Blog
Search this site Recent Entries Recent Comments Recent Trackbacks
TDDを学ぶべき10の理由 #TddAdventJp - やさしいデスマーチ
かなり香ばしいタイトルですが、TDD Advent Calendar jp: 2011のエントリーとなります。前日の@bleisさんのエントリーの次になります。 はじめに TDD（テスト駆動開発）とは、「テストファーストを原則とし、テストが成功するようにプロダクションコードを書くというサイクルを繰り返す開発手法」です。XPのプラクティスの１つとして10年近く前に紹介され、ここ数年で再び１つのムーブメントとなっています。これは、TDD Boot CampがTDDへの敷居を下げ、体験する機会を提供した事も１つの大きな要因でしょう。 自分もTDDに魅せられたエンジニアの１人です。ぶっちゃけ、TDD信者とかTDD厨とか言われても可笑しくはありませんし、むしろ嬉しいくらいです。一方で、TDDを嫌う人もいるのも事実です。しかし、自分もTDDを銀の弾丸とは思っていませんし、適用しにくい領域もある事も理解
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
