サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Androidアプリ開発（に限った話ではないですが）でTDDしたいと思ったときに、テスト対象クラスのフィールドをモックで差し替えたい、と思うことがしばしばあります。依存するクラスの振る舞いを固定化することで、テスト対象オブジェクトの振る舞いだけに着目したテストケースを書くことができるからです。 そんな時に、DIコンテナ上でコードを書いていると便利です。以前、少しだけSeasar2+EasyMockでテストを書いていたことがあったのですが、作成したモックオブジェクトの差し替えを、ほぼ全てSeasar2がやってくれたのでものすごく便利でした。Android開発でもSeasar2+EasyMockくらい簡単にテストを書きたい！ ということで、Android Mockでモックオブジェクトとその振る舞いを定義 RoboGuiceでモックオブジェクトをテスト対象クラスにインジェクト ということをや
手順Android側 コマンドラインでAndroidプロジェクトの作成 antコマンドでプロジェクトをビルド gitにcommit & push hudson側 hudsonのインストール hudsonを起動 hudsonプロジェクトを作成 jobの追加 ターゲットプロジェクト テストプロジェクト hudsonからビルド hudsonでテストAndroidTest側 コマンドラインでAndroidのテストプロジェクトの作成 antコマンドでプロジェクトをビルド エミュレータを起動する コマンドラインでテスト実行 gitにcommit & push hudsonのインストール http://hudson-ci.org/ からhudson.warをダウンロードして適当なところに配置Androidプロジェクトをコマンドラインから作成 hudson上でBuildするのにantコマンドを使いま
Testing your code is annoying, but the impact of not doing so can be orders of magnitude more annoying! In this article, we'll use test-driven development to write and test our code more effectively. What is Test-Driven Development? Since the dawn of the computer era, programmers and bugs have battled for supremacy.It's an inevitable occurrence. Even the greatest programmers fall prey to these an
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
