Jenkins を iOS アプリ開発に導入してみた (GHUnit編)
前回 はSenTestKitを用いてJenkins上で単体テストの自動実行を行いました。今回はGHUnitを使った単体テストの自動実行にチャレンジしてみたいと思います。またついでといっては何ですが、単体テスト時に必要になってくるモックを作成するためのライブラリOCMockも同時に導入してみようと思います。 ■なぜGHUnitを使うのか GHUnitを使うことで、SenTestingKitと比べて以下のようなメリットが得られます。 非同期処理のテストを行うための仕組みが用意されている（GHAsyncTestCase）これをSenTestingKitないし他のテスティングフレームワークでやろうとすると大変骨が折れます。 .app形式（要するに実際のiOSアプリケーション）でテストを実行するため、UIApplicationやUIWindowといったUIコンポーネントを使うクラスのテストが可能にな
GHUnitとOCMockでUnit Test効率化 - jarinosuke blog
また、テストを書く。 最近 iOS 界隈のテストのベストプラクティスについて調べているのですが、そこで目に留まった文章があるのでまずそれを紹介します。 How comfortable are you on a bike without a helmet? Writing code without tests is like riding a bike without a helmet. You might feel free and indestructible for now, but one day you’ll fall and it’s going to hurt. http://paulsolt.com/2010/11/iphone-unit-testing-explained-part-1/ ヘルメットを付けずに自転車を漕ぐのはとても快適ですね。でも、ふとしたある日に取り返しの
MMORPGで考えるレベルデザイン
Aiming Inc. 社内で行われたレベルデザインに関する勉強会のスライドです。使用許可の無い画像は削除してあります。ご了承ください。
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
BDDについて自分なりにまとめてみた - UKSTUDIO
BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日本語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
PyPy における Python のパフォーマンスチューニング
これは PyPy Advent Calendar の記事です。PyPyのコアディベロッパーである "Maciej Fijalkowski" 氏のブログ "Analysing python's performance under PyPy" の抄訳+αです。 Python の一般的なパフォーマン解析のモデルは、"プロファイラを実行して、ボトルネックを探し出し、それを最適化するか C で書き直す" ことです。しかし PyPy ではこのアプローチだけでは不十分です。なぜなら、 多くの大規模アプリケーションで、プロファイラはフラットです: PyPy のトランスレーションツールチェーン、Twisted、モダンな Web サーバ等が良い例です ボトルネックを発見したとしても、それが特定の関数内でのみ遅いのか、複数の関数が関係しているのか明確になるわけではありません。どうすれば遅くて、どうすれば速くなる
pythonで、コマンドラインから実行するスクリプトを書いたときのテストの書き方 - ANS-prog
xxxx.pyに直接以下のようにコードを書いているのだと想定します。 import sys arg = sys.argv[1] count = raw_input("count? ") # write some code and set 'result' value print result これは以下のように書けます。 import sys def run(argv, count): # write some code and set result value return result def main(): x = raw_input("count? ") result = run(sys.argv, x) print result if __name__ == '__main__': main() この様に書かれたxxxx.pyには3つのメリットがあります。 直接実行すれば変更前と
mockはこう使え - atsuoishimoto's diary
最近、Mockライブラリ http://www.voidspace.org.uk/python/mock/ を使ってみたのでメモ。 このライブラリは、その性質上、動的にメソッドや属性を作成するケースが多く、普通のPythonライブラリのようにイントロスペクションに頼って使い方を調べるのは難しい。本気で使うならまじめにドキュメントを読み込む必要がある。 関数の置き換え テスト中に呼び出される関数をMockで置き換える例。ここでは、関数 myapp.utils.func1() を置き換える。 from mock import Mock import myapp.utils # myapp.utils.func1 を、常に100を返す関数に置き換える myapp.utils.func1 = Mock(return_value=100) 戻り値が定数でない場合は、Mock()にside_effec
Python の新ユニットテストフレームワーク (or unittest2)
これは Python3 Advent Calendar の記事です。夢はテストエンジニアです！ということでユニットテストについて書きます。 Python3 縛りとのことですが、この新ユニットテストフレームワークは Python 3.2 以降と 2.7 以降が対象です。これ以前のバージョンでこの新ユニットテストフレームワークを利用したい場合は、それぞれ unittest2py3k (3 系)、 unittest2 (2 系) というバックポートが用意されています。新ユニットテストは mock や IronPython 等の開発者としても知られている Michael Foord 氏を中心に開発されました。 >>> Python とユニットテストの歴史 Python のユニットテストは、1999 年 xUnit ファミリーの PyUnit として開発され、2001 年に公開された Python
世界のJavaScriptを読もう @ 2012
調べる方法を知る JavaScriptは調べるとやり方が見つかることが多い 古いものと最近のものがまざってる ごく最近〜未来のものは見つけにくい 以下の総集編的な内容 海外のJavaScript情報を見つけよう 世界のJavaScript情報を読もう 今からRSS購読すべきタグと検索結果 ブラウザの最新情報を知るために、Web開発者が読んでおくべきブログ Webの動きはとても早いので、調べ方を知る
JUnit のセカイ #JJUG - やさしいデスマーチ
このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD（テスト駆動開発）と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit？と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか？JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
モックによるインターフェイスの発見 - Digital Romanticism
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』（いわゆるGOOS）の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"（以下、MRnO
PHPUnitのアンチパターンとベストプラクティス
みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたらPHPUnitのアンチパターン・ベストプラクティスに関する素晴らしいスライドを見つけたので内容を抜粋で紹介します。 1. テストの中で何もテストしていない class FooTest extends PHPUnit_Framework_TestCase { public function testSomething() { $foo = new Foo; $foo->doSomething(new Bar); } } こういうテスト。どこにもアサーションがなくて何もチェックしていません。 $foo->doSomethingの戻り値を検証しないならなんの意味もありません。 純粋にTDDをしていれば、テストコード作成→テスト実行でRed→プロダクションコード作成→テスト実行でGreenなのでこういうテストは登場しませ
FizzBuzzではじめるテスト - 第１回関西PHP勉強会
7/22に大阪市内で第１回関西PHP勉強会を開催しました。 4月にPHPカンファレンス関西を開催して以来、3ヶ月ぶりにPHPの勉強会を開催しました。 参加頂いたみなさんありがとうございました。また発表を快く引き受けていただいた皆さん、本当にありがとうございました。 イベント名に「第１回」と付けたのは、今後も継続して開催していきたいという気持ちの表れです。PHPを軸に色々なテーマで開催していきたいと思うので今後もよろしくお願いします。 スイーツタイム 勉強会をやるときは、休憩時間にみんなで食べるおやつを用意するのですが、今回は @msng さんに色とりどりのマカロンを用意してもらいました。見た目も鮮やかですし、適度な甘さで好評でしたね。（たしかに美味しかったです！） 昨今「スイーツタイム」が話題になっていますが、会場で飲食が可能なら実施することに賛成です。 単純に勉強会で発表を聞くだけでも疲
ソフトウェアテスト技法いろいろ
シャノンに来てからはまだ1年半くらいですが、社会に出てソフトウェアテストしかやってないので、もう6年以上テストしてます。
TDD Boot Camp のお題を C# と Git でやってみた - 予定は未定Blog版
自分で考えたお題を自分で解くとかそれなんてマッチポンプ・・・ 打ち上げ終了後のホテルと、翌日の帰りの新幹線の中で書いたコードを順番に追ってみます。 準備するものは Git で、あるといいものは Visual Studio 2010 と NUnit です。 まぁ、割と小さいコード (テストを含めても 300 行もない) だし C# を知らない人でもそれなりに雰囲気は掴めると思います。 あ、このエントリかなり長いです。 準備 Windows の場合、Git Bash を開いて、適当なフォルダに移動して git clone git://github.com/bleis-tift/MotsunabeZombieProject.git cd MotsunabeZombieProjectとしてください。 MotsunabeZombieProject というフォルダができて、その中に Git のリポジト
えっ、私のテストカバレッジ、低すぎ…？ - いま作ってます。
まとめ テストの「カバレッジ」には、C0, C1, C2の3レベルが存在する 一般的なカバレッジ測定ツールはC0しか測定できない C0だろうがC2だろうが、カバレッジは目安にしかならない とはいえ、他に目安になる物は何もないので、見ないよりは見た方がいい 序 しばらく前のShibuya.js*1が面白そうだったので指をくわえながらIRCで後輩に一席ぶった「テストカバレッジの罠」について書いておくよ。 FizzBuzzのテスト 以下のようなコードを考えよう*2。 <?php function fizzbuzz($i){ $return = ''; if( $i % 3 === 0 ) $return .= 'Fizz'; if( $i % 5 === 0 ) $return .= 'Buzz'; if( $i % 3 !== 0 && $i % 5 !== 0 ) $return = $i;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitbucket | Git solution for teams using Jira
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
