TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ導入から 10 年、PHP の trait は滅びるべきなのか その適切な使いどころと弱点、将来についてshinjiigarashi
PHPでTDD&CIワークショップ、Jenkins + PHP の各種プラグインパート資料 - Yamashiro0217の日記
はじめに この資料は「PHPでTDD&CIワークショップ」 http://atnd.org/events/16626 で @yamashiro が発表するための資料だよ。 ワークショップ参加者じゃなくても記事読むだけで完結するようには書いてあるよ。 概要としては、Jenkins を使って PHP のウンコレガシーなコードをいかに綺麗にして行くかということを説明する。 自画自賛だけど PHPMD とか PHPCPD の使い方の説明の資料としてもそこそこイケてる資料になってると思いました。まる。 この記事に書かれてることは、割とTemplate for Jenkins Jobs for PHP Projectsとかぶってるけど、プラグインを絞ってあるのと、一個一個のプラグインについて解説、また実際にエラーが起きたときにどうすればいいのか書くよ。 Java と Jenkins のインストールとJ
「TDDの本ってあまり売れないんだそうですよ」から始まる、その理由の考察などのまとめ
「TDDの本ってあまり売れないんだそうですよ。」と言う発言から思ったことをつぶやたら思いがけない広がりになったので、まとめてみました。(未完)
TDD ⇒ PDD
ダイクストラは、テストでバグの存在は示せるがバグのないことは示せないと言っていた。一方で、TDDはテストを重ねながらプログラミングをおこない、用意したテストが全部通ったらプログラム完成と言うアプローチだ。と誤解しやすいが実は単なる開発プロセスに対する提案である(10/2)。 欲しいのはバグはあるかも知れないが取りあえず動作する綺麗なコードではなく、まずバグのないコードだ。 この点を改善するにはどうするか。実は良いアイディアが浮かんだ。自動テストツールではなく、プログラム検証ツールを使用して正しいことを証明しながらプログラミングをおこなうPDD(Proof driven development)だ。 プログラムSの証明とは、Qを事前条件、Rを事後条件として、{Q} S {P}が恒真であることを示すことだ。たとえば、二つの整数x, yを与えられてxが大きい値になるように、値を入れ替えるプログラ
CSMの集い - Natural Software
Done,Done,Done Ready,Ready,Ready TDD,BDD,ATDD ALM DAYとAgile DAY ざっくり思ったことをはき出してるので適当に ALM DAYで TFSのことを考えていたら、個々の機能、プラクティスに注目してみればアジャイルでもウォーターフォールでも大差はない。 今の日本ではアジャイルは駆け出しで、従来型（ウォーターフォール）が主流である。アジャイルがどうだという議論はあれど、従来型からアジャイルへの道程はあまり見かけない。 その誤解がハイブリットアジャイルというなんちゃってアジャイルを生んでいる。 従来型からアジャイルへの進み方をプロセス視点で考える場にしたい。 従来型→ハイブリットウォーターフォール→アジャイルへと遷移する ハイブリットウォーターフォールの時点で、アジャイルの思想を知ることで、顧客視点と各プラクティスを学ぶ ハイブリットウォー
C言語による組み込みTDDまとめ - ジャンク☆ニュース 臥龍
C言語でTDDを行う場合、また組込み系でTDDを行う場合、色々問題が発生する。 スタブ関数名の競合 クロスコンパイル環境(実機の容量不足、実機用CPUで使えるツールが少ない(カバレッジ計測など)） グローバル変数の使い過ぎで単体テスト不可 私の場合は以下のようにして行った。 1.関数のモジュール仕様書を作成し、関数名、関数毎の引数、戻り値を定義 2.上記よりスケルトンを作成(自動) 3.ターゲットCPU依存のデバイスをパソコン用にスタブ関数とヘッダーを作成 (擬似FROMのR/W,SIOのR/W,ポートのI/Oなど) 4.Cygwin上でCUnit for Ando でスケルトン用にUnitテストを実装 5.単体テスト実行後、スタブを実機用のドライバーに切り替え（ヘッダーファイルを変更）実機に組み込み。 C言語におけるTDDの問題点と解決方法 組込み開発におけるテスト駆動開発事例 〜C言語
Test Doubleを使うとテストの信頼性/保守性が下がるのか？ - Fly me to the Luna
最近はユニットテストを行うテストコードにおいて、Test Doubleを多用してます。Test DoubleとはMockとStubを合わせた総称です。Test Doubleを用いると、信頼性や保守性が下がると言われることがあります。しかし、それはTest Doubleの用法を誤っているためではないかと僕は思うのです。Test Doubleの用途はユニットテストのスコープをテスト対象のクラスに限定するために用いるべきものです。実感として、Test Doubleを使っているからと言って、ユニットテストの信頼性/保守性が下がったとはあまり感じていません。 良く誤解されていますが、Test Doubleはスローテスト問題を解決するための手段ではありません。Test Doubleをうまく利用すれば、結果的にスローテスト問題を解決できます。しかし、スローテスト問題を解決するための手段ではないのです。ス
PHPでBDD（Behavior Driven Development）する方法
みなさんこんにちは。@ryuzeeです。 RubyであればRSpecやCucumberとか使って、むしろBDDしているケースの方が多いようですが、PHPでやっている事例はあまり聞きません。 とりあえずPHPでもBDDできることは確認できたので、その方法をご紹介します。 ※実戦投入にはもうちょっと検証は必要かもしれません。 BDDとは？BDDとはビヘイビア駆動開発（Behavior Driven Development）でテスト駆動開発から派生したものです。 テスト駆動開発とドメイン駆動設計を統合したようなイメージになります。 対象における「振る舞い」や「制約条件」の検証のために、自然言語的な記述でテストコードを記述します。 スペックファーストで仕様を作ってから実装するという流れになります（コードを書く前に振る舞いを決める）。 ということで、以下ではPHPでBDDを行う方法について解説してい
レガシーコード改善ガイド読書会 2010-04-03 - 未来のいつか/hyoshiokの日記
先日、会社でレガシーコード改善ガイド読書会を行った。1回しかやっていないので、今後どんな感じになるのか正直わからないが、1回目の振り返りを記してみる。 〆会、テスト勉強会（社内）などで有志を募ったところ、なんやかんやで10数名が名乗りを上げてくれた。どんなペースでやるかとか運営をどうするかとかを相談するために、参加希望者で集まった。週1回（木曜日、19時開始）、担当の章などを決めた。第1章〜第5章までは各自で読んで、読書会への参加の動機などを含めて簡単なポジションペーパーとしてまとめることにした。 わたしが、読書会の世話役として、会議室の確保（空き会議室を見つけて予約しただけ）、開催のアナウンスなどを行った。資料置き場の共有ディレクトリ、社内Wikiなどを立ち上げた。*1 テストがないコードはレガシーコードだ！ 「テストがないコードはレガシーコードだ」という強烈なフレーズが表紙に書いてある
【告知】「JaSST'11 Tokyo (#jasst) 第2日目/ 1月26日(水) E5 新しいTDDアプローチ TDDの新しい活かし方をライブで見せます！」に登壇します - t-wada の日記（旧）
ハッシュタグ #jasst 今日は告知ばかりで申し訳ありません。三つめの告知エントリです。ソフトウェアテストシンポジウム(通称 JaSST)、のパネルディスカッションに登壇させていただきます。 ■E5 新しいTDDアプローチ TDDの新しい活かし方をライブで見せます！ TDD研究会 テスト駆動開発(TDD)は、アジャイル開発手法であるXPのプラクティスとして紹介されて以来、アジャイル開発に限らず多くのソフトウェア開発現場で用いられるようになってきました。 TDDは開発の中に「Red⇒Green⇒Refactor」のリズムを作ることで、開発者に安心感を与えるのと同時に、品質や生産性の向上にも貢献することが知られています。 その一方、TDDが多くの現場で用いられるようになるにつれ、TDDの成果物の1つであるテストケースと、従来テスト工程で作られてきたテストケースの間に溝があることが指摘されるよ
テスト駆動開発・実践編 - Strategic Choice
ケント・ベック師の著書で、TDDの教科書「テスト駆動開発入門」の、「Part1 Money オブジェクトの例」を写経して、TDDを「実践」し、これまで学習した「パターン」「プラクティス」を理解し、定着させます。目次テスト駆動開発・実践編01・黄金の回転（「第1章 複数通貨のMoney」より）テスト駆動開発・実践編02・テストファースト（「第2章 オブジェクトの退化」より）テスト駆動開発・実践編03・（「第3章 すべてに対する等価性」より）テスト駆動開発・実践編04・（「第4章 プライベート化」より）テスト駆動開発・実践編05・（「第5章 『フランク』に話す」より）テスト駆動開発・実践編06・（「第6章 再度、すべてに対する等価性」より）テスト駆動開発・実践編07・（「第7章 りんごとみかん」より）テスト駆動開発・実践編08・（「第8章 オブジェクトの生成」より）テスト駆動開発・実践編09・
テスト駆動開発・パターン編 - Strategic Choice
ケント・ベック師の著書で、TDDの教科書「テスト駆動開発入門」の「Part3 テスト駆動開発のためのパターン」をまとめ、「TDDの戦略」「TDDの定石」「TDDのプラクティス」を身につけます。はじめにファーストステップテスト駆動開発のパターンテスト方法の詳細の前の、基本的な戦略に関するパターンです。「テストすることは何を意味するのか」「いつテストするのか」「テストするロジックをどのように選択するのか」「テストするデータをどのように選択するのか」を吟味します。Test（テスト）Isolated Test（独立したテスト）Test List（テストリスト）Test First（テストファースト）Assert First（アサートファースト）Test Data（テストデータ）Evident Data（明示的データ）レッドバーに関するパターンテスト作成を開始するタイミング、テストを作成する場所、テ
機能テストの自動化に向けて - nemuzukaの「明日から本気出す」
前回は、ツールを使っても機能テストを自動化するハードルは低くないですよ、ということを書きました。 残念ながら、高いお金を払って購入したテストツールもスケジュールが間に合わない現場の品質担保の救世主にはなりえません。やっぱりロジック部分の単体テストレベルはおとなしくxUnitを書いた方が早いでしょう。*1 ですが、機能テストの自動化に成功して、ViewやController部分がデグレった箇所を検知してくれるようになれば開発現場のモチベーションは上がるでしょう。 では、機能テストの自動化には、何を準備すればいいでしょうか？私の経験と妄想から、いくつか述べてみようかと思います。 動的な要素を固定にできる仕組み 外部パラメータで処理がスタブ化できれば、いつテストを実施しても結果は等しくなります。例えば、システム日付はテスト実行時毎に変わってしまうのですが、JVMのパラメータやプロパティファイルの
私家版テスト駆動開発 - rabbit2goのブログ
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由
【ハウツー】xUnit.NETでユニットテストをしてみよう【前編】 (1) xUnit.NETの入手と環境設定 | エンタープライズ | マイコミジャーナル
xUnit.NETは.NET 2.0以上で動作するテストツールで、MicrosoftのBrad Wilson氏とJames Newkirk氏が中心となって開発を進めています。xUnit.NETは拡張性の向上、カスタム属性の減少、メソッドごとのインスタンス生成を特徴としており、Moq、Ninject、Oxite、KiGGなどのOSSにも採用されています。以下、xUnit.NETの導入方法、テストコードを紹介します。 xUnit.NET の入手と環境設定 xUnit.NET はCodePlexから入手できます。執筆時点での最新バージョンは1.6です。「xunit-1.6.zip」をダウンロードして適当なフォルダ(本稿ではC:\Sample\xunit)に展開します。これには以下のようなファイルが含まれています。 xUnit.NETのWebサイト インストールウィンドウ(xunit.instal
tanabata.tracに参加してきました - tomo_snowbug’s diary
ブログに書くまでが勉強会です。とid:kanu-orzさんがおっしゃっていたので所感を書いてみようと思います。 Shibya.tracは初めて参加させていただきました。 知っている人が居ない状態でしたが、楽しかったです！ あと、ビアバッシュも初体験。ビール大好きなので、ぜひ、社内の勉強会でもやってみたいです。 スタッフの皆さん、スピーカーの皆さん、参加者の皆さん、お疲れ様でした！ USTのリンクも貼っておいてと。 http://www.ustream.tv/recorded/8125667 http://www.ustream.tv/recorded/8127374 以下、自分なりのメモです。 ゆかわさん id:wyukawa - 大規模受託案件(Java)でのHudsonの導入事例紹介 Hudsonをコンパイルエラーの検知のために導入した 途中から入った案件で、入った当初はコンパイルエラ
TDD BootCamp Hokuriku Extra Day - Development Antinews
これは個人的なイベントというか、起きたこととそれの観察記。 そして、BootCamp と日常を重ねて思ったことなど。 大変だ！ レガシーコードの修正だ！TDDBC の翌日は普通に仕事していたのですが、この現場には Camp とは比較にならない劣悪なレガシーコードがゴロゴロしています。 そこに修正の依頼が入りました。自分にじゃないですが。電話口のやりとりを小耳に挟んだので、要求を再確認。 対象はいわゆるMVCフレームワークを利用したWebアプリ最速でやってくれ（ここがもう「なんだかな」ではあるんだが）変更を加える必要のあるメソッドはもう見つかっているが、これが一つで140行あってベッタベタ できるだけここはいじりたくないいやぁ、レガシーだねぇ。 どうやら基本的にはブラックリストの考え方で迂回する方法で実現できそうだなんか censor のない Camp ネタのように見えるなこの部分だけ切り出
xDDについて考える(その1)
※このブログはデブサミ後のTwitterで話題になっていた時に下書きしていたものをそのままUPしています。 先日TDDBootCamp北陸に参加して少し考えたところもあるのですが、それは別エントリに。 最近xDD(???-driven development)という言葉が色々取り上げらています。 TDD(Test-driven development) BDD(Behavior-driven development) SDD(story-driven development) DDD(Domain-driven development) ※ここでTiDD(Ticket-driven development)のような技法を含んでいないのは、ちょっと方向性が違うかなと思ったためです。 デブサミでも話題になったそうで、Twitter上でも色々議論が流れているようですが、 ちょっといま忙しくてほと
TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
toshiyukikawanishi.net