shellでTDDするshunit2 その６：内部定数

shunit2にはテストを円滑にすすめるための内部定数がいくつか用意されています。

実際のところ

SHUNIT_TRUE

Standard shell true value (the integer value 0).

SHUNIT_FALSE

Standard shell false value (the integer value 1).

SHUNIT_ERROR

The integer value 2.

SHUNIT_TMPDIR Path to temporary directory that will be automatically cleaned up upon exit of shUnit2.

参考もと

github.com

【読書メモ】モダンC言語プログラミング

モダンC言語プログラミング　統合開発環境、デザインパターン、エクストリーム・プログラミング、テスト駆動開発、リファクタリング、継続的インテグレーションの活用 (アスキー書籍)

タイトルまんまの、今時なツールを活かした生産的C言語開発環境について書かれている本です。

ネタとしてはIDE*1にデザインパターン、アジャイルにTDD、リファクタリング、CIと……Webなんかでは比較的採用されている技術です。

イケイケドンドンな現場では高速軽量用途だとC++を使っていることもあるでしょう。

ただ、実際の現場ではターゲットマイコン用のコンパイラがC言語用しかない事も考えられます。
あるいは土台となるライブラリ/リファレンス実装がやや古めなC言語による実装で提供されているため止むを得ず……なんてケースもありますね。

こういう現場となると、どうしても開発環境も引きずられて古い環境で構築されていたりします。
この本ではそういった「現実の問題」との折り合いの付け方も紹介されているので
今苦しんでいる人も何か拾えるネタがあるかもしれません。

2014年の本ではありますが、C言語を使ってるほとんどの現場ではこれらノウハウを実際に運用できてないところばかりではないでしょうか？

*1:クロスプラットフォーム性を考慮してか、Eclipseが紹介されていました

【イベントログ】マルツロボットフェアに出てきました

明日、マルツロボットフェアを開催します！
　日時：2月2日（土）11:00～17:00　
　場所：東京都調布市小島町1-1-1UECアライアンスセンター1F
　内容：★KONDO BATTLE★　★電子工作体験コーナー★　★ロボット体験コーナー★　★抽選会★
　遊びにお越しください！ pic.twitter.com/mljJMGE7bP

— マルツ@調布電通大電子部品／西東京営業所 (@marutsu_uec) 2019年1月31日

マルツエレック様と近藤科学様が電気通信大学でロボット関連のイベントを開催されました。
第28回KONDO BATTLEという、人型ロボットの大会を
ウチはロボットアームを出してきました。

ダイジェスト動画

主催社のマルツエレック様が、イベント当日のダイジェスト動画をつくってくれました。
うちのロボットアームも取り上げられています。

https://t.co/igTb9S4t2i

— マルツ@調布電通大電子部品／西東京営業所 (@marutsu_uec) February 7, 2019

shellでTDDするshunit2 その５：Table Driven Testで似たテストを自動化

Table Driven Testをつかうと、似たデータのテストをブン回すときに便利です。

実際のところ

ヒアドキュメントで

while read desc arg want; do
  got=$(fn ${arg})
  rtrn=$?
  assertTrue "${desc}: fn() unexpected error; return ${rtrn}" ${rtrn}
  assertEquals "${desc}: fn() = ${got}, want ${want}" "${got}" "${want}"
done <<EOF
test#1 value1 output_one
test#2 value2 output_two
EOF

あるいは、ファイル数が多くなって手に負えなくなるケースもあるでしょう。
そういう時はテスト用のデータを用意

while read desc arg want; do
  got=$(fn ${arg})
  rtrn=$?
  assertTrue "${desc}: fn() unexpected error; return ${rtrn}" ${rtrn}
  assertEquals "${desc}: fn() = ${got}, want ${want}" "${got}" "${want}"
done </path/to/some/testfile

実際のところ

github.com

shellでTDDするshunit2 その４：初期設定と破壊

shellでTDDするshunit2のお話。
今回はTDDフレームワークで欠かせないものの一つ、テストの前と後の値設定です。

実際のところ

oneTimeSetUp/setUp

存在する場合テスト前に呼び出され、そのテストで使用する一時環境変数を設定します。
前者は呼び出されたら最初に一度つくるだけ。
後者はテストの度毎回呼び出されるコマンドです。

oneTimeTearDown/tearDown

主な用途はsetUpで作った環境変数の破壊です。
前者は全てのテストが終わったら一度呼び出される。
後者はテストの度に毎回呼び出される。

本家の事例

テストサンプルのディレクトリ作成の事例では、oneTimeSetUpとtearDownの組み合わせで使われています。
github.com
作者様の姉妹プロジェクトであるlog4shのテストでも色々事例があります。
github.com

参考もと

GitHub - kward/shunit2: shUnit2 is a xUnit based unit test framework for Bourne based shell scripts.
GitHub - kward/log4sh: log4sh is an advanced logging framework for Unix shell scripts.

shellでTDDするshunit2 その３：つかえるAsserts

実際のところ

assertEquals [message] expected actual

expectedとactualを比較し、同じなら正を返す。
要は普段使いのコマンド。

別表現として"assertSame [message] expected actual"という記法もあり。
個人的には、どちらかに限定して置いた方があとあと楽かと思います。

assertNotEquals [message] unexpected actual

先ほどとは逆でexpectedとactualを比較し、異なるなら正を返す。

こちらも"assertNotSame [message] unexpected actual"という別表現あり

assertContains [message] container content

containerに記載されている要素（文字列として評価される）がcontentにあった場合、正。
例：

assertContains 'abcdef' 'abc'

assertNotContains [message] container content

assertContainsも逆バージョンあり。

assertNull [message] value

valueがNULLじゃなときに正となる。
0文字の列の場合が該当するので、どこかの言語のように0がNull扱いということはありません。
また、プリント不可文字("¥01"とか)も含まれるので注意。

assertNotNull [message] value

valueがNULLじゃない……なんらかの文字列にできる場合

assertTrue [message] condition

実行中のシェルでTrueとなる値、"${SHUNIT_TRUE}"で定義された値になっていれば正を返します。

参考もと

github.com

shellでTDDするshunit2 その２：Red/Greenをブン回す

前回に続いてshunit2のお話。
今回はいよいよRed/Greenテストの開始です。

実際のところ

つかってみる

ではまず失敗するファイルをつくりましょう

#! /bin/sh

myFunc() {
 echo 0
}

testEquality() {
  value=`myFunc`
  assertEquals 1 "$value"
}

# Load shUnit2.
source shunit2

意図通りREDになります。

$ ./testsh.sh 
testEquality
ASSERT:expected:<1> but was:<0>

Ran 1 test.

FAILED (failures=1)

では、こいつをgreenにしてきましょう

#! /bin/sh

myFunc() {
 echo 1
}

testEquality() {
  value=`myFunc`
  assertEquals 1 "$value"
}

# Load shUnit2.
source shunit2

実行すると……はい、緑になりまし……たっ！*1

$ ./testsh.sh 
testEquality

Ran 1 test.

OK

二個目のテストとコメント追加

テスト増やしていくとわけがわからなくなるので、コメントを増やしていきましょう。
今度はassertの引数を三つにします。
一個目がコメント、二個目が期待値で三個目が実際の値です。

#! /bin/sh

myFunc() {
 
 echo 1$1
}

testEquality() {
  value=`myFunc`
  assertEquals "myFuncTest simple" 1 "$value"
}

testEqualityWithValue() {
  value2=`myFunc 12`
  assertEquals "myFuncTest with value" 1 "$value2"
}

# Load shUnit2.
source shunit2

$ ./testsh.sh 
testEquality
testEqualityWithValue
ASSERT:myFuncTest with value expected:<1> but was:<112>

Ran 2 tests.

FAILED (failures=1)

緑にしてきましょう。

#! /bin/sh

myFunc() {
 
 echo 1$1
}

testEquality() {
  value=`myFunc`
  assertEquals "myFuncTest simple" 1 "$value"
}

testEqualityWithValue() {
  value2=`myFunc 12`
  assertEquals "myFuncTest with value" 112 "$value2"
}

# Load shUnit2.
source shunit2

OK

$ ./testsh.sh 
testEquality
testEqualityWithValue

Ran 2 tests.

OK

あとはこんな感じでどんどん追加です。

参考もと

github.com

*1:元ネタわかってない