Python で TDD してみる - methaneのブログ
RSpec の入門とその一歩先へ がとてもよい記事だったので、 Python で写経させてもらいました。 https://github.com/methane/pytest-tut Ruby コミュニティと Python コミュニティの考え方の違いも見えて面白いと思います。 環境は Python 3.3 で、実行には py.test コマンドを使いましたが、 py.test の機能は特に使っていないので nose でもなんでも大丈夫です。 ファイルの作成 まずは空の実装とテストを作ります。 message_filter.py class MessageFilter: pass message_filter_test.py 最初のテストを書く py.test は .should といったメソッドを勝手に生やしたりはしません。普通に assert 文を書きましょう。 --- a/messege
「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」?
きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm 僕が不勉強な部分はあるのだけど、「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」とかたまにいう人がいるんだけど、その人がまともにTDD/BDDの説明しているの聞いたことがないので、まるで参考にならない意見ばかりでつらいです。 2014-04-17 12:49:49
使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!
Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin
Robert C. Martin (Uncle Bob) has been a software professional since 1970. In the last 40 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, C++ Programming and Clean Code. He has published dozens of articles in various trade journals. Today, he is one of
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
【翻訳】TDD is Fun - diskogs's diary
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
「実況解説つき！ペアプロでわかるJavaScriptテスト入門」レポート | gihyo.jp
2014年1月17日、ベルサール新宿グランドにて開催された「エンジニアサポートCROSS 2014」の中の1セッション「実況解説つき！ペアプロでわかるJavaScriptテスト入門」をレポートします。 エンジニアサポートCROSS 2014とは 「複数の技術を身につけなければWebサービスは作れない＝クロスしないと生きていけない」をテーマに、「エンジニアサポート新年会2012 CROSS」として第一回が2012年に開催された勉強会イベント、それがCROSSです。今年で3回目になります。 「実況解説つき！ペアプロでわかるJavaScriptテスト入門」 このセッションは「JavaScriptで書かれたよくあるコードをベースに、ペアプロでテストコードを足していく様子を解説者が説明する」という内容になります。 それでは、さっそくセッションの模様を見ていきましょう。 登壇者 本セッションの登壇者
BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト
新年のご挨拶あけましておめでとうございます． 2012年は Schemer, Haskeller にとって飛躍の年でありますよう心から願う所存であります． デザインについてはあと最終勧告まで2年を切った HTML 5 がそびえたつクソにならない事を切に祈り，ユーザビリティ，アクセシビリティ，ユースケース，UX をガン無視した「CSS3だけで出来たなんちゃらかんちゃら」「美麗なビジュアルエフェクトを実現する jQuery プラグイン」で衆目を集めてなんちゃってクリエイティブ気分を味わってる人たちが滅亡してくれる事を期待しています 前回までのエントリーBDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 BDD on Haskell チュートリアル その1 : HUnit で TDD を 今回は QuickCheck を使ってランダ
和田卓人さん出題のテスト駆動開発問題『現在時刻とロケールに依存するテスト』をPHPを使ってオブジェクト指向で解答してみました #php #object_oriented｜CodeIQ MAGAZINE
テスト駆動開発の巨匠・和田卓人さんからの『現在時刻とロケールに依存するテスト』問題をPHPメンターズの後藤秀宣さんが解答してくださいました！ この記事は、その後藤さんによる解答コードの公開と解説記事になります！！ by CodeIQ運営事務局 PHPメンターズの後藤です。 和田卓人さん出題の『現在時刻とロケールに依存するテスト』問題をPHPを使ってオブジェクト指向のアプローチで解答してみました。 ※問題文については、和田卓人さんの解説記事を参照にしてください。 https://codeiq.jp/magazine/2013/11/1475/ 解答例は次の環境で作成しています。 PHP 5.5.4 PHPUnit 3.7 Composer サンプルコードのリポジトリをGitHubにて公開しています。コミットログなど合わせてご参照ください。（解説中にも各コミットへのリンクを貼ってあります） g
Copeが教えてくれた、TDD否定派論文の紹介 - 2013-10-31 - やっとむでぽん
来日中の James O. Coplien と話をする機会があり、いまTDDをクライアントに推薦していると話したら目を剥いて "Are you still doing TDD!?" と詰め寄られ、TDDの問題について大変熱烈に語ってくれました(ディスカッションをした体ではあるんだけど、だいたい10対0くらいで押されてました)。 Cope はその後、丁寧にfacebook上にもTDDの話を書いてくれました。ここで読めます。 さらにメールで、TDDの問題を指摘した論文などをいくつか教えてくれたのでした。そこで紹介してもらった論文を、自分の理解の整理も兼ねて、サマリをしてみようと思います。とりあえず1つだけですけど。 "A Comparative Case Study on the Impact of Test-Driven Development on Program Design and T
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
もはや若くないし、頭も悪くなったから、いまテスト駆動開発(TDD)、ドメイン駆動設計(DDD)、DCIを学んでる - 石橋秀仁(zerobase)書き散らす
今年はプログラミングに再入門してます。 もはや若くないので、自分の「頭の悪さ」を受け入れて、それでも読み書きできるコードを模索してます。 ここでいう「頭の悪さ」とは、「大きなクラスや長いメソッドを理解できない」という脳のスペック的な意味です。 ぼくは二十代の頃と比べて頭が悪くなってしまったので、DDD（ドメイン駆動設計）、TDD（テスト駆動開発）、DCI（データ・コンテキスト・インタラクション）といったソフトウェア工学の成果に興味を持ってます。 抽象度の高いドメインモデリングとかプログラミングって、一見頭がよさそうに見えるかもしれませんが、むしろ（上記の意味で）「頭が悪い」人にこそ必要なんです。 頭が良かったら、もっとCPUに寄り添った高速なコードをすらすら書けるわけです。 頭が悪かったら、人間のメンタルモデルに寄り添った読みやすいコードを書くしかないわけです。 だから、一見高度で抽象的で
Gaucheでユニットテスト。 - rokujyouhitoma's blog
TDDを求めるエンジニアが多いので、gaucheでのユニットテスト例。 ;;テスト対象 (define (proc1 a b c) (if (and (<= a b)(<= a c)) (+ (proc2 b)(proc2 c)) (proc1 b c a))) (define (proc2 x) (* x x)) #| 以下ユニットテスト例。 |# ;;テストモジュールを読み込む (use gauche.test) ;;テストをスタート (test-start "proc1 test") ;;テスト群の名前付け。 (test-section "test group 1") ;;テスト項目 (test* "proc1 13" 13 (proc1 1 2 3)) (test* "proc1 25" 25 (proc1 2 4 3)) (test* "proc1 41" 41 (proc1 5
私はRSpecでテストをこんな感じで書いてる - アジャイルSEを目指すブログ
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
TDDしないケースについてのUncle Bobの考え
おー。UncleBobの最新エントリいいですね。次の #TDDBC で紹介してもよいのでは？ / The Pragmatics of TDD | 8th Light http://t.co/l4XQPrCfol @unclebobmartinさんから — きょん＠うさみみモード (@kyon_mm) March 6, 2013 で、紹介されていたのが、以下のエントリ。 The Pragmatics of TDD – The Clean Coder Blog (※2019/1/16 エントリのURLが変わっていたので差し替え) 読んでみると、ボブおじさん（Uncle Bob）ことRobert C. MartinがTDDしないケースについて言及していて素晴らしいエントリでした。 ので、勝手訳してみます。（添削していただいた@liliputさんに感謝！） Original blog entry
グリーンバンド共同購入まとめ - みずぴー日記
発端 TDDブートキャンプで「テストを書くのはつらい。Bob Martinもacts_as_professionalと刻んだグリーンバンドを身につけて、自分を戒めてるんだ」というエピソードが紹介される ボクも欲しい! http://mixbuzz.com/wristbands.htmlで20個から作ってもらえるらしい さっそく賛同者を募ったところ30個、希望者が集まる よし、注文しよう! 進捗状況 2010-07-11: http://mixbuzz.com/wristbands.htmlに見積りを出しました。Mサイズで30個。色はJUnitのグリーンの色(rgb(0,188,65), ■)です。 2010-07-12: 「RGB指定は200個からです」と言われました。ネオングリーン■で再見積りを出しました。ついでに個数を40個に増やしました。 2010-07-13: 上記の設定で見積りが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いつでも聞けるTDD入門 #TDDBC_NAGOYA
Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案
How deep are your unit tests?
