Visual Studio 2012 C++ Unit Test Framework をコマンドライン実行 + Jenkins

Visual Studio 2012 C++ Unit Test Framework でテストコードが書けるようになっても、
テストエクスプローラーで実行していたのでは自動化できない！

というわけで、自動化するためにコマンドライン実行をする方法を調べました。
ついでに、Jenkins で結果を集計する方法も調べています。

コマンドライン実行する方法

"%ProgramFiles%\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe"
を使います。

テストプロジェクトをビルドすると dll が作成されるので、
その dll パスを vstest.console.exe の引数に渡すと実行されます。

vstest.console.exe iutest_unittest.dll

その他のコマンドラインオプションは vstest.console.exe /? とすることで見ることができます。
または、MSDN にも載っています。

Jenkins で集計する方法

/logger オプションで結果の出力フォーマットを指定できます。
/logger:trx で Visual Studio テスト結果ファイル(TRX) で出力でき、
trx ファイルは MSTest plugin を使えば結果の集計ができそうです。


まずは、ビルド手順を追加して以下のようにテストを実行します。

vstest.console.exe iutest_unittest.dll /logger:trx

テスト結果は
./TestResults/${USERNAME}_${COMPUTERNAME} ${日付} ${時間}.trx
に出力されます。

次に、「ビルド後の処理の追加」から「Publish MSTest test result reposrt」を選択し、trx ファイルを集計するように設定します。


以上で設定は終わりです。


このようにテスト結果が集計されました。

iutest v1.3.0 をリリースしました

iutest v1.3.0 をリリースしました。

今回の変更点は主に

• ライブラリビルド対応
• Google Test モード使用時のエラーおよび非互換だった部分の修正

です。

Visual Studio 2012: C++ Unit Test Framework でブレークポイント

VS2012 の C++ Unit Test Framework ですが、仕事や個人で実運用はしていないのですが、検証とか実験とかお遊びとかで使ってたりします。

Visual Studio 2012 の C++ Unit Test Framework については、このへんを見てください。

Visual Studio 11 : C++ Unit Test Framework ── C++単体テストの決定版（かもしれない）
MSDN Blogs - Writing Unit Tests in Visual Studio for Native C++

で、今までずーーーーっとブレークポイントは使えないものだと思って、プリントデバッグしてましたorz



ちゃんと使えます

テスト エクスプローラーの[すべて実行]ではブレークポイントで停止しないのですが、
各テストを右クリックして出るメニューの[選択したテストのデバッグ(D)]から実行すると、ブレークポイントで停止します！

MSDN にも書いてありました。

[Cppcheck] Windows 環境で -j オプションが使えるようになった

Cppcheck 1.58 がリリースされました。
待ちに待った -j オプションが Windows 環境でも使えるようになったようなので、
早速試してみました。

-j なし

-j あり(-j4)

（黄色いのは気にしないでください）

約１/２ 程度の処理時間で終わりました。
（※-j オプションを使うと unusedFunction の検出は使えなくなります。）

会社のプロジェクトでも試してみたところ、処理時間が半分ほどになりました。
これは嬉しいですね！

「2013年はじめのTDD Boot Camp in 大阪」に参加してきました

「2013年はじめのTDD Boot Camp in 大阪」に参加してきました。

このブログでも Google Test や Boost.Test などテスティングフレームワークのことを書いてきましたが、
TDD（テスト駆動開発）はほとんどしたことがありませんでした。
今回の勉強会で TDD を体験し、今後のプログラミングライフに活かしていきたいと思っております。

それでは出発！
（※ここまでは参加前に書いてます。）

---

楽しかったペアプログラミング～

初めてのペアプログラミングで不安があったけど、やってみたらとても楽しくできました。
あっという間に３時間が過ぎてしまいました。（このレベルの体感時間は久しぶりだった）
演習前のデモでどういう風に進めていくのか、わかったのも良かったです。

悩みに悩んだテスト名～

C++ グループではテスト名前をどうつけるかで、一手間かかりました。
他の言語では、日本語が使えたのでテストする内容(Todo)をそのままテスト名としていましたが、
Google Test (C++) では日本語が使えないため、拙い英語で名前をつけていました。

あとになって思い出したのですが、実は VC++ では日本語変数名が使えました。
というわけで、次 Google Test + Visual Studio でやる場合は、「日本語使えるよー」と教えてあげると良いかもです。

考えに考えたテストコード～

テストをどのように書けば良いのか（テスティングフレームワークの使い方も含め）、たくさん考えました。
どういうテストコードを書けば良いか、テストを分けるべきか、例外のテストはどこまですれば良いのか・・・

テスト技法について勉強していこうと思いました。

TDD に触れられて良かったです

今回 TDDBC に参加して非常に学ぶことが多かったです。
今までもやもやとした認識しかなかった TDD ですが、認識が深まり、
自分でもやっていけそう、会社の人にも広めたいと思いました。

そして何よりプログラミングは楽しいと再確認できたのが一番の収穫です。

僕たち、私たちは、卒業しました！

グリーンバンドゲット！！

Google Test の記事が増えたのでまとめた

Google Test に関する記事が大分増えたのと、後でまとめて見るときにめんどくさかったのでリンクを纏めました。
こちらから閲覧できます。

Jenkins 1.498 に更新したときのメモ

Jenkinsに緊急のセキュリティ勧告が出ているので、アップデートをお願いします。 groups.google.com/d/topic/jenkin…

— Jenkins(日本語)さん (@jenkinsja) 1月 7, 2013

詳細：Jenkins Security Advisory 2013-01-04

こちらを受けてアップデートした方が多いのではないかと思いますが、
アップデートしたときに少し手間取ったのでブログに残しておきます。

アップデート後に Re-key

アップデート後に [Jenkinsの管理] ページを開くと下の画像のようなメッセージが表示されています。



[Re-key in background now] もしくは [Schedule a re-key during the next startup] を
選択して暗号化用のキーの再生成をします。

スレーブが接続できなくなった場合

これまでは

java -jar slave.jar -jnlpUrl http://jenkins/computer/slave1/slave-agent.jnlp

のようにスレーブマシンからコマンドラインで起動した場合、特に問題なく接続できていました。

今回のアップデートで、Anonymous ユーザーに Slave/Connect 権限がないと接続できなくなりました。

java.io.IOException: Failed to load http://jenkins/computer/slave1/slave-agent.jnlp: 403 Forbidden

のようなエラーログが出ている場合は、アクセス権の確認をしてみましょう。

「次回から入力を省略」ができない

アップデートする前までは、ログイン画面で「次回から入力を省略」にチェックを入れておくと
次回接続時に自動でログインしてくれていたのですが、アップデートしてから毎回ユーザー名とパスワードの入力が必要になってしまいました。(1.498, 1.480.2 どちらでも)

これってバグ？
何か分かったら追記します。。。

1/9 追記

Jenkins issues にあったのでメモ
[JIRA] (JENKINS-16278) "Remember me on this computer" does not work, cookie is not accepted in new session

2/13 追記

1.501 で修正されました。
LTS はまだのよう。

2/18 追記

LTS 版も 1.480.3 で修正されました。

[Visual Studio] プリプロセス結果を IDE で見る方法

マクロを使っていると、ちょっとした間違いでよくわからないエラーが出たりしますが、
どこが間違っているか探すのがちょっと大変だったりしますよね。
そういう時にプリプロセッサだけ通したテキストを出力して、マクロがどのように展開されているのか見て探すこともあると思います。

Visual Studio の場合、 cl.exe /P hoge.cpp でプリプロセス済みファイルが出力されますが、
これを IDE から１操作でやろうと思います。

外部ツールを使う

[ツール]メニューにある[外部ツール]を使用します。

[外部ツール]をクリックすると、ダイアログが開きます。
[追加(A)]ボタンを押し、画像のように入力します。
[タイトル]はお好みでつけてください。


[コマンド]のところを入力するまえに、
下記の内容を適当な場所にバッチファイル(.bat)として保存します。
そして、保存したファイルのパスを[コマンド]に入力してください。

@echo off
call "%VS110COMNTOOLS%\vsvars32.bat"

rem プリプロセス
rem 結果は .i 拡張子で出力される
cl.exe /P /C "%~1"

rem 出力ファイルを関連付けられたアプリケーションで開く
rem この辺はお好みで編集してください。
call "%~dp1\%~n1.i"

rem 使い終わったら消す
del /F "%~dp1\%~n1.i"

以上で設定は終わりです。

このバッチファイルが今回の肝になります。
バッチの説明の前に、試しに実行してみましょう。

使用方法

1. ソースウィンドウでプリプロセス結果を見たいファイルを選択します。
2. [ツール]-[Preprocess] をクリック（Preprocess は設定で付けたタイトル名）
3. 選択したソースファイルの .i 拡張子ファイルが開きます。（※）

※ .i 拡張子に関連付けられたアプリケーションで開きます。お使いの Visual Studio に関連付けると IDE で開きます。

解説

仕組みは単純で、cl.exe が出力した .i ファイルを開いているだけです。
そのため .i 拡張子に関連づいたアプリケーションで開きます。

.i 拡張子に Visual Studio を関連付けても良いですし、お気に入りのエディタに関連付けても良いです。
バッチファイルでやることも自由なので、自分好みにバッチファイルを編集してください。

最後に

あまり良い仕組みではないですが、こんなこともできるんだー程度に思っていだければ。