参考ページ
パッケージとかの準備
* Automake version 1.9 or newer
* Autoconf version 2.59 or newer
* Libtool / Libtoolize
* Python version 2.3 or newer (for running some of the tests and
re-generating certain source files from templates)
$ sudo apt-get install automake autoconf libtool python
$ automake --versionでバージョン情報を表示。1.9より古かったら
$ sudo apt-get install automake1.9
$ AUTOMAKE=automake-1.9
$ ACLOCAL=aclocal-1.9
準備が終わったら
$ autoreconf -fvi
表示された中にerrorがなければ
$ emacs ~/.bashrc
ファイルの最後に
export GMOCK_DIR=~/GcodeProjects/gmock
export GTEST_DIR=${GMOCK_DIR}/gtest
のように環境変数を追加
$source ~/.bashrcで変更を反映
$ g++ -I${GTEST_DIR}/include -I${GTEST_DIR} -I${GMOCK_DIR}/include \
-I${GMOCK_DIR} -c ${GTEST_DIR}/src/gtest-all.cc
$ g++ -I${GTEST_DIR}/include -I${GTEST_DIR} -I${GMOCK_DIR}/include \
-I${GMOCK_DIR} -c ${GMOCK_DIR}/src/gmock-all.cc
$ ar -rv libgmock.a gtest-all.o gmock-all.o
出来たlibgmock.aをテストを行うディレクトリに移動。
(ビルドが成功したかを試すために参考ページにあるソースコードを使用した。)
$ g++ -I${GTEST_DIR}/include -I${GMOCK_DIR}/include \
your_test.cc libgmock.a -o your_test -lpthread
テストの実行
$ ./your_test
2010年8月24日火曜日
2010年8月9日月曜日
Google C++ Testing Frameworkで述べられているプライベートメンバー関数のテストについて
参考ページ
原文:
If you change your software's internal implementation, your tests should not break as long as the change is not observable by users. Therefore, per the black-box testing principle, most of the time you should test your code through its public interfaces.
If you still find yourself needing to test internal implementation code, consider if there's a better design that wouldn't require you to do so.....
訳:
あなたがソフトウェアの内部の実装を変更したいとして、ユーザに分からないような変更に時間をかけるべきではない。あなたは、他のクラスとのインターフェースとなる関数のテストに時間をかけるべきだ。
もし、まだ内部の実装をテストしたいなら、その必要が無いようなデザインをもっと考えたほうがいい。
個人的な意見:
そうは言っても、Composedパターンなどで多数のプライベート関数が生まれることは避けられないのだから、プライベート関数をテストすることは、必要なのではないの?
原文:
If you change your software's internal implementation, your tests should not break as long as the change is not observable by users. Therefore, per the black-box testing principle, most of the time you should test your code through its public interfaces.
If you still find yourself needing to test internal implementation code, consider if there's a better design that wouldn't require you to do so.....
訳:
あなたがソフトウェアの内部の実装を変更したいとして、ユーザに分からないような変更に時間をかけるべきではない。あなたは、他のクラスとのインターフェースとなる関数のテストに時間をかけるべきだ。
もし、まだ内部の実装をテストしたいなら、その必要が無いようなデザインをもっと考えたほうがいい。
個人的な意見:
そうは言っても、Composedパターンなどで多数のプライベート関数が生まれることは避けられないのだから、プライベート関数をテストすることは、必要なのではないの?
2010年8月6日金曜日
C++のクラスを書いていて分かったこと。
gcc = C言語のコンパイルに主に使う。
g++ = C++のコンパイルに主に使う。
こんな感じのファイルをコンパイルしようとすると、gccではエラーが出た。
g++では何事もなくコンパイルに成功した。
gccでもクラスをコンパイルできるが、アクセッサ、ミューテータを実装しようとしたところでエラーが出るようになった。
g++ = C++のコンパイルに主に使う。
#includeusing namespace std; class ClassSpike { public: void set_int(int i); int get_int(); private: int I; }; void ClassSpike::set_int(int i){ I = i; } int ClassSpike::get_int(){ return I; } int main(){ ClassSpike cs; cs.set_int(1); int j = cs.get_int(); cout << j << "です。\n"; return 0; }
こんな感じのファイルをコンパイルしようとすると、gccではエラーが出た。
g++では何事もなくコンパイルに成功した。
gccでもクラスをコンパイルできるが、アクセッサ、ミューテータを実装しようとしたところでエラーが出るようになった。
登録:
投稿 (Atom)