# -*- rd -*-

= チュートリアル --- Cutterの使い方

== はじめに

スタックを実現するプログラム（ライブラリ）をC言語で作成する。
プログラム作成はテストを作成しながら行う。テストの作成にはC
言語用のテスティングフレームワークであるCutterを用いる。

プログラムのビルドシステムにはGNUビルドシステム（GNU
Autoconf/GNU Automake/GNU Libtool）を使用する。GNUビルドシス
テムはビルド環境の差異を吸収する。これによりプログラム・テス
トを複数の環境で容易にビルドできるようになる。

大きなコストをかけずにプログラム本体が複数の環境で動作するの
であれば、その方がよい。さらにテストもその環境で動作するのな
らば、プログラム本体がその環境で正しく動作することを容易に検
証できる。プログラム本体だけではなく、テストも複数の環境で容
易に動作することは重要である。

Cutterが依存しているライブラリはGLibのみである。GLibはUNIX系
のシステムだけではなく、WindowsやMac OS X上でも動作する移植
性の高いライブラリである。CutterはGLibを利用することにより移
植性の高い状態を保ちつつ豊富なテスト支援機能を提供するxUnit
系のテスティングフレームワークである。

以下、スタックを作成しながらCutterの使い方について述べる。
なお、Cutterはインストールされているものとする。

このプログラムのソースコード一式はsample/stack/以下にある。

== ディレクトリ構成

まず、プログラムを作成するためのディレクトリを用意する。ディ
レクトリはstackとする。

  % mkdir -p /tmp/stack
  % cd /tmp/stack

続いて、stack/ディレクトリ以下にビルド補助ファイル用ディレク
トリconfig/、プログラム用ディレクトリsrc/、テストプログラム用
ディレクトリtest/を作成する。

  [stack]% mkdir config src test

つまり、ディレクトリ構成は以下のようになる。

  stack/ -+- config/ ビルド補助用ディレクトリ
          |
          +- src/ ソースファイル用ディレクトリ
          |
          +- test/ テストプログラム用ディレクトリ

== GNUビルドシステム化

GNUビルドシステムでは、コマンドを実行し、いくつかのファイルを
自動生成する。これらのコマンドは、autogen.shというシェルスク
リプトを作成し、そこから呼び出すのが一般的である。ここでも、
その慣習に従う。

autogen.sh:
  #!/bin/sh

  run()
  {
      $@
      if test $? -ne 0; then
          echo "Failed $@"
          exit 1
      fi
  }

  run aclocal ${ACLOCAL_ARGS}
  run libtoolize --copy --force
  run autoheader
  run automake --add-missing --foreign --copy
  run autoconf

autogen.shに実行権を付けることを忘れないこと。

  [stack]% chmod +x autogen.sh

run()はコマンドの実行結果を確認するための便利のための関数で
ある。実行しているコマンドはそれぞれ以下のためである。

  * aclocal: Automakeが利用するマクロをaclocal.m4に集める
  * libtoolize: libtoolを使用するために必要なファイルを用意
  * autoheader: configureスクリプトが利用するconfig.h.inファイルを作成
  * automake: configureスクリプトが利用するMakefile.inを生成
  * autoconf: configureスクリプトを生成

もし、Cutterをaclocalと異なるprefixでインストールしている場合
はACLOCAL_ARGS環境変数を指定する。この環境変数はautogen.sh内
で参照している。ここでは、prefixを$HOME/localとしてCutterをイ
ンストールしたものとする。

  [stack]% export ACLOCAL_ARGS="-I $HOME/local/share/aclocal"

この時点でautogen.shを実行すると以下のようになる。

  [stack]% ./autogen.sh
  aclocal: `configure.ac' or `configure.in' is required
  Failed aclocal

Autoconf用のファイルであるconfigure.acを用意する必要がある。

=== configure.ac

autogen.shのための最低限のconfigure.acは以下の通りである。

configure.ac:
  AC_PREREQ(2.59)

  AC_INIT(stack, 0.0.1, you@example.com)
  AC_CONFIG_AUX_DIR([config])
  AC_CONFIG_HEADER([src/config.h])

  AM_INIT_AUTOMAKE($PACKAGE_NAME, $PACKAGE_VERSION)

  AC_PROG_LIBTOOL

  AC_CONFIG_FILES([Makefile])

  AC_OUTPUT

configure.acを用意してもう一度autogen.shを実行すると以下のよ
うになる。

  [stack]% ./autogen.sh
  Putting files in AC_CONFIG_AUX_DIR, `config'.
  configure.ac:7: installing `config/install-sh'
  configure.ac:7: installing `config/missing'
  automake: no `Makefile.am' found for any configure output
  Failed automake --add-missing --foreign --copy

今度はAutomakeのためにMakefile.amを用意する必要がある。

=== Makefile.am

autogen.shのためだけであれば空のMakefile.amで構わない。

  [stack]% touch Makefile.am
  [stack]% ./autogen.sh
  Putting files in AC_CONFIG_AUX_DIR, `config'.

これでconfigureスクリプトが生成される。この時点で一般的なソ
フトウェアのようにconfigure; make; make installができるよう
になる。

  [stack]% ./configure
  ...
  [stack]% make
  [stack]% make install

ただし、ビルドするものもインストールするものも何もないため、
今は何も起きない。

== はじめてのテスト作成

最低限のビルド環境が整ったので、テストの作成にはいる。まずは、
新しく作ったばかりのスタックは空であることをテストする。コー
ドにすると以下の通りである。

  void
  test_new_stack (void)
  {
      Stack *stack;
      stack = stack_new();
      if (stack_is_empty(stack))
          PASS;
      else
          FAIL;
  }

ここでは、上記のテストをCutterのテストとして動作させる。

=== テストプログラムの作成

テストプログラムはtest/以下に作成する。ここでは
test/test-stack.cとして作成するものとする。

まず、Cutterを使うためにcutter.hをincludeする。

test/test-stack.c:
  #include <cutter.h>

また、テスト対象のスタックの実装のAPIが書かれているstack.hも
includeする。（stack.hは後で作成する。）

test/test-stack.c:
  #include <stack.h>

続いて、このスタックのAPIを用いてテストを作成する。

test/test-stack.c:
  void
  test_new_stack (void)
  {
      Stack *stack;
      stack = stack_new();
      cut_assert(stack_is_empty(stack));
  }

cut_assert()は引数が0ならテストが失敗、0以外ならテストが成功
と判断するマクロである。Cutterのテストとはcut_XXX()マクロを使
用して、特定の状況で望んだ動作をしているかを検証するプログラ
ムを作成するということである。

以下に、「作成したばかりのスタックは空である」ということを検
証するテストのソースコード全体を示す。

test/test-stack.c:
  #include <cutter.h>
  #include <stack.h>

  void test_new_stack (void);

  void
  test_new_stack (void)
  {
      Stack *stack;
      stack = stack_new();
      cut_assert(stack_is_empty(stack));
  }

=== テストのビルド

Cutterの各テストは共有ライブラリになる。上記で作成したテスト
を共有ライブラリとしてビルドするために、Makefile.amを変更す
る。

==== test/以下でのビルド設定

現在のMakefile.amは空である。

まず、make経由でaclocalが実行された場合にもautogen.sh用に設
定したACLOCAL_ARGS環境変数が使われるように以下を追記する。

Makefile.am:
  ACLOCAL_AMFLAGS = $$ACLOCAL_ARGS

次に、サブディレクトリであるtest/以下のtest/test-stack.cをビ
ルドするためにはMakefile.amにtest/以下がサブディレクトリとし
て存在することを指定する。

Makefile.am:
  ...
  SUBDIRS = test

Makefile.amを変更した後にmakeを実行すると、makeがMakefile.am
の変更を検出し、Makefileなどを自動的に更新する。

  [stack]% make
   cd . && /bin/sh /tmp/stack/config/missing --run automake-1.10 --foreign  Makefile
   cd . && /bin/sh ./config.status Makefile 
  config.status: creating Makefile
  Making all in test
  make[1]: ディレクトリ `/tmp/stack/test' に入ります
  make[1]: *** ターゲット `all' を make するルールがありません.  中止.
  make[1]: ディレクトリ `/tmp/stack/test' から出ます
  make: *** [all-recursive] エラー 1

test/以下もビルドしにいこうとしているのがわかる。ただし、
test/Makefileがないためtest/以下でのビルドは失敗している。

test/以下でビルドを行うようにするため、test/Makefile.amを作成
する。また、configureがtest/Makefileを生成するように
configure.acに指定する。

test/以下でのmakeが失敗しないようにするには、空の
test/Makefile.amでもよい。

  [stack]% touch test/Makefile.am

あとはconfigure.acにtest/Makefileを生成するように指定すれば
makeは通るようになる。

configure.ac:
  ...
  AC_CONFIG_FILES([Makefile
                   test/Makefile])
  ...

実際にmakeを実行すると自動で再びconfigureが走り、
test/Makefileが生成され、test/以下でのmakeが失敗しなくなる。

  [stack]% make
  ...
  config.status: creating test/Makefile
  config.status: creating src/config.h
  config.status: src/config.h is unchanged
  config.status: executing depfiles commands
  Making all in test
  make[1]: ディレクトリ `/tmp/stack/test' に入ります
  make[1]: `all' に対して行うべき事はありません.
  make[1]: ディレクトリ `/tmp/stack/test' から出ます
  make[1]: ディレクトリ `/tmp/stack' に入ります
  make[1]: `all-am' に対して行うべき事はありません.
  make[1]: ディレクトリ `/tmp/stack' から出ます

==== test/test_stack.soのビルド

それではtest/test-stack.cを共有ライブラリとしてビルドできる
ようにtest/Makefile.amを編集する。テスト用の共有ライブラリは
「test_」から始まる名前にする（「test_」の前に「lib」が付い
ても良い）。また、テストプログラムはインストールする必要がな
いため「noinst_」を使う。

test/Makefile.am:
  noinst_LTLIBRARIES = test_stack.la

テストの共有ライブラリはCutterが提供するテスト実行コマンド
cutterから動的に読み込まれる。動的に読み込まれる共有ライブラ
リは、libtoolに-moduleオプションを渡す必要がある。ま
た、-moduleオプションを指定する場合-rpathも指定する必要がある。
そこで、LDFLAGSを以下のように指定する。-avoid-versionはテスト
の共有ライブラリにはバージョン番号を付ける必要がないため指定
している。-no-undefinedは未定義のシンボルがある場合にエラーを
報告するオプションである。環境によっては-no-undefinedを指定し
ないと共有ライブラリが作成されないため指定している。（例えば、
Windows上でDLLを作成する場合）

test/Makefile.am:
  ...
  LDFLAGS = -module -rpath $(libdir) -avoid-version -no-undefined

test/test_stack.laのビルド（test_stack.soはtest/.libs/以下に
作成される）にはtest/test-stack.cを使用するので、それを指定す
る。

test/Makefile.am:
  ...
  test_stack_la_SOURCES = test-stack.c

これでtest/test_stack.laがビルドできる。

  [stack]% make
  ...
   cd .. && /bin/sh /tmp/stack/config/missing --run automake-1.10 --foreign  test/Makefile
  test/Makefile.am: required file `config/depcomp' not found
  test/Makefile.am:   `automake --add-missing' can install `depcomp'
  make[1]: *** [Makefile.in] エラー 1
  ...

config/depcompを生成するには--add-missingオプション付きで
automakeを実行する必要がある。これにはautogen.shを使用できる。
また、configureを再実行する必要もある。

  [stack]% ./autogen.sh
  [stack]% ./configure

これでmakeを実行することによりtest/test_stack.laができるよう
になる。

  [stack]% make
  ...
  test-stack.c:1:20: error: cutter.h: そのようなファイルやディレクトリはありません
  test-stack.c:2:19: error: stack.h: そのようなファイルやディレクトリはありません
  test-stack.c: In function ‘test_new_stack’:
  test-stack.c:9: error: ‘Stack’ undeclared (first use in this function)
  test-stack.c:9: error: (Each undeclared identifier is reported only once
  test-stack.c:9: error: for each function it appears in.)
  test-stack.c:9: error: ‘stack’ undeclared (first use in this function)
  make[1]: *** [test-stack.lo] エラー 1
  make[1]: ディレクトリ `/tmp/stack/test' から出ます
  make: *** [all-recursive] エラー 1

ただし、上記のようにCutterを使用する設定を行っていないため
cutter.hが読み込めない。また、スタックの実装もないため
stack.hの読み込みにも失敗する。

==== Cutterの使用

まずは、cutter.hを読み込めるようにする。Cutterはaclocal用のマ
クロファイルを提供している。そのため、容易にGNUビルドシステム
から利用することができる。

まず、configure.acにCutterを検出するコードを追加する。

configure.ac:
  ...
  AC_CHECK_CUTTER

  AC_CONFIG_FILES([Makefile
                   test/Makefile])
  ...

また、test/Makefile.amでは検出したCutter用の設定を利用する。

test/Makefile.am:
  ...
  INCLUDES = $(CUTTER_CFLAGS)
  LIBS = $(CUTTER_LIBS)
  ...

現時点での完全なconfigure.ac、Makefile.am、test/Makefile.amは
以下のようになる。

configure.ac:
  AC_PREREQ(2.59)

  AC_INIT(stack, 0.0.1, you@example.com)
  AC_CONFIG_AUX_DIR([config])
  AC_CONFIG_HEADER([src/config.h])

  AM_INIT_AUTOMAKE($PACKAGE_NAME, $PACKAGE_VERSION)

  AC_PROG_LIBTOOL

  AC_CHECK_CUTTER

  AC_CONFIG_FILES([Makefile
                   test/Makefile])

  AC_OUTPUT

Makefile.am:
  ACLOCAL_AMFLAGS = $$ACLOCAL_ARGS

  SUBDIRS = test

test/Makefile.am:
  noinst_LTLIBRARIES = test_stack.la

  INCLUDES = $(CUTTER_CFLAGS)
  LIBS = $(CUTTER_LIBS)

  LDFLAGS = -module -rpath $(libdir) -avoid-version -no-undefined

  test_stack_la_SOURCES = test-stack.c

AC_CHECK_CUTTERマクロ内では一般的なパッケージ情報管理ツールで
あるpkg-configを使用している。もし、Cutterをpkg-configと異な
るprefixでインストールしている場合はPKG_CONFIG_PATH環境変数を
指定する。この環境変数はpkg-configが.pcファイルを検索するため
に利用する。ここではprefixを$HOME/localとしてCutterをインストー
ルしたものとする。

  [stack]% export PKG_CONFIG_PATH=$HOME/local/lib/pkgconfig

変更後、makeを実行すると自動的にconfigureが実行され、Cutter
を利用したビルドが行われる。

  [stack]% make
  ...
  test-stack.c:2:19: error: stack.h: そのようなファイルやディレクトリはありません
  test-stack.c: In function ‘test_new_stack’:
  test-stack.c:9: error: ‘Stack’ undeclared (first use in this function)
  test-stack.c:9: error: (Each undeclared identifier is reported only once
  test-stack.c:9: error: for each function it appears in.)
  test-stack.c:9: error: ‘stack’ undeclared (first use in this function)
  make[1]: *** [test-stack.lo] エラー 1
  make[1]: ディレクトリ `/tmp/stack/test' から出ます
  make: *** [all-recursive] エラー 1

cutter.hが読み込めないというエラーがなくなった。

==== スタックAPIの作成

次はstack.hが読み込めないエラーを解消する。

スタックの実装はsrc/以下に作成するので、スタックのAPIである
stack.hはsrc/stack.hに置く。

  [stack]% touch src/stack.h

インクルードパスを設定し、テストプログラムからstack.hを読み
込めるようにする。

test/Makefile.am:
  ...
  INCLUDES = $(CUTTER_CFLAGS) -I$(top_srcdir)/src
  ...

makeを実行するとstack.hが読み込めないエラーが解消されている
のが分かる。

  [stack]% make
  ...
  test-stack.c: In function ‘test_new_stack’:
  test-stack.c:9: error: ‘Stack’ undeclared (first use in this function)
  test-stack.c:9: error: (Each undeclared identifier is reported only once
  test-stack.c:9: error: for each function it appears in.)
  test-stack.c:9: error: ‘stack’ undeclared (first use in this function)
  make[1]: *** [test-stack.lo] エラー 1
  make[1]: ディレクトリ `/tmp/stack/test' から出ます
  make: *** [all-recursive] エラー 1

残りのエラーがStack型が宣言されていないことだけになった。

==== Stack型の宣言

src/stack.hにStack型を宣言し、テストプログラムをビルドできる
ようにする。

src/stack.h:
  #ifndef __STACK_H__
  #define __STACK_H__

  typedef struct _Stack Stack;

  #endif

stack_new()が宣言されていないため警告がでるが共有ライブラリ
を作成することはできる。

  [stack]% make
  ...
  test-stack.c: In function ‘test_new_stack’:
  test-stack.c:10: warning: assignment makes pointer from integer without a cast
  ...
  [stack]% file test/.libs/test_stack.so
  test/.libs/test_stack.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

注: Cygwin上では未解決のシンボルがあるときは作成できない。
Cygwin環境の場合は気にせずに次に進むこと。

==== stack_new()/stack_is_empty()の宣言

stack_new()、stack_is_empty()を宣言し、警告を解消する。

src/stack.h:
  ...
  Stack *stack_new      (void);
  int    stack_is_empty (Stack *stack);
  ...

makeをして警告がでないことを確認する。

  [stack]% make

=== テスト起動

共有ライブラリが作成できたので、cutterコマンドでこのテストを
起動できる。

  [stack]% cutter test/
  cutter: symbol lookup error: test/.libs/test_stack.so: undefined symbol: stack_new

stack_new()が定義されていないため読み込みに失敗するが、テス
トプログラムが読み込まれることは確認できる。

注: Cygwin上では未解決のシンボルがあるときはDLL作成できないの
で、エラーにならず、「0個のテストを実行して失敗しなかった」結
果が報告される。以降の作業の中でスタックを実装し、未解決のシ
ンボルが解決されればDLLが作成され、テストが実行できるようにな
る。それまではテストの実行結果が異なる。Cygwin環境の場合は気
にせずに次に進むこと。

==== テスト起動の自動化

GNUビルドシステムでは一般的にmake checkでテストが起動する。
スタックの実装でも同様にテストが起動するようにする。

まず、テストを起動するスクリプトtest/run-test.shを作成する。
cutterコマンドのパスは環境変数CUTTERで受け取ることにする。

test/run-test.sh:
  #!/bin/sh

  export BASE_DIR="`dirname $0`"
  $CUTTER -s $BASE_DIR "$@" $BASE_DIR

実行権を付けることを忘れないこと。

  [stack]% chmod +x test/run-test.sh

test/Makefile.amにテスト起動スクリプトとしてtest/run-test.sh
を使うことを指定する。

test/Makefile.am:
  TESTS = run-test.sh
  TESTS_ENVIRONMENT = CUTTER="$(CUTTER)"
  ...

TESTS_ENVIRONMENTではcutterコマンドのパスを環境変数CUTTERで
渡している。cutterコマンドのパスはconfigure.ac内に追加した
AC_CHECK_CUTTERが検出している。

make -s checkでテストが走ることを確認する。-sオプションは
makeの出力を抑えるオプション（silent）であり、これを指定する
ことによりテスト結果が見やすくなる。

  [stack]% make -s check
  Making check in test
  cutter: symbol lookup error: ./.libs/test_stack.so: undefined symbol: stack_new
  FAIL: run-test.sh
  ================================
  1 of 1 tests failed
  Please report to you@example.com
  ================================
  ...


注: 前述のとおり、Cygwin上ではDLLが作成できないため、エラーは
発生しない。Cygwin環境の場合は実行結果が異なっても気にせずに
次に進むこと。

==== test/run-test.shの単独実行のサポート

make -s checkではビルドログなどテスト結果以外の出力がでて、テス
ト結果が埋もれてしまう。そこで、make -s check経由ではなく
test/run-test.shを実行できるようにする。

まず、test/run-test.shを環境変数CUTTERが指定されていない場合
は、cutterコマンドのパスを自動的に検出する。さらにmake check
経由でtest/run-test.shが起動された場合はmakeを実行し、必要な
ファイルをビルドする。

test/run-test.sh:
  #!/bin/sh

  export BASE_DIR="`dirname $0`"
  top_dir="$BASE_DIR/.."

  if test -z "$NO_MAKE"; then
      make -C $top_dir > /dev/null || exit 1
  fi

  if test -z "$CUTTER"; then
      CUTTER="`make -s -C $BASE_DIR echo-cutter`"
  fi

  $CUTTER -s $BASE_DIR "$@" $BASE_DIR

このtest/run-test.shに対応するためにtest/Makefile.amを以下の
ように変更する。

test/Makefile.am:
  ...
  TESTS_ENVIRONMENT = NO_MAKE=yes CUTTER="$(CUTTER)"
  ...
  echo-cutter:
  	echo $(CUTTER)

test/Makefile.am全体は以下のようになる。

test/Makefile.am:
  TESTS = run-test.sh
  TESTS_ENVIRONMENT = NO_MAKE=yes CUTTER="$(CUTTER)"

  noinst_LTLIBRARIES = test_stack.la

  INCLUDES = $(CUTTER_CFLAGS) -I$(top_srcdir)/src
  LIBS = $(CUTTER_LIBS)

  LDFLAGS = -module -rpath $(libdir) -avoid-version -no-undefined

  test_stack_la_SOURCES = test-stack.c

  echo-cutter:
          @echo $(CUTTER)

test/run-test.shを直接実行してテストが起動することを確認する。

  [stack]% test/run-test.sh
  cutter: symbol lookup error: test/.libs/test_stack.so: undefined symbol: stack_new

注: Cygwin環境ではエラーは発生しない。

ここからはmake -s checkではなくtest/run-test.shを使用する。こ
れは必要な情報のみが出力され、本当に興味のあるテストの結果が
埋もれてしまうのを防ぐためである。

また、スタックの実装を行う前にテストの実行環境を整備している
のは、テストを実行するコストを下げるためである。これは、テス
トを実行することが面倒になるとテストを実行しなくなり、その結
果、プログラムの品質低下につながるためである。

最初にテスト環境の整備を行うと、その分、プログラム本体の開発
着手が遅れてしまう。しかし、プログラム本体が開発・保守され続
ける間は常にテストを実行し、品質を保持する必要があるため、最
初にテスト環境整備に当てたコストは回収可能である。今後、快適
に品質の高いプログラムの開発を行うために、最初にテスト環境の
整備を行うことは重要である。

=== スタックの実装

テスト環境の整備ができたため、スタックの実装に入る。

==== 簡単なstack_new()の実装

まず、stack_new()を定義し、実行時エラーの原因を解決する。

スタックの実装はsrc/stack.cで行う。簡単なstack_new()の実装は
以下の通りである。

src/stack.c:
  #include <stdlib.h>
  #include "stack.h"

  Stack *
  stack_new (void)
  {
      return NULL;
  }

==== src/libstack.laのビルド

それでは、makeでsrc/stack.cをビルドできるようにする。

まず、test/以下をビルド対象に加えたように、src/以下もビルド
対象とする。

Makefile.am:
  ACLOCAL_AMFLAGS = $$ACLOCAL_ARGS

  SUBDIRS = src test

configure.ac:
  ...
  AC_CONFIG_FILES([Makefile
                   src/Makefile
                   test/Makefile])
  ...

これでsrc/以下もビルド対象となる。

  [stack]% test/run-test.sh
  configure.ac:13: required file `src/Makefile.in' not found
  make: *** [Makefile.in] エラー 1

src/Makefile.amを作成するとこのエラーはなくなる。

  [stack]% touch src/Makefile.am
  [stack]% test/run-test.sh
  cutter: symbol lookup error: test/.libs/test_stack.so: undefined symbol: stack_new

注: Cygwin環境ではエラーは発生しない。

makeは通るようになるが、この時点ではsrc/stack.cはビルドされ
ないし、テストプログラムもlibstack.soをリンクしていないので
stack_new()が定義されていないエラーは変わらない。

src/Makefile.amに以下を追加し、src/stack.cからlibstack.soを
作成する。

src/Makefile.am:
  lib_LTLIBRARIES = libstack.la

  LDFLAGS = -no-undefined

  libstack_la_SOURCES = stack.c

makeでlibstack.soが生成できるようになるはずである。

  [stack]% make
  ...
  make[1]: ディレクトリ `/tmp/stack/src' に入ります
  Makefile:275: .deps/stack.Plo: そのようなファイルやディレクトリはありません
  make[1]: *** ターゲット `.deps/stack.Plo' を make するルールがありません.  中止.
  ...

上記のエラーを修正するためにconfigureをもう一度実行する必要が
ある。

  [stack]% ./configure

makeでsrc/.libs/libstack.so.0.0.0を生成することができる。

  [stack]% make
  [stack]% file src/.libs/libstack.so.0.0.0
  src/.libs/libstack.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

注: Cygwin上ではsrc/.libs/cyglibstack.dllが作成される。

==== src/libstack.laのリンク

libstack.soはできたがテストプログラムにはリンクしていないの
で、まだ実行時エラーは発生する。

  [stack]% test/run-test.sh
  cutter: symbol lookup error: test/.libs/test_stack.so: undefined symbol: stack_new

注: Cygwin環境ではエラーは発生しない。

libstack.soをリンクするためにtest/Makefile.amを以下のように
変更する。

test/Makefile.am:
  ...
  LIBS = $(CUTTER_LIBS) $(top_builddir)/src/libstack.la
  ...

Cygwin環境の場合はsrc/.libs/以下に生成されるスタックを実装し
たDLLを利用するために、src/.libs/にパスを通す必要がある。その
ため、以下のようにtest/run-test.shでcutterを実行する前にPATH
を設定する。

test/run-test.sh:
  ...
  case `uname` in
      CYGWIN*)
          PATH="$top_dir/src/.libs:$PATH"
          ;;
      Darwin)
          DYLD_LIBRARY_PATH="$top_dir/src/.libs:$DYLD_LIBRARY_PATH"
          export DYLD_LIBRARY_PATH
          ;;
      *BSD)
          LD_LIBRARY_PATH="$top_dir/src.libs:$LD_LIBRARY_PATH"
          export LD_LIBRARY_PATH
          ;;
      *)
          :
          ;;
  esac

  $CUTTER -s $BASE_DIR "$@" $BASE_DIR

テストプログラムを再リンクする必要があるため、一度make clean
してからビルドしなおす。

  [stack]% make clean
  [stack]% make
  [stack]% test/run-test.sh
  cutter: symbol lookup error: test/.libs/test_stack.so: undefined symbol: stack_is_empty

今まではstack_new()が見つからずにエラーが発生していたが、
stack_is_empty()が見つからないというエラーに変わった。これに
より、libstack.soがリンクされていることが確認できた。

注: Cygwin環境ではエラーは発生しない。

==== stack_is_empty()の実装

テストプログラム中ではstack_is_empty()の結果を以下のようにテ
ストしている。

test/test-stack.c:
  ...
  cut_assert(stack_is_empty(stack));
  ...

つまり、stack_is_empty()が真を返すことをテストしている。よっ
て、src/stack.cでのstack_is_empty()は真を返す必要がある。

src/stack.c:
  ...
  #define TRUE 1
  #define FALSE 0
  ...
  int
  stack_is_empty (Stack *stack)
  {
      return TRUE;
  }

src/stack.c全体は以下のようになる。

src/stack.c:
  #include <stdlib.h>
  #include "stack.h"

  #define TRUE 1
  #define FALSE 0

  Stack *
  stack_new (void)
  {
      return NULL;
  }

  int
  stack_is_empty (Stack *stack)
  {
      return TRUE;
  }


このstack_is_empty()の実装は常に真を返すため、テストは成功す
るはずである。

  [stack]% test/run-test.sh
  .

  Finished in 0.000028 seconds

  1 test(s), 1 assertion(s), 0 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  100% passed

「.」がひとつ表示されているのは1つのテストがパスしたことを表
している。現在は1つしかテストがないので1つのテストにパスした
ということはすべてのテストにパスしたということである。

環境によっては表示が緑になっているはずである。これはテストが
パスしているので次に進んでもよいという意味である。

テストが動作することが確認できたので、以降ではテストを作成し
ながらスタックの実装を完成させる。

== pushの実装

まずはpushを実装する。今回の実装では、スタックにはintのみを
格納できることする。

=== pushのテスト

pushをした後はスタックのサイズが1になり、スタックは空ではなく
なるはずである。これをテストにすると以下のようになる。

test/test-stack.c:
  ...
  void test_push (void);
  ...
  void
  test_push (void)
  {
      Stack *stack;

      stack = stack_new();
      cut_assert_equal_int(0, stack_get_size(stack));
      stack_push(stack, 100);
      cut_assert_equal_int(1, stack_get_size(stack));
      cut_assert(!stack_is_empty(stack));
  }

テストを実行すると、stack_get_size()が定義されていないため実
行時エラーになる。

  [stack]% test/run-test.sh
  cutter: symbol lookup error: ./test/.libs/test_stack.so: undefined symbol: stack_get_size

注: Cygwin環境ではエラーは発生しない？

このテストをパスするようにpushを実装する。

=== cut_stack_push()の実装

まずは、パスしなくても良いのでテストが動くように
stack_get_size()とstack_push()を実装する。

まず、src/stack.hに宣言を追加する。

src/stack.h:
  ...
  int    stack_get_size (Stack *stack);
  void   stack_push     (Stack *stack, int value);
  ...

続いてsrc/stack.cに定義を追加する。

src/stack.c:
  ...
  int
  stack_get_size (Stack *stack)
  {
      return 0;
  }

  void
  stack_push (Stack *stack, int value)
  {
  }

stack_get_size()が0を返しているのは、最初のstack_get_size()
は以下のように0を期待されているからである。

test/test-stack.c:
  ...
  stack = stack_new();
  cut_assert_equal_int(0, stack_get_size(stack));
  ...

pushの実装ができたのでテストを実行する。

  [stack]% test/run-test.sh
  .F

  1) Failure: test_push
  <1 == stack_get_size(stack)>
  expected: <1>
   but was: <0>
  test/test-stack.c:23: test_push()

  Finished in 0.000113 seconds

  2 test(s), 2 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  50% passed

「F」はテストが失敗（Failure）したことを表している。環境によっ
ては表示が赤くなっているはずである。これは、テストがパスして
いないので先に進むことは危険であることを示している。popの実
装に移る前にテストをパスさせるようにpushを実装を改良するべき
だということである。

cutterからのメッセージでは、test/test-stack.cの23行目、
test_push()関数の中でstack_get_size(stack)の値が1ではなく0の
ために失敗したということを表している。該当する行は以下の通り
である。

test/test-stack.c:23:
  cut_assert_equal_int(1, stack_get_size(stack));

これはstack_get_size()が常に0を返しているためである。
stack_push()された後には内部のカウンタを1つ進める必要がある。

=== メモリ開放

今まではstack_new()でNULLを返していたが、test_pushテストをパ
スするためには内部にカウンタを持つ必要があるため、メモリを割
り当てる必要がある。メモリを割り当てた場合、使用済のメモリを
開放する必要がある。

例えば、test_new_stack()では以下のようにする必要がある。

  void
  test_new_stack (void)
  {
      Stack *stack;
      stack = stack_new();
      cut_assert(stack_is_empty(stack));
      stack_free(stack);
  }

しかし、stack_free()の前のcut_assert()が失敗した場合はその時
点で処理が終了してしまうため、stack_free()が呼ばれずメモリリー
クが発生する。（ただし、テストプログラムはすぐに終了する短命
なプログラムため、害が大きくなることは少ない。）

Cutterではテストの前後に必ず実行される関数を設定することがで
きる。それがcut_setup()/cut_teardown()である。これらはテスト
が成功した場合も失敗した場合も呼ばれるためテスト中で割り当て
たメモリを確実に開放する処理などに使うことができる。

test_new_stack()をcut_setup()/cut_teardown()を使って確実にメ
モリを開放するようにすると以下のようになる。

test/test-stack.c:
  ...
  static Stack *stack;

  void
  cut_setup (void)
  {
      stack = NULL;
  }

  void
  cut_teardown (void)
  {
      if (stack)
          stack_free(stack);
  }

  void
  test_new_stack (void)
  {
      stack = stack_new();
      cut_assert(stack_is_empty(stack));
  }
  ...

同様に、test_push()でも、関数内のローカル変数stackを使わずに
ファイル中でstaticなstackを使用すれば確実にメモリを開放でき
る。

test/test-stack.c:
  ...
  void
  test_push (void)
  {
      stack = stack_new();
      cut_assert_equal_int(0, stack_get_size(stack));
      stack_push(stack, 100);
      cut_assert_equal_int(1, stack_get_size(stack));
      cut_assert(!stack_is_empty(stack));
  }
  ...

cut_setup()/cut_teardown()を使用したtest/test-stack.c全体は以
下のようになる。

test/test-stack.c:
  #include <cutter.h>
  #include <stack.h>

  void test_new_stack (void);
  void test_push (void);

  static Stack *stack;

  void
  cut_setup (void)
  {
      stack = NULL;
  }

  void
  cut_teardown (void)
  {
      if (stack)
          stack_free(stack);
  }

  void
  test_new_stack (void)
  {
      stack = stack_new();
      cut_assert(stack_is_empty(stack));
  }

  void
  test_push (void)
  {
      stack = stack_new();
      cut_assert_equal_int(0, stack_get_size(stack));
      stack_push(stack, 100);
      cut_assert_equal_int(1, stack_get_size(stack));
      cut_assert(!stack_is_empty(stack));
  }

この変更の後でもテストが変更前と同じ結果を返すことを確認する。

  [stack]% test/run-test.sh
  .F

  1) Failure: test_push
  <1 == stack_get_size(stack)>
  expected: <1>
   but was: <0>
  test/test-stack.c:35: test_push()

  Finished in 0.000084 seconds

  2 test(s), 2 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  50% passed

=== stack_new()/stack_free()の実装

それでは、stack_new()でメモリを割り当て、stack_free()で開放
する処理を実装する。

まず、src/stack.hにstack_free()を宣言する。

src/stack.h:
  ...
  void   stack_free     (Stack *stack);
  ...

続いて、src/stack.cにStackを定義する。Stackはスタックのサイズ
を保存するフィールドを含む。

src/stack.c:
  ...
  struct _Stack {
      int size;
  };
  ...

stack_new()でStackのためのメモリを割り当て、stack_free()で開
放する。

src/stack.c:
  ...
  Stack *
  stack_new (void)
  {
      Stack *stack;

      stack = malloc(sizeof(Stack));
      if (!stack)
          return NULL;

      stack->size = 0;
      return stack;
  }

  void
  stack_free (Stack *stack)
  {
      free(stack);
  }
  ...

この変更の後でもテストが変更前と同じ結果を返すことを確認する。

  [stack]% test/run-test.sh
  .F

  1) Failure: test_push
  <1 == stack_get_size(stack)>
  expected: <1>
   but was: <0>
  test/test-stack.c:35: test_push()

  Finished in 0.000113 seconds

  2 test(s), 2 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  50% passed

=== stack_push()の本実装

Stackにスタックサイズを持つことができるようになったので、こ
れを使用してテストをパスするように
stack_push()/stack_get_size()を実装する。

src/stack.c:
  ...
  int
  stack_get_size (Stack *stack)
  {
      return stack->size;
  }

  void
  stack_push (Stack *stack, int value)
  {
      stack->size++;
  }

pushする毎にスタックサイズを増やし、そのサイズを返すようにし
た。これで今まで失敗していたstack_get_size()のテストがパスす
るはずである。

  [stack]% test/run-test.sh
  .F

  1) Failure: test_push
  expected: <!stack_is_empty(stack)> is not FALSE/NULL
  test/test-stack.c:36: test_push()

  Finished in 0.000113 seconds

  2 test(s), 3 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  50% passed

期待通りstack_get_size()のテストはパスしたがその後の
test/test-stack.cの36行目、stack_is_empty()で失敗している。

test/test-stack.c:36:
  cut_assert(!stack_is_empty(stack));

スタックにpushしたら空ではなくなるはずである。

=== stack_is_empty()の本実装

スタックが空なのはスタックサイズが0のときである。よって、
stack_is_empty()の実装は以下のようになる。

src/stack.c:
  ...
  int
  stack_is_empty (Stack *stack)
  {
      return stack->size == 0;
  }
  ...

テストを実行し、すべてのテストにパスすることを確認する。

  % test/run-test.sh
  ..

  Finished in 0.000036 seconds

  2 test(s), 4 assertion(s), 0 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  100% passed

pushのテストもパスし、既存のスタックを作った直後の場合のテス
トもパスしたままである。すべてのテストがパスしたため、結果表
示も緑に戻った。これで安心してpopの実装に進むことができる。

== popの実装

pushが実装できたので、次はpushで入れたデータを取り出すpopを
実装する。

=== popのテスト

popをすると最後にpushした値が順番に返ってくる。また、popする
毎にスタックサイズが減り、最後は空になる。これをテストにする
と以下のようになる。

test/test-stack.c:
  ...
  void test_pop (void);
  ...
  void
  test_pop (void)
  {
      stack = stack_new();

      stack_push(stack, 10);
      stack_push(stack, 20);
      stack_push(stack, 30);

      cut_assert_equal_int(3, stack_get_size(stack));
      cut_assert_equal_int(30, stack_pop(stack));
      cut_assert_equal_int(2, stack_get_size(stack));
      cut_assert_equal_int(20, stack_pop(stack));
      cut_assert_equal_int(1, stack_get_size(stack));

      stack_push(stack, 40);
      cut_assert_equal_int(2, stack_get_size(stack));
      cut_assert_equal_int(40, stack_pop(stack));
      cut_assert_equal_int(1, stack_get_size(stack));
      cut_assert_equal_int(10, stack_pop(stack));
      cut_assert_equal_int(0, stack_get_size(stack));
      cut_assert(stack_is_empty(stack));
  }

テストを走らせる。

  [stack]% test/run-test.sh
  ..cutter: symbol lookup error: test/.libs/test_stack.so: undefined symbol: stack_pop

stack_pop()を定義していないためエラーが発生している。エラー
メッセージの前に「.」が二つ出ているので既存のテストはパスし
ていることが確認できる。

注: Cygwin環境ではエラーは発生しない？

=== stack_pop()の実装

まず、src/stack.hにstack_pop()の宣言を追加する。

src/stack.h:
  ...
  int    stack_pop      (Stack *stack);
  ...

つづいて、src/stack.cにstack_pop()の実装を追加する。

src/stack.c:
  ...
  int
  stack_pop (Stack *stack)
  {
      return 30;
  }

ここで30を返すようにしているのは最初のstack_pop()では30を返
すことが期待されているからである。

test/test-stack.c:50:
  cut_assert_equal_int(30, stack_pop(stack));

テストを実行し、popのテストもエラーが発生せずに実行されるこ
とを確認する。

  [stack]% test/run-test.sh
  ..F

  1) Failure: test_pop
  <2 == stack_get_size(stack)>
  expected: <2>
   but was: <3>
  test/test-stack.c:51: test_pop()

  Finished in 0.000307 seconds

  3 test(s), 6 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  66.6667% passed

popのテストが実行された。しかし、現在のstack_pop()ではスタッ
クサイズを変更していないため、popした後のスタックサイズを確
認しているtest/test-stack.cの50行目のstack_get_size()で失敗
している。

test/test-stack.c:51:
  cut_assert_equal_int(2, stack_get_size(stack));

=== データ領域の確保

テストが実行されることが確認できたのでテストにパスするように
stack_pop()を実装する。

後でpopで取り出すために、pushされたデータを保存しておく必要
がある。Stackに保存されたデータを示す場所を用意し、
stack_push()/stack_pop()で動的に必要な領域を割り当てる。

まず、Stackに保存されたデータを示す場所を用意し、stack_new()
で初期化、stack_free()で開放する。

src/stack.c:
  ...
  struct _Stack {
      int size;
      int *data;
  };

  Stack *
  stack_new (void)
  {
      ...
      stack->data = NULL;
      ...
  }

  void
  stack_free (Stack *stack)
  {
      free(stack->data);
      free(stack);
  }
  ...

この時点では外部向けの処理の内容は変わっていないはずなので、
テストを実行して変更前と同じように失敗することを確認する。

  [stack]% test/run-test.sh
  ..F

  1) Failure: test_pop
  <2 == stack_get_size(stack)>
  expected: <2>
   but was: <3>
  test/test-stack.c:51: test_pop()

  Finished in 0.000097 seconds

  3 test(s), 6 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  66.6667% passed

=== stack_pop()の本実装

保存したデータを示す場所が用意できたので
stack_push()/stack_pop()でそこに必要な分だけ領域を割り当て、
データを保存する。

src/stack.c:
  ...
  void
  stack_push (Stack *stack, int value)
  {
      int *new_data;

      stack->size++;
      new_data = realloc(stack->data, sizeof(*stack->data) * stack->size);
      if (!new_data) {
          free(stack->data);
          stack->data = NULL;
          stack->size = 0;
          return;
      }
      stack->data = new_data;

      stack->data[stack->size - 1] = value;
  }

  int
  stack_pop (Stack *stack)
  {
      int value;
      int *new_data;

      stack->size--;
      value = stack->data[stack->size];

      new_data = realloc(stack->data, sizeof(*stack->data) * stack->size);
      if (stack->size > 0 && !new_data) {
          free(stack->data);
          stack->data = NULL;
          stack->size = 0;
          return value;
      }
      stack->data = new_data;

      return value;
  }

テストを実行し、popのテストがパスすることを確認する。

  [stack]% test/run-test.sh
  ...

  Finished in 0.000076 seconds

  3 test(s), 15 assertion(s), 0 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  100% passed

== 重複の排除

stack_push()/stack_pop()の実装では動的なメモリ割り当て部分、
メモリ割り当て失敗時のエラー処理部分に重複があった。一般的に
コード中に重複があることは、メンテナンス性の面などの理由で悪
いこととされている。

ここでは、既存の動作を変更せずに重複している悪い部分を修正す
る。既存の動作が変わっていないことはテストを実行することで確
認することができる。

=== メモリ割り当て部分の重複の除去

まず、以下のメモリ割り当て部分の重複を除去する。

src/stack.c:
  new_data = realloc(stack->data, sizeof(*stack->data) * stack->size);

この部分はstack_realloc()として切り出す。

src/stack.c:
  ...
  static int *
  stack_realloc (Stack *stack)
  {
      return realloc(stack->data, sizeof(*stack->data) * stack->size);
  }

  void
  stack_push (Stack *stack, int value)
  {
      ...
      new_data = stack_realloc(stack);
      ...
  }

  int
  stack_pop (Stack *stack)
  {
      ...
      new_data = stack_realloc(stack);
      ...
  }

この変更の後でも以前と同じ挙動をしているかを確かめる。

  [stack]% test/run-test.sh
  ...

  Finished in 0.000078 seconds

  3 test(s), 15 assertion(s), 0 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  100% passed

結果が緑なので次へ進める。

=== エラー処理部分の重複の除去

次に、以下のメモリ割り当て失敗時のエラー処理部分の重複を除去
する。

src/stack.c:
  ...
  void
  stack_push (Stack *stack, int value)
  {
      ...
      new_data = stack_realloc(stack);
      if (!new_data) {
          free(stack->data);
          stack->data = NULL;
          stack->size = 0;
          return;
      }
      ...
  }

  int
  stack_pop (Stack *stack)
  {
      ...
      new_data = stack_realloc(stack);
      if (stack->size > 0 && !new_data) {
          free(stack->data);
          stack->data = NULL;
          stack->size = 0;
          return value;
      }
      ...
  }

これらのエラー処理をstack_realloc()の中に移動し、
stack_realloc()は割り当てたメモリを返すのではなく、新しくメ
モリを割り当てることに成功したかどうかを返すことにする。

src/stack.c:
  ...
  static int
  stack_realloc (Stack *stack)
  {
      int *new_data;

      new_data = realloc(stack->data, sizeof(*stack->data) * stack->size);
      if (stack->size > 0 && !new_data) {
          free(stack->data);
          stack->data = NULL;
          stack->size = 0;
          return FALSE;
      }
      stack->data = new_data;

      return TRUE;
  }

  void
  stack_push (Stack *stack, int value)
  {
      stack->size++;
      if (!stack_realloc(stack))
          return;
      stack->data[stack->size - 1] = value;
  }

  int
  stack_pop (Stack *stack)
  {
      int value;

      stack->size--;
      value = stack->data[stack->size];
      stack_realloc(stack);
      return value;
  }

この変更の後でも以前と同じ挙動をしているかを確かめる。

  [stack]% test/run-test.sh
  ...

  Finished in 0.000076 seconds

  3 test(s), 15 assertion(s), 0 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s)
  100% passed

既存の動作を変更することなく、プログラム中の重複部分を取り除
き、プログラムを改良したことを確認できた。

== まとめ

本稿では小さなスタックの実装を例にしてGNUビルドシステムを用い
たビルド環境の構築方法・Cutterを用いたテストの作成方法・テス
トのあるプログラムでのプログラムの改良方法を示した。

=== メリット

GNUビルドシステムを用いることにより、ビルド環境の差異を吸収
することが比較的容易になる。これはプログラムの移植性を向上さ
せることにつながる。

Cutterを用いることにより、簡単にテストが書ける。既存のC言語用
テスティングフレームワークではテストを定義するために独自のマ
クロを用いたり、テストの定義とテストの登録を別々に行う必要が
あるなどテスト以外にも書かなければいけないことが多い。Cutter
はこの点を改善し、テスト定義のための独自のマクロを提供せず、
通常どおりに関数を定義するだけでテストを定義できるようにした。
明示的にテストを定義する必要もない。

本稿ではcut_assert()とcut_assert_equal_int()しか使用しなかっ
たが、cut_assert_equal_string()など期待値と実際の値を比較する
ための方法を多数用意している。これにより、テストプログラムの
ための比較方法を定義しなければいけない機会が減り、より簡潔に
テストプログラムを書けるようになる。

また、Cutterのテスト結果出力は必要のない情報はなるべく表示せ
ず、必要な情報はできるだけ多く提供する。これは必要な情報が埋
もれてしまうのを防ぎ、プログラムの修正を支援する。また、C言語
ではよくある異常終了時には、バックトレースの出力を試み、プロ
グラム修正のためのより多くの情報を提供する。

既存の機能を変更せずにプログラムの内部構造を改良することはメ
ンテナンス性を向上させるのに非常に役立つ。自動化されたテスト
を作成することにより、既存の機能が変更されていないことを容易
に確認できる。

また、新規に機能を追加する場合でも、自動化されたテストがあれ
ば、既存の機能を壊すことなく機能を追加していることを確認でき
る。自動化テストを用意することはメンテナンス面でも、新機能開
発面でも品質の高いプログラムを作成する上で有用である。

=== スタックのテスト

最終的なテストは以下の通りである。

test/test-stack.c
  #include <cutter.h>
  #include <stack.h>

  void test_new_stack (void);
  void test_push (void);
  void test_pop (void);

  static Stack *stack;

  void
  cut_setup (void)
  {
      stack = NULL;
  }

  void
  cut_teardown (void)
  {
      if (stack)
          stack_free(stack);
  }

  void
  test_new_stack (void)
  {
      stack = stack_new();
      cut_assert(stack_is_empty(stack));
  }

  void
  test_push (void)
  {
      stack = stack_new();
      cut_assert_equal_int(0, stack_get_size(stack));
      stack_push(stack, 100);
      cut_assert_equal_int(1, stack_get_size(stack));
      cut_assert(!stack_is_empty(stack));
  }

  void
  test_pop (void)
  {
      stack = stack_new();

      stack_push(stack, 10);
      stack_push(stack, 20);
      stack_push(stack, 30);

      cut_assert_equal_int(3, stack_get_size(stack));
      cut_assert_equal_int(30, stack_pop(stack));
      cut_assert_equal_int(2, stack_get_size(stack));
      cut_assert_equal_int(20, stack_pop(stack));
      cut_assert_equal_int(1, stack_get_size(stack));

      stack_push(stack, 40);
      cut_assert_equal_int(2, stack_get_size(stack));
      cut_assert_equal_int(40, stack_pop(stack));
      cut_assert_equal_int(1, stack_get_size(stack));
      cut_assert_equal_int(10, stack_pop(stack));
      cut_assert_equal_int(0, stack_get_size(stack));
      cut_assert(stack_is_empty(stack));
  }

=== スタックの実装

最終的なプログラムは以下の通りである。このスタックは素朴な実
装であるため、エラーの通知方法やパフォーマンスのチューニング
などの課題が残っているが、テストが示している通りの基本的な機
能は実装されている。

src/stack.c:
  #include <stdlib.h>
  #include "stack.h"

  #define TRUE 1
  #define FALSE 0

  struct _Stack {
      int size;
      int *data;
  };

  Stack *
  stack_new (void)
  {
      Stack *stack;

      stack = malloc(sizeof(Stack));
      if (!stack)
          return NULL;

      stack->size = 0;
      stack->data = NULL;
      return stack;
  }

  void
  stack_free (Stack *stack)
  {
      free(stack->data);
      free(stack);
  }

  int
  stack_is_empty (Stack *stack)
  {
      return stack->size == 0;
  }

  int
  stack_get_size (Stack *stack)
  {
      return stack->size;
  }

  static int
  stack_realloc (Stack *stack)
  {
      int *new_data;

      new_data = realloc(stack->data, sizeof(*stack->data) * stack->size);
      if (stack->size > 0 && !new_data) {
          free(stack->data);
          stack->data = NULL;
          stack->size = 0;
          return FALSE;
      }
      stack->data = new_data;

      return TRUE;
  }

  void
  stack_push (Stack *stack, int value)
  {
      stack->size++;
      if (!stack_realloc(stack))
          return;
      stack->data[stack->size - 1] = value;
  }

  int
  stack_pop (Stack *stack)
  {
      int value;

      stack->size--;
      value = stack->data[stack->size];
      stack_realloc(stack);
      return value;
  }

=== Cutterがある場合だけテストをサポート

ここで作成したtest/test-stack.cはCutterがない場合はビルドに
失敗する。つまり、makeが失敗する。開発者であればテストを実行
するのが当然なので、Cutterがない場合は失敗しても問題はない。
むしろ、問題に気づきやすいのでそうである方がよいと言える。

しかし、ライブラリとしてスタックを使いたいユーザにはCutterが
ない場合でもビルドが正常に終了できた方がよい。そのようなユー
ザは開発者がテストしたリリース版のライブラリを使用していると
考えられるからである。

以下はCutterがない場合でもビルドできるようにする方法である。

まず、configure.acのAC_CHECK_CUTERの部分を以下のように変更し、
Cutterが提供するm4（cutter.m4）がない場合でもautogen.sh（よ
り詳しくいうとaclocal）が動くようにする。（autogen.shを実行
するのが開発者のみであれば、この設定は必要ない。その場合は
AC_CHECK_CUTTERの定義がないためにaclocalが失敗する。）

configure.ac:
  ...
  m4_ifdef([AC_CHECK_CUTTER], [AC_CHECK_CUTTER], [ac_cv_use_cutter="no"])
  ...

ここでac_cv_use_cutterという変数名を使っているのは、
AC_CHECK_CUTTERが同じ名前の変数を使っているからである。この
変数はCutterの検出が失敗した場合にも"no"になるので、
cutter.m4がない場合（autogen.shを実行した環境にCutterがない
場合）は常にCutterを検出できなかった状態となる。

次に、Cutterの検出に失敗したという情報をMakefile.am中で利用す
るために、AC_CHECK_CUTTERの後ろでMakefile.am中で使える条件を
設定する。

configure.ac:
  ...
  m4_ifdef([AC_CHECK_CUTTER], [AC_CHECK_CUTTER], [ac_cv_use_cutter="no"])
  AM_CONDITIONAL([WITH_CUTTER], [test "$ac_cv_use_cutter" != "no"])
  ...

後は、WITH_CUTTERが真の場合だけtest/test-stack.cをビルドし、
test/run-test.shを実行すればよい。

test/Makefile.am:
  if WITH_CUTTER
  TESTS = run-test.sh
  TESTS_ENVIRONMENT = NO_MAKE=yes CUTTER="$(CUTTER)"

  noinst_LTLIBRARIES = test_stack.la
  endif
  ...

以上の変更を加えたconfigure.acとtest/Makefile.amの全体は以下
のとおりである。

configure.ac:
  AC_PREREQ(2.59)

  AC_INIT(stack, 0.0.1, you@example.com)
  AC_CONFIG_AUX_DIR([config])
  AC_CONFIG_HEADER([src/config.h])

  AM_INIT_AUTOMAKE($PACKAGE_NAME, $PACKAGE_VERSION)

  AC_PROG_LIBTOOL

  m4_ifdef([AC_CHECK_CUTTER], [AC_CHECK_CUTTER], [ac_cv_use_cutter="no"])
  AM_CONDITIONAL([WITH_CUTTER], [test "$ac_cv_use_cutter" != "no"])

  m4_ifdef([AC_CHECK_COVERAGE], [AC_CHECK_COVERAGE])

  AC_CONFIG_FILES([Makefile
                   src/Makefile
                   test/Makefile])

  AC_OUTPUT

test/Makefile.am:
  if WITH_CUTTER
  TESTS = run-test.sh
  TESTS_ENVIRONMENT = NO_MAKE=yes CUTTER="$(CUTTER)"

  noinst_LTLIBRARIES = test_stack.la
  endif

  INCLUDES = -I$(top_srcdir)/src
  LIBS = $(CUTTER_LIBS) $(top_builddir)/src/libstack.la

  AM_CFLAGS = $(CUTTER_CFLAGS)

  LDFLAGS = -module -rpath $(libdir) -avoid-version -no-undefined

  test_stack_la_SOURCES = test-stack.c

  echo-cutter:
  	@echo $(CUTTER)

=== 関連項目

  * xUnit: Cutterも属するassertXXXといった方法で結果を確認し
    ながらテストを書いていくテストの書き方をサポートするライ
    ブラリのこと。テスティングフレームワークとも呼ぶ。様々な
    言語で実装されている。
    * SUnit (Smalltalk)
    * JUnit (Java)
    * Test::Unit (Ruby)
    * PyUnit (Pytnon)
    * ...

  * エクストリーム・プログラミング（Extreme Programming, XP）:
    品質の高いプログラムを開発するための方法を集めたプログラ
    ミング方法。テストの作成も重要視している。