android.casual.test #2 の発表資料です。 LT 内容の補足も含めた勉強会全体の感想などは次の記事を参照してください: http://vividcode.hatenablog.com/entry/study-meeting/android-casual-test-2Read less
詳解Objective-C2.0にはテストの話がなかったけど、この辺は何で学ぶのがよいのだろうかなあ 2014-01-12 10:49:26 via web @nagayama テストのこと書いてある和書たぶんぜんぜん無い気がします。洋書ならありそう。Xcode標準のXCTestとOCMockとOHHTTPStubsとTKRGuardを使ったら最低限の単体テストが書けるつもり。あとexpectaとspecta使ってもよさそう。 2014-01-12 12:37:56 via Twitter for iPhone to @nagayama から 公式ドキュメント翻訳 Xcodeの概要(PDF) 「アプリケーションのユニットテスト」の項目があります、が内容は薄い。 Instrumentsユーザガイド(PDF) 「UIのテストの自動化」の章がありUI Automationについてふれられています
iOSのアプリケーションではモデル周りのテストと同じぐらいUI周りのテストが重要な気がするのですが、画面のテストってちょっと面倒ですよね。その上Xcode標準のテストフレームワークでは画面遷移などのテストができません。そこで、統合テスト用のテストフレームワークを使う必要がでてきます。 選択肢はいくつかありますが、使い方がシンプルで導入も容易なKIF Frameworkを紹介します。 KIF Framework GitHub - kif-framework/KIF: Keep It Functional - An iOS Functional Testing Framework KIFは決済サービスSquareが自社アプリケーションの統合テストのために開発したフレームワークだそうです。KIFを使ったテストではボタンをタップして画面遷移したり、画面遷移した先のUIの存在を確認したりといったこと
2013-12-15 Android Test Casual Talks 01を開催しました Android Test Casual Talks #1 on Zusaar Agenda 01 · hotchemi/android-test-casual-talk Wiki · GitHub Twitter / Search - #androidtest 先日、Android Test Casual Talksというイベントを@androhiさんと開催しました。ハッシュタグは#androidtestでした。 Androidのテスト専門イベントというニッチな会だったので人が集まるが心配でしたが、蓋を開けてみれば募集から半日程度で定員が埋まってしまい、最終的には20人以上補欠でお待ち頂くという嬉しい誤算でした。 会場はリクルートのMTLカフェをお借りできました。 会場をご提供頂いた@i2key
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード(または実行結果)を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
Android OSを搭載した携帯端末の種類はもはや数えきれないほどであり、複雑化するアプリケーションのテスト工数の増大はAndroidアプリケーションの開発者にとって喫緊の課題です。本書は増え続けるテスト工数に対する対抗手段として、主に「必要なテストを必要な分だけ設計する方法」と「テストの自動化によってテスト工数を抑制する方法」について解説しています。開発者として知っておくべきテストの技法、コンポーネント別のテストコードの書き方、継続的インテグレーションへの統合方法など、実践的な内容も含まれています。本書がAndroidアプリケーションをテストする全ての人々の一助になれば幸いです。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、すでに修正が施されている場
レーベでもAndroidアプリの開発を行っていまして、最近ではカメラアプリを開発しました。沢山ダウンロードされると「○○で動かない」といったレビューがGoogle Playに入る事も多々あり、逐一各機種でテストする必要があります。 最近まで私たちも実機を事あるごとに購入していたのですが、良いレンタルサービスを発見したので、簡単な動作検証の場合は実機を買わずに済ませるようになりました。 Remote Testkit for Androidについて http://appkitbox.com/testkit Remote Testkit for AndroidとはNTTレゾナントが提供するリモートによるスマートフォン実機検証のためのサービスです。端末のレンタルはチケット制で3チケットで30分利用可能となっています。6チケット(1時間分)945円(税込)で販売しています。 エミュレータではなく、実
AppiumはiOSのテストを自動化するSeleniumを使ったテストツールです。 iOSのテストはユニットテストが基本と思われます。実際の操作については人が細かくテストを行っているのではないでしょうか。その面倒なUIテストを自動化してくれるのがAppiumです。 実行中です。 文字の入力などは自動で行ってくれます。 テストコード。 AppiumはテストコードをJava/Ruby/PHP/node.js/Pythonで書くことができます。さらにSeleniumを使って開発されているのも特徴です。テストは分離しているため、既存のアプリに何らかのSDKを組み込んだりする必要はありません。近く、Androidもサポートされるそうです。 AppiumはMac OSX用のオープンソース・ソフトウェア(Apache License 2.0)です。 MOONGIFTはこう見る iPhoneを自動操作して
Objective-CでUnit Testフレームワーク GHUnitの導入手順 Jan 25th, 2013 Tweet Objecitve-CのUnit Testのフレームワークの中では、GHUnitが安定性の面でオススメなようです。ということで、GHUnitの導入にトライしたらドハマリしたので、今後のために導入の手順を残しておきます。 Objective-Cのテストフレームワーク Objective-Cのテストフレームワークの比較は、iOS 向けTDD/BDDフレームワークやモックフレームワークの現状 - laiso - iPhoneアプリ開発グループ がよくまとまっています。ここでの結論は、SenTestingKitが公式でサポートされているのでXCode/iOSのバージョンアップして使い続けられる点で、オススメとのことでした。 一方、TECH-GYM(株式会社プラスアール)さんの
ScreenRecorderはiOSアプリの操作ログを動画として保存するソフトウェアです。 iPhoneアプリのユーザビリティテストはWebに比べると大変です。しかしその操作ログがあれば改善すべきポイントが見つかりやすそうです。そのためのソフトウェアがScreenRecorderです。 実際に使ってみたデモです。 操作は動画として記録されます。 タップしたところは赤い丸で表示されます。 ScreenRecorderは既存のiOSアプリに仕込んで利用します。操作は逐次動画として保存されます。FPSは設定で変更可能です。さらに自動でファイルに保存し、ローテーションも行います。App Storeへの提出にも対応しています。 ScreenRecorderはiOS用、MIT Licenseのオープンソース・ソフトウェアです。 MOONGIFTはこう見る ユーザビリティテストを行う手法は幾つかあります
こんにちは!うきょーです! iOSアプリのテストのことをそろそろ1年くらい考えていて、1周した感じもするので、 ここら辺で一旦の区切りの意味でもなんとなく考えをまとめてみる。 ちなみにテストというのは主に単体テストにフォーカスした内容です。 こういう系のエントリを書くと、僕はわりと誤解を生みやすい書き方をしてしまうので先に断っておくと、 なんらかのアプリ開発手法や、テスト手法をDisっているわけではないです。 フレームワークがいろいろ登場したりしますが、それらをDisっている訳ではないですし、それぞれ素晴らしいものだと思っています。 同じくそのフレームワークを使っているプロジェクトも登場しますが、それらをDisっている訳でもありません。 もちろん特定個人をDisる内容でもありません。 という感じで、何かをDisってる記事ではないので、ご了承ください。 長めです。結局何がよかったの、っていう
前回までは、単体テストを対象としたテスト実行およびテスト実装について、ツールによる自動化を解説しました。今回は、テスターによるGUI操作を伴うテストの自動化について紹介します。自動化には、キャプチャーリプレイツールと呼ばれるツールを利用します。 キャプチャーリプレイツールとは、「キャプチャー機能」「リプレイ機能」という二つの機能を備えるツールを指します。 ・キャプチャー機能 テスト対象となるシステムへのユーザー操作(キーボード入力、マウス操作など)を記録して、スクリプトとして保存する ・リプレイ機能 記録したスクリプトを用いて、何度も繰り返しテストを実行できる 以前のキャプチャーリプレイツールは、キャプチャー機能によって記録されるスクリプトにテスト対象の座標を利用していました。そのためGUIが少しでも変わると、スクリプトの修正が必要でした。その頃にツールを利用していた方は、今もそのようなイ
東京Node学園祭2012 アドベントカレンダーの9日目です。Node.jsとほとんど関係ないうえに内容がけっこう薄い感じなった気がするんですけど気にせずいこうと思います。 フロントエンドのJavaScriptをテストするとき最近はいつもmochaを使ってるんですが、やはりJenkinsとかtravis-ciを使って自動テストもしたいと思って試してみました。 hokaccha/mocha-phantom-travis-test ここではよくあるjQueryで画像のロールオーバーをするというプラグインを作ってそのライブラリに対してテストを書いています。ソースコードはこんな感じです。 $.fn.rollover = function() { return this.each(function() { var $img = $(this); var src = $img.attr('src');
プログラムの種類によっては、そのまま実行できるものと、実行できるようにするために「ビルド」が必要なものとがあります。Cなどのコンパイルが必要な言語で書かれたプログラムは当然ビルドが必要ですし、コンパイルが不要な言語であっても、インストーラパッケージを作るというビルド作業が必要な場合はあります。 ビルド作業の自動化のためのツールとしてmakeなどがありますが、そこまで本格的な事をやる必要がない場合は、シェルスクリプトで「ビルドスクリプト」を作るのが手軽でおすすめです。この記事では、そのような場合に役立つシェルスクリプトのテクニックを4つご紹介します。 エラーの気付きやすさとデバッグのしやすさを高める メッセージに色を付ける シェル関数をライブラリにする 一時的に作業ディレクトリの中に入る エラーの気付きやすさとデバッグのしやすさを高める はじめに紹介するテクニックは問題が発生した時に気づきや
PhantomJSとJasmineで振る舞い駆動開発なJavaScriptテスト:フレームワークで実践! JavaScriptテスト入門(2)(1/3 ページ) しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載 前回は、JavaScriptテストの基本、今回からフレーワムークを紹介 前回の「JavaScriptテストの基礎知識と使えるフレームワーク6選」では、JavaScriptのテストを取り巻く環境や、JavaScriptのテストに使用できるフレームワークの紹介を行いました。今回からは、前回の記事で紹介されたフレームワークを使用して実際にJavaScriptのテスト環境を構築し、テストを行うまでの流れを解説します。 今回は「PhantomJS」と「Jasmine」を取り上げま
開発ビギナーだけじゃない!インフラエンジニア & マネージャー にも知ってほしいテスト自動化と品質管理慎一 古賀
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
こんにちは、中川です。 今回は「インタラクティブなJavaScriptテストフレームワークTestem 」にて紹介されていた、 JavaScriptのテストランナー「testem」を試してみたいと思います。 ※動作確認は、Mac OS 10.7、Node-v0.8.0 にて行ないました。 ■testem https://github.com/airportyh/testem ■インストール
初めまして。プログラマのショウといいます。 現在、mixiの公式iPhoneアプリを担当しています。 今回は、iPhoneアプリ開発におけるGHUnitを用いた単体テストについて紹介したいと思います。 ★ テストとは 本題に入る前に少しだけ、テストという概念について整理してみましょう。 ソフトウェアを開発する上での「テスト」という言葉は、「コンピュータのプログラムを実行し、正しく動作するかを確認する作業のこと」を指します。 そしてこの「正しく動作するかを確認する方法」として主に以下の2通りがあります。 ・ ホワイトボックステスト ・ ブラックボックステスト ホワイトボックステストとは、「命令網羅」「分岐網羅」「条件網羅」などの方式を用いて、プログラム内部の動作がプログラマの意図通りとなっているかを確認するものとなります。 これに対してブラックボックステストとは、プログラム内部に関係なく、外
このエントリーは「Software Test & Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる/苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG(Software Engineering Process Group)という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く