PHPUnitにDBUnitを拡張してテスト用DBのデータを初期化させてみた
はじめに
テストを実行する際に、テスト用DBのテーブルのレコードをええ感じで初期化したいな〜という思いがありました。"ええ感じで"というのはそんなに深い意味はなくて、研修でwebアプリを作った時は、テスト実行時にDBのテーブルのレコードを初期化するコードをテストファイルの中にごちゃごちゃ書いてやっていたので、もっとスマートにやりたいなーというくらいのニュアンスです。
今回はDBUnitを導入してみました。
ちなみにPHPUnitも公式ドキュメントで
DbUnit を使うと、 データベースのテストにおけるこれらの問題をシンプルにする助けになります。
って言うてるみたいです。
DBUnitの導入
テスト用のクラスに継承させる
そしてテストクラスで
class Hoge_FugaTest extends PHPUnit_Framework_TestCase
と継承していたものを
class Hoge_FugaTest extends PHPUnit_Extensions_Database_TestCase
と書き換えます。
設定用メソッドの実装
次に上記のフレームワークを継承したクラスに以下の２つのメソッドを実装します。
getConnection()はテスト用のDBへ接続情報を与え、getDataset()はDBのテーブルへの初期データの情報を与えます。
public function getConnection()
{
$db = \Database_Connection::instance();
return $this->createDefaultDBConnection($db->connection(),'testDBname');
}
public function getDataSet()
{
return $this->createFlatXmlDataset(APPPATH."tests/defaultDataset.xml");
}
'testDBname’はテスト用のDBの名前を指定するみたいですが、fuelphpでは各開発環境ごとに接続するDBの情報をconfigフォルダで管理しています。一応中の処理も見たのですが、おそらく？dbのDatabase_Connectionのインスタンスを作成する際にそのファイルを読みに行ってくれている？と思われるので、特に指定する必要はなさそうです。試しにtestDBnameを空文字にして試してみましたが、ちゃんと動いてくれました。
なんにせよ、これでテスト実行時にDBのテーブルのレコードを指定した値を用いて初期化してくれるようになりました。
初期データの指定
なお初期データは別のxmlファイルに切りだし、そのファイルのパスを指定してやればOK。
データは以下の様に記述します。
<?xml version="1.0" ?> <dataset> <users id="1" name="aho" password="ahopass" /> <users id="2" name="boke" password="bokepass" /> </dataset>
一点だけ詰まったのが、各フィールドに指定する値は、DBのテーブルで指定した型によらずクォーテーションで囲まないといけない様子。idとかの数値をそのまま書いてたらエラーで怒られました。
ポモドーロテクニックを導入して得られた３つの効果
ポモドーロテクニック導入
新人研修中に、タスクや時間管理の手法としてポモドーロテクニックを導入していました。本手法導入により得られた効果について社内勉強会で発表したので公開します。5分のLTだったので方法論や効果について詳しく言及できていませんがあしからず。
www.slideshare.net
TDD入門（テストを書いてみよう！＆Test::SimpleとTest::Moreって？）
はじめに
これまでテストなんて1ミリも気にせず，やっつけでコーディングしていました．
が，しかし，テストを書くと幸せになれると聞いたので頑張って身につけようと一念発起．
めちゃくちゃ奥が深そうなので，段階的に，細かくアウトプットしていくつもりです．
TDDとは
Test Driven Development(テスト駆動開発)の略称．
プロダクトを作成する時，いきなりメインコードを書き始めるのではなく，プロダクトに必要と思われる機能のテストコードから書き始める開発手法．
テストから書くことによって様々な恩恵を得られるそう．たとえば，
・プロダクトの各機能は常に思った通りに動く
・冗長なコードが生じにくく，内部品質の向上につながる
などなど．
他にもたくさんあるそうですが，現段階で私自身が実感しているメリットはまだこれこれくらい．
テストを書いてみる
my $day=15; print $day == 15 ? “ok!” : “no today is the 15th”;
実行します
perl -Ilib hoge.t
$dayの値が15であればokを，それ以外はnoを返します．
今回では内容が一致しているのでokが返ってきました．
試しに$dayの値を15以外でやってみると正しくnoが返ってくることがわかります．
Test::Simple
先ほどのコードを見て，まあテスト１個ならまだしも，いっぱいある時に全部printしていくのめんどくさ・・・てなりますよね．
そこでTest::Simpleを利用します
use Test::Simple; my $day=15; ok($day == 15);
先ほどprintでやっていたのがすべてok()に置き換わりました．
これで実行してみるとok 1 かnot ok 1が返ってきます．
またまた思うところとしては，これ，テスト数が少ない時だとまだマシですが，多くなったらどのテストが失敗したのかわかりにくいですよね．
そこで，ok()の第２引数にコメントを取ることができます．
use Test::Simple; my $year=2016; my $month=3; my $day=14; ok($year == 2016,"check year"); ok($month == 3,"check month"); ok($day == 15,"check day");
例えばこれで実行してみると，以下のようになります．
ok 1 - check year ok 2 - check month not ok 3 - check day # Failed test 'check day' # at test.t line 10.
なるほど，これでどのテストでエラーが起こったのかがわかりやすくなります．
さて，エラー箇所は特定できるようになりましたが，どういう結果になってテストが失敗したのかがわかりません．
今はハードコードで書いているため一目瞭然ですが，いろんなデータを処理しているとバグなどが原因で思った値が入っていないなんてことが起こりえます．
Test::More
そんな時はTest::Moreを使います．
名前の通り，Test::Simpleよりも機能がより多く使えるようになるそう．
use Test::More; my $year=2016; my $month=3; my $day=14; is($year,2016,"check year"); is($month,3,"check month"); is($day,15,"check day");
ok()関数ではなくis()関数を用いてそれぞれ第１引数にはチェックしたい値，第２引数に期待する値，第３引数にコメントを取ることができます．
これで実行すると
ok 1 - check year ok 2 - check month not ok 3 - check day # Failed test 'check day day' # at test.t line 10. # got: '14' # expected: '15'
３つめの日付のテストで失敗しており，さらに期待する値が15であったのに対し実際には14であった，ということが確認できるようになりました．
参考
以下の公式？サイトを参考にしました．和文に関して，エキサイト翻訳などにそのまま突っ込んだようなものしか見つからなかったので，内容は原文の翻訳をちょびっと意識しています．
Test::Tutorial - search.cpan.org
macにanyenvを導入してみた
anyenvとは？
perlやruby、pythonなどのバージョンを管理するplenvやrbenv、pyenvなどを一括で管理してくれます。これらを別々に管理していた場合、それぞれのパスの設定を行う必要があり.bash_profileが煩雑になります。それがanyenvで一元化して管理しているとanyenvへのパスだけ通してやればよいっぽいです。どうせ複数のenvで管理することになるなら、anyenvを使って一元化管理しようということで。情報の一元化はいろんな手間軽減につながりますからね。
既にインストールしていたenv系のアンインストール
すでにhomebrewを使ってインストールしているものがありました。これとanyenvでインストールしたものとが複数存在すると後々ややこしそう（実際この前ややこしかった）なので、アンインストールしておきます。なおbrewでインストールしたenvではほとんど管理しているものがなかったので、移植作業等は一切行わず、そのまま削除しました。既に結構システムのenvで色々管理している場合には注意が必要かも。
$ brew uninstall plenv $ brew uninstall perl-build
同時に.plenvなどの設定ファイルも削除しておきました。
anyenvのインストール
いよいよanyenvの導入です。
githubからcloneしてきます。
$ git clone https://github.com/riywo/anyenv ~/.anyenv
.bash_profileに以下のパス設定を追加
$ echo ‘export PATH=“$HOME/.anyenv/bin:$PATH”’ >> ~/.bash_profile $ echo ‘eval “$(anyenv init -)”’ >> .bash_profile
これでanyenvのインストールが完了しました。
そもそもenvって何してくれんねん
システムにインストールされているperl等だと、アップデートした際に全てのプロダクトに影響が起こりえます（バージョンアップしたら動かんくなった！他のモジュールとの互換性がなくなった！など）。この時、プロダクトごとに使用するバージョンを固定し管理することで、こういった問題を防いでくれます。
研究で作っていたプロダクトは長期運用のつもりはなかった（こんなん言うたら教授に怒られそう）ので、特に気にせず使っていましたが、実際の開発現場では当たり前に使われています。調べれば似たような記事やもっと詳しい記事がたくさんありますが、備忘録のため、まとめておきます。
話を戻しましょう。
例えば、基本的にはこのバージョンを使いたい！というものは
$ plenv global 5.23.0
とするとOK。
逆にこのディレクトリ以下では5.21.0が使いたい！という時には、そのディレクトリで
$ plenv local 5.21.0
とすればOK。
ruby+sinatraで作成したwebアプリへの外部からのアクセス方法
久しぶりの更新ですね（ちゃんと生きてます
今回はweb初心者がrubyの起動に関するところで勉強したことをひとつ．
はじめに
webアプリをサーバで動かし，そこに他のマシンからアクセスできるようにするためには，自分でイチからサーバ構築する必要があるのかと思っていました．
しかし，WEBrickを使えばそんな必要はなさげです．
webrickとは
はい，わざわざ自分で構築する必要がなくなります．
どうやら最近のバージョンでは，rubyインストール時にくっついてきてくれるようです．
当然，実際に運用するためにはきちんと構築する必要がありそうですが，今回みたいに実験的にちょこちょこっと使いたい，みたいな用途に対しては非常に便利ですね．
アプリの起動
では，実際に起動してみます．
ruby filename.rb
これでwebアプリを起動することができます．
しかし，このままではlocalhostからのアクセスしか受け付けません．
そこで，実行環境とホストのIPアドレス，ポート番号を指定してやります．
ruby filename.rb -e production -o IPAddress -p port
eで実行環境を選択することができます
developmentは開発環境として，productionは本番環境として起動してくれます．
oでホストのIPアドレスを，pでポート番号を指定することができます．
今回はrubyプログラムを実行するマシンのIPアドレスを固定し，そのアドレスを指定しました．
これで無事に動いてくれます．
次に他のマシンからサーバに対してのアクセスを試みます．
他のマシンからのアクセス
IPアドレス:ポート番号/filename
ブラウザから，指定したIPアドレスとポート番号を入力し，表示させたいページを指定すればOK
localhostの場合だと，localhost:4567/indexという具合ですね．
これで他のマシンからもアクセスが可能になります．
参考
参考にさせていただいた記事はこちらhamuhamuengineer.blogspot.jp
大学生限定の無料カフェに行ってきた！
久々の更新です．
今回は知るカフェというカフェに行ってきたので，それについて．
知るカフェとは？
大学生限定のカフェで，
・ドリンク無料
・Wi-Fi使用可
・コンセントあり
・持ち込みOK
・ミーティング利用可
とまあなかなかに最強なカフェです．
企業がスポンサーについており，そのおかげでタダでコーヒーとかが飲める仕組みだそう．
そうして学生を集め，企業側はインターン募集や就職(?)相談会的なものなど，様々なイベントを開催している様子．
もちろん全学年対象のイベントも多くあり，話を聞いてみると，どのイベントもかなり人気らしく，いつも募集定員いっぱいになるくらいの人が来ているそうです．
ちなみに今回は同志社前店に行ってきました．
使い方
はじめに一度だけ，会員登録を行います．
それ以降は学生証の提示のみでOKのようです．
一瞬，同志社前店は同志社生限定かと思いましたが，登録フォームには自分の所属大学を選択する欄があったので，大学生ならどこの大学でも大丈夫っぽいです．
＃もちろん，大学の選択肢の欄にウチの大学は載っていませんでしたが．
使ってみて
かなり，いい感じです．
まだオープンしてすぐということで店内もキレイですし，何よりWi-Fiとコンセントとフリードリンクのコンボが最強です．Wi-Fiがすこし重いのだけはネックですが，作業空間としてはかなりイケてると思いました．
ドリンクは今回，ホットコーヒーを頼みました．
よくある喫茶店で出てくるカップみたいなものを想像していたのですが，それの2倍くらいは入るであろうマグカップで出てきて，さすがにびっくりしました．
空きコマなどの時間つぶしで来る学生も多いようですが，一人で作業をしに来ている学生も多く，比較的静かな環境でした．
また店員さんの愛想も良く，非常に満足度の高いカフェでした．
とまあなかなかに最強なカフェでしたが，研究室の環境はもっと最強なので，ボクにとっては，わざわざココに来て作業する必要はないかなあという感じ．
逆に，もし自分が研究室配属される前だったら，入り浸っていたと思います．
しかし，大学からの帰り道に寄っていける場所にあるので，気分を変えて作業をしたい時など，ちょくちょく行こうと思います．
立命館大学前店が！
できるそうです．これはもっと早くにできていて欲しかったですね．shirucafe.com
京都開催のエンジニア×デザイナー×プランナーMeet upイベントに参加してきた！
先日，京都で行われたエンジニア×デザイナー×プランナーのMeet upイベントに参加してきました．
最近Twitterでいろんな方とつながることが多いのですが，今回のイベントも，Twitterでフォローしていただいた方のご紹介で参加させていただくことになりました．
主催
主催はデルタクロス京都さんdeltacross.net
関西の学生を対象に，東京企業のリモートインターンシップ支援を行なっている学生団体さんです．
他にも日々，様々なイベントが開催されているようです．
行ってみて思ったこと
参加者それぞれが，自分のフィールドでしっかりアウトプットを出しているのがすごい，と思いました．
しかも２，３回生の段階で．
ボクがそれくらいの頃といえば，せいぜい演習授業で作ったソフトウェアがアウトプットに一番近いモノでした．
あの頃はとりあえずサークルして，バイトして，飲んで遊んで，という感じですっちゃかめっちゃかでしたからね・・・
でも一応授業もきちんとでてましたし，実験や演習も真面目にやってましたが，それ以上，はなかったです．
なので単純に，すごいな，と思いました．
そういう意味では，大学院へ進学したのは大きかったと思います．
ものづくりの面白さや難しさなどいろいろなことを学べました．
特に，日々の研究活動やデザイン学専攻の学生と一緒に行うインデザプロジェクトなどでエンジニアとしての考えが大きく変わったのはデカイです．
まあまだこれをいうのは少し早い気もしますが，この研究室を選んでよかったなあと思いました．
なんかイベントの話から脱線してしまいましたね．
そんなこんなで，たくさんの方とお話しさせていただきました．
参加されていたのは京府医大学院，立命，同志社の方や，これまであまり絡んだことのない清華大やHAL大阪の方など．
特にデザイナーの方が多く参加していたようです．
割と最後まで残っていたのですが，最後まで一緒に喋っていた運営のお二人とは，今度お酒でも飲みながらいろいろ喋ってみたいなあと思いました．是非飲みに行きませんか？笑
せっかく京都でこういったつながりを作ることができたので，これっきりにならないよう，大事にしていきたいと思います．
最後に，全体の写真を一枚．
あ，あと，こういうときにポートフォリオがあるとすごい便利ですね．
エンジニアの場合はGitHubとかがそれに近いと思いますが，割とプロダクトっぽいアウトプットが多いので，学会発表が終わってから一回まとめてみようかなあ・・・
