「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」 - カレーなる辛口Javaな加齢日記
注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1 http://www.publickey1.jp/blog/12/8585.html http://www.keyman.or.jp/at/dev/debug/30004610/ 数値の正確さはともかく，だいたいそんなもんでしょう． 「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない． そもそもテストを知らない．テスト＝手動テストだと思っている． デバッグといえばデバッガでするものだと思っている． 導入するメリットが理解できない． テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1 導入するスキルがない．
設計におけるTDD-全てのアジャイル開発者へ- #swtestadvent2011 - うさぎ組
「Software Test ＆ Quality Advent Calendar 2011」 : ATND テストと品質に関するAdventCalendarです。 やりたい！っていうことで、登録してみましたが、見習いテストエンジニアとしてはなかなか書くことがありませんでした。 ということで、僕が最近思いついたことを書きます。 「設計におけるTDDとは存在するのか？」です。 現在ではTDDは開発手法として大きく認知され、xUnit系やSpec系をはじめとした多くのテスティングフレームワークでプロダクトコードに対するテストコードを書いて、リファクタリングをつづけるというサイクルを行う事で早い段階で良質なコードを生み出すことに成功しています。 ではプロダクトコードの前の段階である設計ではどうなのでしょうか？ コーディングの前に設計することはたくさんあります。 フレームワークやインフラや言語の選定
TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組
@t_wada「TDDはスキルです。量は質に転化する」 TDD Advent Calendar2011の記事になります。 TDD Advent Calendar jp: 2011 : ATND 前：@irof テストと言うパートナー #TddAdventJp - 日々常々 次：@yuya_takeyama さんです。 はじめに これは僕の主観であって、間違いもあると思います。それは僕の勉強不足から生じるものです。 どちらかというと、これを読んだ方に「そこはちょっと認識が一般的じゃない」「そもそも違うよ」って突っ込んでもらうためのものです。 「TDDよくわからないので教えてください」っていう記事です。 TDDをはじめたい人、TDDに行き詰まっている人 TDDがどんなものかよくわからない人、とりあえずテストコードって書いているけど毎回つまずいて成長が実感出来ない人、現場に導入したいけど伝え方が
テスト駆動を導入するための3つのポイント
前編「テストを金額にするといくら？」ではテストの価値を価格として算出し、その重要性を検証するという思考実験を行いました。その結果、大ざっぱながらも、テストの重要性に少し現実味が持てたのではないでしょうか。後編では、テスト駆動開発をプロジェクトに導入して、運用するための具体的なノウハウを紹介します。 テスト駆動開発（TDD）を回すのにもノウハウが要る TDDでは、いままでよりユニットテストコード作成にウェイトが置かれるので、ユニットテストコード作成の進ちょくがプロジェクトの進ちょくに与える影響は大きくなります。つまり、ユニットテストコード作成の効率性をより高めていかなくてはならないわけです。 では、ユニットテストコード作成の効率性を高めるには、具体的にどうすればよいでしょうか？ まずは以下の2点を押さえるべきでしょう。 EoTの高い設計になっていること テストコードが正確に業務仕様を表してい
テストを金額にするといくら？ ― ＠IT
テスト駆動開発（Test Driven Development：TDD）。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。 テスト駆動開発（TDD）とは テスト駆動開発は一般にエクストリーム・プログラミング（XP）の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なもの
TDDBC Fukuoka Day1
TDD Boot Camp Fukuoka Day1 - Mar 19, 2011 at FukuokaRead less
J2EE勉強会での発表資料を公開します - t-wadaの日記
id:takubonさんからいただいたコメントに触発されてちょっと書いてみます。 リリースを行う際に利用者に公開したインターフェイスが「公布済みインターフェイス(published interface)」になります。短い期間のイテレーションを繰り返してチーム間で結合を繰り返していく場合には、利用者は他のチームとなります。イテレーションの期間に応じて不完全な形でインターフェイスを公布する機会があるかもしれませんし、実際に機能を制限してリリースを行ったりもします。 短い期間で反復開発しているということは、インターフェイスを公布する機会が増えるということです。公布する機会が増えれば、リファクタリングの範囲が公布済みインターフェイスに引っかかる確率も増えます。すると、公布済みインターフェイスの変更はリファクタリングの枠を越えて「仕様変更」となってしまうことが多くなってしまいます。 これがイテレーシ
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
＠IT：特集 「テスト駆動開発」はプログラマのストレスを軽減するか？
新しいソフトウェア開発技法へチャレンジできるか？ ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング（XP）という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
よい単体テストの特徴と、書くためのヒント - builder by ZDNet Japan
Alan Cooper氏著の「The Inmates Are Running the Asylum」（邦題「コンピュータは、むずかしすぎて使えない！」）で、同氏は「軍艦にコンピュータが導入されたら何が起こるか」という問いを発している。同氏は、米国のミサイル巡洋艦ヨークタウンが大西洋で艦隊行動を行っていた際に起きた事件を例に挙げた。その時、海軍の技術者は燃料バルブを調整しており、艦上管理コンピュータの1つにゼロを入力した。すると、プログラムは入力されたゼロの値で別の数を割ろうとして（この解は数学では未定義となる）、ドカン！制御システム全体が完全にクラッシュしてしまい、海岸に曳航できるようになるまで、何時間も水上で立ち往生してしまったのだ。 この艦の管理システム全体が、設置前にはまったくテストされず、なんらかの形のテスト運用も行われなかったというのは考えにくいことだ。このシナリオは、「本当に？
[tDiary][ruby][security] tDiary の脆弱性に関する注意喚起, [TDD][Work] TDDと品質とビジネス, [DNS] hsbt.org のレジストラを livedoor ドメインにした, [DNS][.. - HsbtDiary(2010-02-25)
■ [tDiary][ruby][security] tDiary の脆弱性に関する注意喚起 tDiary に XSS 脆弱性が発見されたため、対応策と対策済みバージョンが公開されています。詳細は以下を参照してください。 tDiaryの脆弱性に関する報告 tDiary 2.2.3リリース この脆弱性を確認するために、VirtualBoxにライセンスが余っているXPをわざわざインストールして、IE8がデフォルトでアップデート表示されるなかIE7をインストールして、環境を再現したのは内緒です。これはひどい。 ■ [TDD][Work] TDDと品質とビジネス 最初に宣言しておくと受託開発の話ね。投資先が自分達であるところの自社サービスやパッケージの場合はまた違う話になるのでここでは触れません。また、理解が不足、話を勘違いしている部分も多々あると思うので、違う部分は指摘してもらえると助かります。
![[tDiary][ruby][security] tDiary の脆弱性に関する注意喚起, [TDD][Work] TDDと品質とビジネス, [DNS] hsbt.org のレジストラを livedoor ドメインにした, [DNS][.. - HsbtDiary(2010-02-25)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
TDDを行うとソフトウェアの信頼度が上がる理由 - babie, you're my home
「TDDはテスト手法か否か」の議論で、いまいち私の考えが伝えきれてないようでした(link1, link2)ので、表題にあることを通じて、私のTDDに対する理解の説明を試みます。 用語説明 本題に入る前にこれから使う用語を説明しておきます。 科学的方法には、伝統的な方法としてベーコン由来の実証主義、割と最近のポパー由来の反証主義があります。それぞれ批判はあるのですが、２大潮流といって差し支えないと思います（私は科学哲学については勉強中であり近年の研究はフォローしてないこと、また、観点が反証主義よりなことを、お断りしておきます）。 ここでは、 実証主義……実証の積み重ねから信頼度の高い理論が導けるとする態度 反証主義……様々な反証テストに耐えた理論が信頼度が高いとみなす態度 とします。 先の用語に出てきた、実証、反証とは、 実証……ある理論を経験や実験から真であると証明すること 反証……ある
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
TDDはテスト手法か否か
なんもわからん @babie TDDは論理実証主義的な面が強調されすぎたために、BDDなどという言い換えが行われた。反証主義的に、エラーを積極的に起こそうとするテストを書くべき。 2010-02-21 13:45:09
深夜のテストTL
ヨシオリX @yoshiori なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ 2010-02-15 00:43:52 ヨシオリX @yoshiori 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。 2010-02-15 00:47:13
index at XUnitPatterns.com
xUnit Test Patterns - the book The book has won a Jolt Productivity Award in the Best Technical Book category! Here's what the reviewer Rick Wayne said about why the book won the award: Unit testing is hardly news, but simply writing a ton of tests guarantees you no bliss. Gerard Meszaros's xUnit Test Patterns distills and codifies the crucial meta-knowledge to take us to the next level. Why do go
Visual Studio 2008単体テスト機能のすべて ― ＠IT
Visual Studio 2008単体テスト機能のすべて：特集：Visual Studio 2008単体テスト機能徹底活用（前編）（1/4 ページ） 連載目次 Visual Studio 2005（以下、VS 2005）では上位エディションであるTeam Developerでのみ利用可能だった単体テスト機能が、Visual Studio 2008（以下、VS 2008）からは、Professional Editionでも利用可能になった。 VS 2008の1機能として導入されるほど単体テストが脚光を浴びるようになったのは、やはりアジャイル開発の普及だろう。アジャイルで開発する場合、単体の品質が非常に重要になる。また、リファクタリングなどで繰り返しテストが必要になるケースが多いため、テストを自動化するという考えが生まれ、単体テストの注目度はさらに増している。 本稿では、このVS 2008
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD について
