レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必
C言語・C++言語用テスティングフレームワーク - Cutter
最新リリース 2019-09-13にリリースされた1.2.7が最新です。 [ダウンロード] [変更点] Cutterとは Cutterは書きやすさ・デバッグのしやすさを重視したC言語・C++言語用のテスティングフレームワークです。メンテナンスしやすく、利用効果の高い単体テスト（ユニットテスト）の開発を支援します。 また、テストを苦痛ではなく、楽しいものにすることも重視しています。スクリーンショットはテスト結果の通知機能を利用している様子です。文字としてテストのパス・失敗を伝えるだけではなく、視覚的にも通知することで、テスト結果をわかりやすくします。わかりやすいので、頻繁にテストを実行したくなります。この機能はnotify-sendコマンド（Linuxや*BSDなどの場合）またはgrowlnotifyコマンド（macOSの場合）を利用します。 動作環境 CutterはDebian GNU/L
新人注目！ テストを極める最初の一歩 記事一覧 | gihyo.jp
第3回コピー＆ペーストでテスト仕様書を作っていませんか？ 鈴木三紀夫，池田暁 2008-07-14
TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組
@t_wada「TDDはスキルです。量は質に転化する」 TDD Advent Calendar2011の記事になります。 TDD Advent Calendar jp: 2011 : ATND 前：@irof テストと言うパートナー #TddAdventJp - 日々常々 次：@yuya_takeyama さんです。 はじめに これは僕の主観であって、間違いもあると思います。それは僕の勉強不足から生じるものです。 どちらかというと、これを読んだ方に「そこはちょっと認識が一般的じゃない」「そもそも違うよ」って突っ込んでもらうためのものです。 「TDDよくわからないので教えてください」っていう記事です。 TDDをはじめたい人、TDDに行き詰まっている人 TDDがどんなものかよくわからない人、とりあえずテストコードって書いているけど毎回つまずいて成長が実感出来ない人、現場に導入したいけど伝え方が
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
googletest - Google C++ Testing Framework - Google Project Hosting
