C/C++でのユニットテストによるメモリリーク検出 - 千里霧中
CやC++の開発ではメモリリークに悩まされることが多い。メモリ管理はスマートポインタに限定するなど自分たちが注意しても、外部で開発されたコードやレガシーコードによって結局逃れられないことがしばしばある。 さらに組み込み開発といったコードの実行環境に制約が多い場合は、検出や再現がやりにくいことから、メモリリークのデバッグやテストが結構なストレスになることがある。 こうした、面倒な問題になりがちなメモリリーク対応では、全てに対応できるというわけではないけれど、ユニットテストでの検証が有効なことが多い。ユニットテストならば、再現性の確保、異常な入力の実現、コードの切り分けといったものが容易なためだ。デバッグ等で便利なので、今回いくつかの方法をまとめたいと思う。 対象のコード 今回はメモリリークを発生させる題材として、以下のコードを解析する。 class Base { }; class Hoge
C言語向けユニットテスティングフレームワーク Cmockeryについて - 千里霧中
このブログでCppUTest、PCUnit、Unityと紹介してきたので、この流れを続けてTDDBCで使われたC言語のユニットテスティングフレームワークを紹介していきたいと思います。今回はTDDBC大阪で使われたCmockeryについて。 なおTest Doubleについて詳しくない方は、本エントリを読む前に予備知識として「xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中の犀」を読んでおくと良いかもしれません。 Cmockeryとは google製のC言語向けのユニットテスティングフレームワーク。 サイト：http://code.google.com/p/cmockery/ シンプルなフレームワーク。マルチプラットフォームにそれなりに対応。 ユニットテスティングフレームワークとしての機能はかなり簡素。
Eclipse CDTを使ったMacでのPCUnitの環境構築 - 千里霧中
引き続きTDDBC大阪向けの資料です。 TDDBC大阪ではCのテスティングフレームワークにPCUnitが選択されそうなので、今回はPCUnitの概要と、Mac OS XでのEclipse CDT上のPCUnitの環境構築方法をまとめます。なおPCUnitはRubyスクリプトによるテストコード自動生成が大変便利なので、今回はスクリプト実行環境も合わせて構築しています。 ちなみにPCUnitは日本人の @katono123 さんが開発したものであるため、既に分かりやすい日本語ドキュメントが「katono/PCUnit · GitHub」等で公開されています。入門の際は本エントリよりまずそちらを当たった方が無難だと思います。 PCUnitについて 組み込み開発も対象に含むC/C++向けユニットテスティングフレームワーク サイト: https://github.com/katono/PCUnit
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
ユニットテストの網羅性の扱いについて - 千里霧中
テストの網羅性については様々なものがある。基本的な網羅性の観点としては、構造ベース、仕様ベース、外部の標準や指標ベースなどが挙げられる。 そして観点ごとに、様々な網羅性の指標がある。ユニットテストの場合だと、例えば以下がある。 コードの構造網羅 コードの構造を網羅する。ここでいうコードの構造としては、制御フロー、データーフロー、例外フローなどがある。具体的な指標としては、コードカバレッジが有名。コードの構造網羅では、コードカバレッジなどを基準にして、基準以上の網羅性を確保できるようにテストを設計する。 なお、構造網羅というと、一般的な定義ではコード以外の構造も扱われるが、このブログでは便宜上「構造網羅をコードの構造を網羅すること」という定義に絞り込んで説明する。 仕様網羅 コードの仕様を網羅する。コードの仕様には、対象（対象の粒度はテストレベルに依存する。例えば関数やクラス、モジュールを単
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
組み込み開発へのテスト駆動開発の導入 - 千里霧中
早速テスト駆動開発(以下TDD)について検討を始めましたが、やはり組み込みではいろいろ困難が伴いますね。 一番大きな障壁は、ホスト上でのテスト環境の構築です。組み込みでのテストにおいて、ターゲットを伴ったテストは当然必要でしょうが、ターゲットが形になってからテストを始めるのは、遅すぎてとてもTDDとはいえません。そのためTDD導入にはまずターゲットに依存しないテスト環境が必要になります。しかしそのターゲット非依存のテスト環境の構築というのが難しい。 ターゲット非依存のテスト環境としては、一般的なものとして2つ挙げられると思います。1つはターゲット非依存のコードを器用に抜き出して単体テストを行う、実機を伴わないテスト環境。もう1つはターゲットに近い実機環境で実現される、実機を伴うテスト環境です。 実機を伴わないテスト環境 まず実機を伴わないテスト環境についてですが、なかなか簡単にいきません。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
