複数バージョンのPythonでのテスト - 何気に大変
最近 pyroonga というPythonから groonga が操作できるようなものを作り始めたのですが、作るにあたってサポートするPythonのバージョンを2.6、2.7、3.xに決めました。 そこで問題になるのがテストです。複数バージョンでテストしないといけないので、virtualenvあたりを使うんですが、いちいちバージョンを切り替えてテストを走らせるのがめんどくさいです。 で、そのためのツールに tox というものがあります。これを使うと複数バージョンでのテストがコマンド一発で済みます。 前提条件として、テストに使用するバージョンのPythonがシステムにインストールされている必要があります。 まぁ普通のPythonistaならPython2.6、2.7、3.2ぐらいは当然入れていると思いますので問題ないでしょう。 インストール pipまたはeasy_installを使ってpyp
継続的インテグレーションに。iOSを自動操作してテスト·KIF MOONGIFT
KIFはiOSアプリを自動操作するテストフレームワークです。 iOSにおいて継続的インテグレーションを実現するのに使えるのがKIFです。アプリの操作を自動で行って、テストの自動化を推進してくれます。 iOSシミュレータ、実機の双方で動きます。 テストの記述です。タップするラベルを指定しています。 デモ動画です。シミュレータはマウスでは触れていません。 KIFではテストコードをアプリに組み込みます。テスト自体Objective-Cで記述するようになっています。なお、ドキュメントにないAPIを使っていますので、アプリ申請の際に注意が必要です（KIFでは使い方を細かく書いています）。なおKIFはモバイル課金プラットフォームで知られるSquareを開発している企業のソフトウェアになります。 KIFはObjective-C製、Apache License 2.0のオープンソース・ソフトウェアです。
mixiエンジニアがおくるソーシャルアプリ開発実践講座：第3回 自動テストと継続的インテグレーションを既存プロジェクトへ導入しよう｜gihyo.jp … 技術評論社
はじめに はじめまして。（株）ミクシィの加藤和良です。2008年度に入社し、2011年1月からはシステム本部 技術部に所属しています。技術部は、日記やコミュニティといった特定のサービスに紐づかない、mixi全体を裏から支える部署です。「支える」ための方法は、実際のサービスの一部として動作する共通基盤から、開発効率を上げるために社内で動作しているものまで、多岐にわたります。 mixiでは、ここ数年で自動テストの導入が急速に進みました。図1は、mixiのソースツリーにおけるコードと、そのテストコードの毎月1日のバイト数をグラフにしたものです。2008年の頭には少なかったテストが急速に増え、今年の5月にはコード量をも追い越しているのがわかります。 携帯電話向けmixiである「mixiモバイル」の開始が2004年、mixiニュースが2006年ですから、2008年当時のmixiも、それなりに大き
Stylus/mochaがやってるGlobal leakテストとNode.js Debugger - teppeis blog
先日、Stylusのコードをいじってたらグローバルリークがあったので、修正してPullリクエストしました。（TJが即マージしてリリース済みだよ！） リークを見つけたのは、StylusのテストコードにGlobalオブジェクト汚染を検出するテストがあってそれをたまたま走らせただけなのですが、このテストがシンプルかつ効果的でいいなと思いました。 https://github.com/LearnBoost/stylus/blob/master/test/run.js // Testの初期化時にデフォルトのグローバルオブジェクトのキーを保存。 var globals = Object.keys(global); ... // Testが終わったらグローバルオブジェクトの差分をチェック function done() { Object.keys(global).forEach(function(nam
ソフトウェアテストを勉強しはじめて10ヵ月でやったこと - うさぎ組
WACATE 2011 夏に誘われたのがキッカケでソフトウェアテストを勉強しはじめて10ヵ月くらいがたちました。 先日、わんくま名古屋でソフトウェアテストの勉強法についてLTしたのですが、みなさんにいろいろ聞かれたのでここにまとめておこうと思います。 本当は1年の区切りで書こうと思ったけど、まぁいいでしょう。 追記ここから わんくまで発表したLT資料はこちらです うさみみのソフトウェアテスト勉強法 View more presentations from Kyon Mm 追記ここまで こういうのを書くときに時系列で書くべきか、コツを書くべきか悩みますね。 でも、みんなが知りたいのは僕の歴史じゃなくってコツだと思うので後者で書きます。前者はTwitterとか勉強会とかお食事とかお茶でもしているときに聞いてみてください。 以下では多くの書籍を紹介していますが、僕がこの10ヵ月で読んだ本。ってい
iOSと非同期テストな話 - yaakaito::Blog
Objective-C, Test, iPad, iPhone非同期テストを書くにはdispatch_semaphoreを使う方法と、自分でループまわして管理する方法の2つがありますね。違い、というか、特徴としてはdispatch_semaphore使うとかなり綺麗にテストコードが記述できますが、処理内でメインスレッドになってしまうと、そのまま二度と帰ってこないみたいです。自分で管理する場合はこれの逆、メインスレッドに行ってもテストできるけど、テストはちょっと冗長になる感じ。dispatch_semaphore dispatch_semaphore_t semaphore = dispatch_semaphore_create(0); dispatch_queue_t global_queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIOR
逆引きソフトウェアテスト関連技術まとめ - >& STDOUT
「Software Test ＆ Quality Advent Calendar 2011」の8日目。アドベントカレンダーということで、普段と少しトーンを変えてソフトウェアテストにあまり造詣のない方へ向けて何か役に立つ記事を考えてみました。先の記事でも述べたとおり、ソフトウェアテストの関連技術を表す用語はそれが何に使えて、何に役立つのか、門外漢にはとってもわかり難いので、そちらを軸にした紹介があると便利かもしれないということで、関連技術を目的別に整理し、参考になる記事や資料にリンクする形でお届けします。 テストの戦略を定めたい ソフトウェアテストプロジェクトの最上流工程と考えられているテスト分析の方法論です。プロダクト、プロジェクトに対してそれぞれ独自の方式で戦略を検討します。テスト計画と一部被る部分もありますが、プロジェクトの予算やスケジュールをひとまずおいて技術的な視点から本当に必要な
私が考えるTDD 〜TDDは天才にしかできないのか〜 - What is it, naokirin?
TDD Advent Calendarに参加していないのに書くのも微妙なのですが、今回はTDDについてです。 TDD Advent Calendarの記事はかなりハイスペックな内容になっています。今回の私の記事はそれらには到底及ばないと思いますが、私の考えるTDDを書いて行こうと思います。 そもそもTDDとは 『TDDとはアジャイル方法論のエクストリーム・プログラミング（XP）のプラクティスの1つです。』 と言う話を聞きますがXPについてWebで調べてみると、「テスト駆動開発(TDD)」と書かれている場合と、「テストファースト」としか書かれていない場合の2種類の場合が存在します。 おそらく元々、「(Unit) Test First」と「Refactor」という2つのプラクティスがXPには存在していて、それがTDDというXP互換なプラクティスになって言ったのではないかと思います。 さらにTD
右手に感情、左手に数値 - カバレッジを味方にしよう - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar 2011 の 7 日目の参加エントリです。前日は @sue445 さんの実録！TDD風景でした。 しかし TDD Advent Calendar 2011 は、名エントリが多いですね……ハードルが上がり続けていて胃に穴があきそうです。私の言いたいことの多くは、既に @bleis さんのTDD の基礎体力と、TDD に対する想いや、 @shuji_w6e さんのTDDを学ぶべき10の理由で語られています。二つとも素晴らしいエントリなので、ぜひ読んでみてください。 そろそろカバレッジについて一言いっておくか さて、今日書くのは、カバレッジについてです。 @bleis さんのエントリに以下のような記述があります。 もう一度言いますが、TDD のテストは Developer Testing であって、品質保証を目的としたテストではありません
TEFに燃料投げたら秋山さんが答えてくれた
TEFの自己紹介メールに対してTwitter上お返事をくださいました。 近いうちにそれぞれ(4つの論点)について自分からMLに投稿するつもりです。 ちなみに4つの論点は次の通り。 「単体テスト/結合テストなんて存在しない」 「テストなんてないほうがいい」 続きを読む
PHP5.4時代のprivateメソッドテスト手法 #php5_4
PHP5.4 Advent Calendar 2011の7日目です。昨日は@madapajaさんの「PHP5.4+ で開発が行われている BEAR.Sunday フレームワークを動かしてみる」でした。 さてさて皆さん、ユニットテストしてますか？ PHPもテストのライブラリが充実してきており、カバレッジ100%に情熱を燃やしている方も多いことでしょう。 ユニットテストで困るのが、private/protectedメソッドです。外から呼べないので、普通の方法ではテストできません。(protectedは適当なダミーのサブクラスを作ってそこからテストできますが、ちょっと面倒です。) まあ当然です。外から呼べないようにprivateにしているので、簡単に呼べたら逆に困るわけです。しかしながら、privateメソッドも外から呼んでテストできた方が開発ははかどるでしょう。この記事ではPHPでprivat
Django テストの高速化 - OZACC.blog
Djangoのテストフレームワークは便利なんだけど、テスト実行時に毎回行われるDBテーブルの生成・削除プロセスやFixtureデータのインポート処理に決行時間が掛かってて、ストレスの種になっていた。 テスト中にコンソールを眺めていて特に遅いと感じられるのがcreate table文の実行。モデルの数だけこれが実行されるので、アプリケーションの規模が大きくなるにつれテスト時間も増加してしまう。 DBアクセスが高速化されればいいんだけど、今回使用しているDBのPostgreSQLにはメモリテーブルみたいな仕組みがないため、どうしてもディスクアクセスが発生してしまう。が、ローカル環境では開発用途にしか使ってないのでRAMディスク上にテーブルスペースを作って、そこにテスト用のDBが生成されるようにすればDBアクセスが高速化されるはず。と思い立って、次のようにこれを実現してみた。 まず導入したのが前
JMockitは理想的なモックフレームワーク - かとじゅんの技術日誌
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
JUnit のセカイ #JJUG - やさしいデスマーチ
このエントリーは、@cero-tさんのエントリーの次で、Java Advent Calendar 2011の6番目のエントリーです。自分自身の今年のメインテーマがTDD（テスト駆動開発）と言う事もあり、関連エントリーとしてJUnitについて書きたいかと思います。今更JUnit？と思われた方も普段からJUnitを使っていあなたも気軽にお読みください。尚、色々な話題を駆け足で紹介するので、どれも簡単な紹介程度になってしまいますが、ご了承願います。 JUnit4 スタイル JUnitがアノテーションに対応し結構な月日が流れましたが、古いコーディング規約のままでテストコードを書いていませんか？JUnit4では、アノテーションとアサーションを使ったテストコードを書くことが基本スタイルです。かつては、TestCaseのサブクラスを作り、testではじまるメソッドを定義していましたが、今は Testアノ
GitHub - mochajs/mocha: ☕️ simple, flexible, fun javascript test framework for node.js & the browser
☕️ Simple, flexible, fun JavaScript test framework for Node.js & The Browser ☕️ Links Documentation Release Notes / History / Changes Code of Conduct Contributing Development Discord (ask questions here!) Issue Tracker Backers Become a backer and show your support to our open source project on our site. Sponsors Does your company use Mocha? Ask your manager or marketing team if your company would
Androidアプリ開発でテストを始めるための基礎知識
Androidアプリのテストに関する課題 Android端末の普及は世界規模で増加の一途をたどっています。2011年秋冬モデルが発表され、発売予定のものを含むと日本で発売中のAndroidの携帯端末は100機種に迫ろうとしています。読者の皆さんの周囲を見渡しても、電車や街角でAndroidを採用したスマートフォンなど携帯端末を使用する人をよく見かけるのではないでしょうか。 そして、スマートフォンに留まらずタブレットやミュージックプレイヤー、電子ブックリーダー、POSレジ、テレビなど、さまざまなデバイスがAndroidを搭載し始めています。Androidの採用が増えるにつれ、Androidアプリの種類が増えるので、アプリの開発案件も増えることになります。実際、本稿を読んでいる開発者の方の中にも、すでにAndroidアプリの開発に取り組んでいる方も多いのではないでしょうか。 筆者も普段の業務の
Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み
Uncategories Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み こんにちは。QAの井上です。 今回は現在QAチームで行っている自動テストに関する課題、それに対する取り組みについて紹介します。 まだまだ詰めが甘いところがあると思うで、フィードバックいただけるとうれしいです。 早速ですが、QAチームではCIツールにJenkinsを使用していて、約8割がSeleniumによるテストケースでできています。 テストケースの作成から実行まではざっくりですが、以下のようになっています。 - テストケースはFirefoxのIDEを使用して作成 - 作成したテストケースはSVNに保存 - 毎日夜中に最新のソースコードに対してテストを実施 - テストの実施は、Jenkinsのseleniumhqプラグインを使用して、複数台のクライアント(Windows)上でSelen
Googleが開発、JavaScriptカバレッジツール登場 | エンタープライズ | マイコミジャーナル
SCRIPTCOVER is a Chrome extension for Javascript coverage analysis. Googleは10月26日(米国時間)、JavaScriptカバレッジツール「ScriptCover」をオープンソースソフトウェアとして公開した。ScriptCoverはChromeエクステンションとして実装されたJavaScriptカバレッジツール。Apacheライセンス2.0のもとで公開されている。 ScriptCoverを使うことで、リアルタイムにWebページを分析することが可能。JavaScript行単位での分析が可能となっている。複雑なコードの解析やデバッグ、試験の実施などに有効とされている。現在のところエクステンション単体では提供されておらず、使用するにはドキュメントに従って自らビルドして開発版を用意する必要がある。利用するツールなども含めてあ
Android開発で泣かないための「テスト」の重要性（1/2） - ＠IT
8月6日、日本Androidの会テスト部（以下、テスト部）主催によるイベント「第1回Androidテスト祭り」が都内で開催された。テスト部は、Androidプラットフォームでの開発において、特にソフトウェア検証テストに関する情報共有や問題解決を目的とした組織だ。2010年9月に発足し、イベント開催時点では276名のメンバーがいるという。 今回のイベントは、その自由度の高さや多様性ゆえに課題を抱えるAndroidアプリ開発のテストについて、開発者同士やコミュニティでの情報交換を目的に開催された。テスト部では、すでに日本Androidの会の総合イベント「Android Bazaar and Conference」での講演をはじめ、さまざまな活動を行っているが、単独イベントは今回が初だ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストをプロダクトコードと別言語で書くことに関するTL
