みんなのPython勉強会#37で『「テスト駆動開発」を通じてプログラマがコードと向き合う活動を改めて学び直す』のタイトルで講演させていただきました。
i-like-tdd-16d9ce2c2201
みんなのPython勉強会#37で『「テスト駆動開発」を通じてプログラマがコードと向き合う活動を改めて学び直す』のタイトルで講演させていただきました。
付録Cだけじゃない！付録Aに隠されたTDDの狙いとは？〜テスト駆動開発をやめて、なお残すべき習慣とは(10)
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっても、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。 付録AにはTDDの狙いが含まれる著者のケント・ベック氏は、そもそも、プログラミング中にどんなフラストレーションを感じて、テストファーストやTDDを編み出し解消を試みたのでしょうか？ 彼が解きたかった問題の説明は、書籍の三部で記載されたパターンの問題記述や25章の「テスト」に出てくる因果ループ図、付録Aに記載された因果ループ図が参考になります。 新訳『テスト駆動開発』が出版されたときは、和田さん書き下ろしの付録Cに注目が集まりましたが、実は付録Aの因果ループ図も「著者が取り組みたかったテーマがいったい何だったのか？」を的確に把握する上で欠かせません。 今回は、付録Aに記載された因果ループ図を参考に、「ケント・ベックが解消し
テスト駆動開発における進化的設計とデザインパターンの勘所とは？〜テスト駆動開発をやめて、なお残すべき習慣とは(9)
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って
希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
粘土のように設計して外側のフィードバックループを回す 〜 『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （２）
和田：そうですね。 家永：もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。 和田：それリファクタリングという言葉の受容のされ方が何か変わってきたというか。 家永：だんだん変わっちゃって。 和田：単なる作り直しをリファクタリングと呼んでいる、それはある。 家永：ちょっと何だかなあという感じ。「えっ！？」と、ドキッとする事があります。 和田：それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。 家永：全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。 和田：そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。 和田：良い面というのはリファ
燃えろスリーアミーゴス！作れGWT！回せフィードバックループ！〜テスト駆動開発をやめて、なお残すべき習慣とは(6)
実践テスト駆動開発の図1–2を参考にいろいろ追記スリーアミーゴスが協力するシステムで具体的に何をつくったらOKなのか（何を作らなくてもよいのか）は、１人のロールで纏めるのは難しく、スリーアミーゴス（ビジネス、開発者、テスター）の３者の協力が必要です。 ビジネス：対象ドメインに詳しい。ユーザストーリーのWhyに詳しい。ビジネス観点で何がシステム必要で不要かを判断できる。開発者：ユーザストーリー実現の技術的手段のHowに詳しい。問題に対するシンプルな解き方の代案を提示できる。対象ドメインをコードで言語化し、理解を深めることができる。テスター：テストシナリオのパターン出し、特に顧客やユーザに損害を与えるであろう盲点の発見が得意。テストシナリオをリスクベースに評価し順序付けを提示できる。早期に何を作り（何を作らないか）のシステムの理解をすり合わせることで、手待ちや手戻りや抜け漏れや不要な作り込みを
最初からクライマックス！デプロイから始めよう〜テスト駆動開発をやめて、なお残すべき習慣とは(5)
AmazonでSteve Freeman, Nat Pryce, 和智 右桂, 高木 正弘の実践テスト駆動開発 (Object Oriented SELECTION)。アマゾンならポイント還元本が多数。Steve Freeman, Nat… １．プロジェクト開始直後に本番に近い環境にデプロイする”プロジェクト開始直後からデプロイとテストを行うことで、チームはシステム全体をどうやって実際の世界に適合させていくか理解しなければならなくなる。 プロジェクト初期段階に、会議室や机上だけでの何を何故つくるべきかどうやってつくるべきかの判断は、たいてい間違いや抜け漏れが含まれています。大事なことを知らないことすら気付いていないこともあります。ソフトウェア開発において、その間違いや知らないことに手っ取り早く、具体的に気付く方法は、早期に小さくつくってデプロイし動かしてみることです。動かそうとすれば仕事の
フィードバックをイチから学び直す〜テスト駆動開発をやめて、なお残すべき習慣とは(4)
前回、テストの４象限を紹介しました。今回からフィードバックについては、複数に分けて解説します。1回目は、フィードバックの基本のキから解説します。次回に実戦テスト駆動を参考に多重のフィードバックを解説する予定です。 フィードバックのおさらい”フィードバック”という言葉は、意味が多義的に使われており、誤解を生じやすいです。Wikipediaのフィードバックを下記に引用します。 フィードバック（feedback）とは、もともと「帰還」と訳され、ある系の出力（結果）を入力（原因）側に戻す操作のこと。古くは調速機（ガバナ）の仕組み[1]が、意識的な利用は1927年のw:Harold Stephen Blackによる負帰還増幅回路の発明に始まり、サイバネティックスによって広められた。https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%BC%E3
Go言語をTDDで学んでみた話（続き）
前回からの続き前回に引き続き、Go言語をテスト駆動開発（TDD）を使いながら学びを進めてみます。前回の記事はこちらをお読みください。 さて、まずはここまでのTODOリストを見てみましょう。#TODOの下はこれからやるべきタスクで、#DONEの下はすでに完了したタスクになります。 #TODO 0の場合、4000の場合はエラー 4の場合はIV 9の場合はIX 5の場合はV 40の場合 50の場合 11の場合はXI (1-3999で抜け漏れをあとで...考える) gorename を試す VSCodeで保存したら即テスト実行の方法を探す# DONE 10,20の場合 1 => Iの変換ができること。 APIの見直し（オブジェクト指向風のメソッドに置き換え） Goでよく見かけるデータ駆動型のテストに置き換え 2 => IIの変換ができること。今回は、気になっていたエラーケース(0の場合、4000の
スタブ・モックは本当に悪者なのか？〜テスト駆動開発をやめて、なお残すべき習慣とは (2)
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
あなたのテストの盲点はどこにある？〜テスト駆動開発をやめて、なお残すべき習慣とは(3)
http://studiototoro.com/musukarakka-471より改変前回、スタブ・モックの使いどころの再考について触れました。そのなかで、ユニットテストのみに頼るのは、盲点が生まれるという点を指摘しました。「群盲象を評す」という寓話があります。各々の盲目の人が象の一部を触って象を語るだけでは部分でしかありませんし、盲点も消えません。 象の部分を統合して初めて全体を語れるように、一つの視点では盲点ができてしまいますが、複数の視点があればそれを防ぐことができます。 今回は、アジャイルテストの４象限を使って、テスト観点の全体像をお伝えし、次回では多重のフィードバックループについて盲点を少なくする仕組みについて解説します。 テスト駆動開発のスタイルをやめたとしても、自分たちが作り続けているプロダクトが期待通り動き続け、プロダクトがユーザや市場によりフィットしていくようにするには、
価値提案駆動 -- TDDとの類似点
概要 Lean Startupで知られるようになってきたMVP(Minimum Viable Product: 最小限の実用可能な製品)と、Running Leanで提唱されている独自の価値提案(Unique Value Proposition: UVP)について、ソリューション(どう実現するか)よりも先にUVPを先に考えMVPによって早期から検証を繰り返しながらプロダクトを構築していくプロセスが、ソフトウェア開発におけるTDD(Test Driven Development : テスト駆動開発)におけるテストを先に書いて、実装して、リファクタリングするというプロセスに似ているのではないかと考えた。 本文 最近、Running Leanのワークショップを@kdmsnrさんと一緒に開催したり、実際に自分でリーンキャンバスを書く機会が増えたため、ソリューションより先に独自の価値提案(UVP)を
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
Using Hudson for C++/CMake/CppUnit
Update: Hudson for C++/CMake/CppUnit Revised As a follow-up to Using grails projects in Hudson, here is another not-so-standard usage of Hudson: C++ projects with CMake and CppUnit. Let’s see how that works out. As long as you have Java/Ant/JUnit based projects, a fine tool that it is, configuration of Hudson is pretty straight forward. But if you have a C++ project with CMake as build system and
はじめに: Cutterリファレンスマニュアル - Cutter
ソースコード: LGPLバージョン3またはそれ以降のバージョン （詳細: license/lgpl-3.txt ） です。 ドキュメントときのたんアイコン: LGPLとGFDLとクリエイティ ブ・コモンズ・ライセンスのトリプルライセンス。 glib-compatible/glibintl.h, glib-compatible/gregex.*, glib-compatible/gscripttable.h, glib-compatible/gsequence.*, glib-compatible/gstring.*, glib-compatible/gunicode.h, glib-compatible/guniprop.c: LGPLバージョン2.0またはそれ 以降のバージョン（詳細: glib-compatible/COPYING ） glib-compatible/pcre/: PC
Webratがスゴい(続:Cucumberがアツい) - moroの日記
Cucumberを使って、Railsアプリのテストを高い抽象度で書き進めていくために欠かせないのがWebratというライブラリです。前回のCucumber全体像の紹介に引き続き、こちらWebratを紹介します。今回も長いです。 2008-01-27修正 id:amacouさんから指摘を受けまして(と、たぶんsatokoさんも以前おっしゃってた)webrat_steps.rbの生成先パスを修正。 語: ${RAILS_ROOT}/step_definitions 正: ${RAILS_ROOT}/features/step_definitions ありがとうございます。 今回のまとめ Webratすごい 画面遷移を「リンクをクリックする」「ボタンをクリックする」と書ける リンクのアンカーテキストではまだ日本語が使えず。さきほどパッチ送ったので早晩書けるようになるはず。 フォームの入力項目もラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go言語をTDDで学んでみた話
俺達のTDDの戦いはこれからだ！〜テスト駆動開発をやめて、なお残すべき習慣とは(1)
I'm afraid I can't do that, Dave. - Embedded Computing Design