サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
って話になって、チーム内で盛り上がった。例えばこんな感じのテストを書きたい時。 「ジュースを買う」メソッドに、お金とジュースの番号を入力したらそのジュースが返されて、在庫が一個減る。 メソッドはこんな感じかな？ Juice buyJuice(int inputAmount, int juiceId) これでどう？ buyJuice_shouldReturnJuice_whenInputAmountIs130Yen え？でもこれだと、なんかこう・・・在庫が減ってることとかは表せてなくない？ えー、じゃあこういう感じ？ buyJuice_shouldReturnSelectedJuiceAndOneLessInventory_whenInputAmountIs130YenAndSelectedIdIsValid いや、長いね・・・。 ふむ。。。全部をメソッド名に書かない方が幸せなんじゃない？
JUnit4.12がでました！……2014/12/4に。なんと6ヶ月経ってる。まぁいいや。 JUnit 4.12の新機能紹介まとめ / うさぎ組(2014/8/5) JUnit 4.12から入ったTestRuleを軽く見てみる / 裏紙(2015/2/28) JUnit4.12時代のParameterized Test / mike-neckのブログ(2015/5/6) ググっても4.12の情報があまり引っかからなかったので書いてみますね。 リリースノート斜め読み とりま、Summary of changes in version 4.12 を斜め読み致して、気になるところ（★）は後でもう少し詳しく書く事にします。なお、バグフィックス、メッセージ変更、挙動の統合などの特にテストコーディングに影響を与えないものはスルー。 Assersions floatのassertNotEquals →
作成したアプリケーションは、どのように動作確認していますか？Androidには、Javaの単体テストのフレームワークである「JUnit」を使用することができます。今回は、その使用方法について説明します。 <1>アプリケーションの仕様を決める まず、作成するアプリケーションの仕様を決定しないといけませんが、今回は下のようなAndroidアプリケーションを作成します。 画面の一番上にEditTextを貼り付ける。 EditTextの下に、TextViewを貼り付ける。 EditText、TextViewの初期値は空文字。TextViewの下には「コピー」という文字が入ったボタンを貼り付ける。 「コピー」ボタンは、EditTextに文字が入力されていない場合は、ボタンを押下することはできない（無効になっている）。 「コピー」ボタンを押下すると、EditTextの内容がTextViewにコピー
テスト作業が、開発作業の中にしっかりと組み込まれていない。こうなる と、開発の進み具合を計測することは不可能になってしまう。というのも、あ るの機能が動き始めたのはいつか、またある機能が動かなくなったのはいつか、 まったくわからなくなるからだ。 JUnit を使えば、苦労なく、しかも段階的に、テストスィートを構築 できる。このテストスィートは、進捗状況を把握したり、意図しない副次効果 を見つけだしたり、また開発で労力をかけるべき箇所を明らかにしたりする上 で役に立つだろう。 目次 問題 実例 テストする習慣（プラクティス） 結語 問題 どんなプログラマだって「コードを書いたらテストも書くべきだ」というこ とは知っている。にもかかわらず、実際に書いている人は少ない。「何で書か なかったの？」という質問に対しては、「あまりにも忙しすぎて」という同じ 答えが返ってくる。しかしこれは悪循環のはじま
先日、日本Javaユーザグループ（JJUG）主催のJJUGCCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
あらすじAndroidのテストを自動化したいので、テストツールの選定をしてみたが、昔の記事がヒットする事が多く、何を使えばいいのかよくわからん。 とはいっても、明確に「どんなテストがしたい」という方針もなく、とっかかりとしてどんなツールがあってどのくらい盛り上がってるのかが知りたかった。 環境Windows 7AndroidDeveloperToolsBuild: v21.1.0-569685 とりあえず Win メインで。 とっかかり ロジックまわりのテスト ロジック的なものは、 JUnit 拡張の TestCase クラスを使えば何とか書けそうというのはわかった。Androidアプリ開発テスト入門（2）：Android SDKでビジネスロジックのテストを自動化するには (1/3) - ＠IT 2011 年の記事だけど、 JUnit で書くという大前提は崩れていないはず…。 画
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
