Steve Freeman氏とのペアプロ雑感 #tddbc
README.md Steve Freeman氏とのペアプロ雑感 http://tddbc.doorkeeper.jp TDD Boot Camp 2013-07 -- TDDBC で、偶然にもロンドンから来日していたSteve Freeman氏を招くことができた。ちなみに本当に偶然の来日で、その日の夕方にご家族と隅田川の花火を見る予定だったらしい。貴重な時間である。 20分ほど講演していただき、さらに参加者と一緒にペアプロ課題に挑戦してもらった。しかもペアプロでっていう貴重な体験をさせてもらったので、そのことについてまとめたい。 Steve Freeman氏は書籍 "Growing Object-Oriented Software, Guided by Tests" （邦訳「実戦テスト駆動開発」）の共著者の一人で、Javaのモックフレームワーク "JMock"の開発者の一人。当然、自動販
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年間で皆さまの知識
軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ
これは、TDD Advent Calendar jp:2012 の16日目のエントリーです。前日のエントリーは、@pocketberserkerさんの「Specs2のParameterized Testのはなし」でした。 ご存じの方も多くなっていると思いますが、「テスト駆動開発（以下、TDD）」とはテストコードを先に書くテストファーストを基盤とした開発手法です。先にテストコードを書く事により、これからどのようなプロダクションコードを書こうとしているかを明確にすることができることが特徴です。このため、テストの技法というようりは設計の技法です。 テスト駆動開発を実践することにより多くのメリットを得ることができます。このことは2011年のAdvent Calendarで言及しました（TDDを学ぶべき10の理由 #TddAdventJp）。TDDは簡単に導入することができる一方で、実践するのは非常
敢えてテストを書かないということ - くりにっき
元々は TDD Advent Calendar jp: 2012 : ATND で人数が足らなかった時の予備として用意していたのですが、めでたく人数が埋まったため単発で上げてみます。 僕は自他共に認めるTDDマニアですが*1、敢えてテストを書かないことの重要性について説きたいと思います。 id:shuji_w6e さんの 軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ と近いですが、shuji_w6eさんのがテストを軽くするのに対しこっちはそもそもテストを書かないようにするということです。 テストを書かなくてもいい（書く必要のない）ケース 寿命の短いプログラム TDDというのは最初にテストを書くコストというのがどうしても発生するため、寿命の短いプログラムだとTDDの恩恵を受けづらいです。 自分の経験上、半年以上メンテする必要があるプログラムだと保守フェーズ
2010-03-20
なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して
ジョジョの奇妙なTDD
何かの間違いで、LT王になってしまったTokyuRuby会議05の発表資料。 人類共通言語のジョジョでTDDを伝える試み。 色々とアウトな感じなので、 お咎めを受けたら消します・・・。 7/30追記: 拡散の勢いがかなりのものだったので、カット版に差し替え。
ユニットテストの保守性を作りこむ, xpjugkansai2011
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
恐怖のFragile Tests問題
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation10.1K views•63 slides
かっこ悪くて面倒でもテストコードを書こう - 今川館
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
TDDの基本的な考え方について - ひげろぐ
今日はTDDBC 福岡2の講演を聴きながら取ったメモを転載。 TDDとは何か、なぜTDDするのか、どのようにTDDを進めていくのか。 テストは目的ではなく手段であり、真の目的は「健康」。 TDDはスキルだから誰でも習得可能。 といったことが凝縮されている。 TDDとは まず動くコードを書いてそれをきれいにしていくのがTDD。 きれいだけど動かない設計より汚くても動くコードを書いて、それを徐々にきれいにしていく。 ソフトウェア開発においては、まずコードを書いて動かしてみないと分からないことが多すぎる。 なのでコードを書き始める前に設計に力を尽くしても無駄になる部分が多い。 完璧な設計をしてからコードを書き始めようという「完璧主義の呪い」 （一方で設計しなさすぎも死ぬけど） TDDのサイクル 1. テストを書き 2. そのテストを実行して失敗させ (Red) 3. 目的のコードを書き 4. 1
PHPUnitのアンチパターンとベストプラクティス
みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたらPHPUnitのアンチパターン・ベストプラクティスに関する素晴らしいスライドを見つけたので内容を抜粋で紹介します。 1. テストの中で何もテストしていない class FooTest extends PHPUnit_Framework_TestCase { public function testSomething() { $foo = new Foo; $foo->doSomething(new Bar); } } こういうテスト。どこにもアサーションがなくて何もチェックしていません。 $foo->doSomethingの戻り値を検証しないならなんの意味もありません。 純粋にTDDをしていれば、テストコード作成→テスト実行でRed→プロダクションコード作成→テスト実行でGreenなのでこういうテストは登場しませ
TDD的にiOSアプリケーション開発してみる - yaakaito::Blog
Test, Objective-C, iPad, iPhone(iOSのテストを書くとViewControllerがコントローラーになれる話 - yaakaito::Blog を先に見ておくと、何がやりたいか分かり易いかもしれません。)iOSアプリケーションのテストの書き方、難しいですよね。僕もよく分からないので手探り状態です。とりあえず、標準のOCUnit使ってTDDっぽいことしてみれば、何か叩き台になるかな？と思ったのでその過程を公開してみます。書くテストロジックテストだけです。後々アプリケーションテストもやる予定なのですが、というか一緒にやってたんですが、重すぎたので一旦ロジックテストだけです。ロジックテスト主体で書けるようにできる限りViewContollerと切り離してコードを考えています。ツッコミ大歓迎！(ロジックテストだけやるので、ビューに表示するところまで書いてません)リク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDDで「テストばかり書いて間に合うのか？」と質問されたときの正解 - きしだのHatena
PerlでTDD(テスト駆動開発)するなら覚えておきたいCPANモジュール群 | hirobanex.net