Eclipse CDTでデフォルトで付いているグラフィカルなGDB用のインタフェースと、GoogleTestなどのxUnitをあわせて利用するとデバッグが捗ったので、メモ。

基本は動的、バグったら静的

方法は以下の通り。

  1. GoogleTestを使ってテストを書いて実行。
  2. テスト失敗したら、失敗したテストケースでブレイクポイントをはる。
  3. GoogleTestを再実行して、ブレイクしたところからステップ実行して、テスト失敗の理由を調査。

基本的には、GoogleTestで自動テストを書いていく。
しかし、テストが失敗し、その原因がよくわからないときはGDBでメモリの値の変化をステップごとに追いながらデバッグをするというスタンスだ。

EclipseのGDB機能はスゴく高性能で、
構造体のネスト構造まで、スケスケ丸見えなのだ（下品 (･∀･)ﾆﾔﾆﾔにや）

キーバインドでパースペクティブを行ったり来たり

キーバインド的には、

GoogleTest実行時 =>「Ctrl+ F11」 GDB起動時 => 「F11」

というようにしている。すると、実行によってEclipseのパースペクティブが[C/C++]と[デバッグ]で切り替えることができる。

設定が必要な場合は、
[ウィンドウ] > [設定] > [実行/デバッグ] > [パースペクティブ]から[C/C++ Application]を選択し、適切に設定すること。

また、ブレークポイントを設定することで、自動的に実行時にはデバッグパースペクティブに切り替えることもできる。
[ウィンドウ] > [設定] > [実行/デバッグ] から設定。（多分、これはデフェルト設定）

セグメンテーション違反対策に効果バツグン！

個人的にとてもいいなと感じたのは、セグメンテーション違反するとその直前でGoogleTestの実行処理を止めることができること。

テストコードがないコードに修正をいれるのは怖いので、まずテストを書いてから修正を入れるようにしているが、このレガシーコードへのテストを書く際に、メモリ獲得を忘れて画面が真っ赤になることがすごくたくさんあるのだ！

この潰し込みが大変で、テストを書くことを諦めることが往々にしてある。
しかし、このgdbを使った方法をとれば、驚くほど効率が上がった。

まとめ

今まで、gdbを積極的には使って来なかった。
（使い方をあまり知らなかったという方が正しいかもしれない)
手動テストなんてありえない！という偏見があったのかもしれない。

物事に偏見をもってはいけないというお話でした。

チャンチャン( ﾟ∀ﾟ )