class TwitterClient { public function tweet($message) { return true; } } $hoge = new TwitterClient(); $hoge->tweet('大心なう'); // trueが返る class ClientContainerTest extends PHPUnit_Framework_TestCase { public function test_モックを書いてみる() { $hoge = $this->getMock('TwitterClient', array('tweet')); $hoge->expects($this->any()) ->method('tweet') ->will($this->returnValue(true)); $hoge->tweet('大心なう'); // true
デバッグしやすいassert_equalの書き方とデバッグしにくいassert_equalの書き方があるのは知っていますか？1 デバッグしやすいassert_equalの書き方を2パターン紹介します。 まとめたassert_equal まず、1つ目のよくみるデバッグしにくいassert_equalの書き方です。 def test_parse assert_equal(29, parse_integer("29")) # (1) assert_equal(29, parse_integer("+29")) # (2) assert_equal(-29, parse_integer("-29")) # (3) end これがデバッグしにくいのは、(1)が失敗したら(2)、(3)が実行されないからです。すべてのassert_equalが実行されて、どのassert_equalが失敗したかを確認す
また、テストを書く。 最近 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/ ヘルメットを付けずに自転車を漕ぐのはとても快適ですね。でも、ふとしたある日に取り返しの
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
こんにちは！元気にiOS開発でテストを書いていますか？？？まだ書いていない人は、さっさと書きましょうね！！！今回はObjective-Cでテスト書く上でのモックオブジェクトとかのお話です。 OCMockというライブラリ使うのでCocoaPodsはインストールしましょう！ 先にOCMockについて少しだけ 実際にOCMock使ってどうこうはちょっと先の話になってしまいますが、簡単にOCMockの説明だけしておきます。 Mulle kybernetiK -- OCMock Objective-Cのモック系のライブラリにはほかにもOCMockitoやExpectaなどがありますが、個人的にはOCMockが好きです。 有名なBDDフレームワークのCedarなんかでも、OCMock使うといいよ〜と言ってるので、そういう意味でもおすすめですね。 で、OCMockは何するの〜という話なのですが
はじめまして、品質管理部門の柿崎です。 最近、Skyrim にハマってしまい、人生一回休みになりかけています。 季節は春ということで、新社会人になられる方も多いと存じます。 新社会人が会社勤めをするようになって、初めて書くビジネス文書といえば...... そうですね！「バグレポート」ですね。 今回はバグレポートの基本について書きたいと思います。 近年、開発現場ではバグトラッキングシステムが定着し、ドッグフーディングのような社内テストを行う現場も増え、テスト担当者以外の方でもバグレポートを提出する機会が増えています。そして前衛的なバグレポートによって、プログラマ達が理不尽かつ不可解なバグ地獄に叩き込まれる機会も増えています。 バグレポートは諸刃の剣です。 良いバグレポートはアプリケーションの問題を速やかに解決まで導きますが、反対にダメなレポートは現場に混乱をもたらします。 良いバグレポートを
pythonのモックとしてminimockというライブラリがある。 日本語のドキュメント・ブログが見当たらないので使い方をここに書いておく。 minimockを構成するモジュール mock関数 -- モックを当てる。 restore関数 -- 当てたモックを解除する。 Mockクラス -- mockより詳細にモックを当てるために使うオブジェクト。 mock関数とrestore関数でモックを当てる・解除するというのはわかりやすい。 しかし、複雑なケースではMockオブジェクトを使う必要があるのでここで説明する。 あと、minimockを使う上ではまりやすい点を書く。 基本的な使い方 minimockの基本は モックに差し替えるモジュールをインポートする。 mock関数を呼ぶ。或いはMockインスタンスを代入する。 使い終わったらrestoreで戻す。 である。 例えば、以下のphilosop
Web サービスをリリースするにあたり避けては通れない（避けて通ってはいけない）性能・負荷テスト工程。 ウォーターフォールやアジャイルなど開発手法は様々ありますが、現実問題、概ね開発工程が遅延する傾向があります。なんとか単体テスト・結合テスト・システムテストはやりきるものの、力尽きて性能・負荷テストを実施せずにリリース・・・なんてことはありませんでしょうか？ そんな場合に限って、リリース直後に高負荷でサービスダウン・・・なんてことになりがちです。 そうならないために性能・負荷テストは必ず実施すべき項目です。ツールとして JMeter がメジャーですがシナリオ作ったり、使い方覚えたりと、正直面倒です。でも apache bench なら使ったことあるし知ってる！という方も多いことでしょう。そこで僕が "簡易的" に性能・負荷テストで使っている方法を公開します。 ab を用いた簡易的な性能・負
注: 長いです。 スクリプト言語でのxUnit実装を使ったことがある方なら、テストを定義するだけでテストが実行されることが当たり前ではないでしょうか。c2.comのWikiによると、これはTest Collectorというそうです。定義したテストを自動的に集めてくる機能のことです。 一般的にTest Collectorの機能は言語が提供するリフレクション機能やメタプログラミング機能を使って実現されます。 例えば、Rubyのtest-unit 2.xでは、リフレクションを使う方法とメタプログラミングを使う方法の両方をサポートしています。リフレクションを使う方法ではObjectSpace.each_object(Class)ですべてのクラスを取得し、その中のTest::Unit::TestCaseのサブクラスを集めます。メタプログラミングを使う方法ではTest::Unit::TestCase.
ネットワークが小規模で、ユーザのほとんどが主にインターネット上のサービスを利用している場合は、名前ではなくIPアドレスの数値を各ノードに割り当てておけばよい。しかし、ネットワークが拡大して組織内のサービス（Wiki、メールサーバ、メディアサーバなど）がオンライン化されると、個々のアドレス値をいちいち覚えきれなくなってくる。解決策の1つが、dnsmasqを使ってドメインネームサーバ（DNS：Domain Name Server）と動的ホスト構成プロトコル（DHCP：Dynamic Host Configuration Protocol）を実装することだ。そうすれば、外部DNSアドレスをキャッシュしてパフォーマンスの向上が図れるほか、ネットワークのすべてのメンバへのIPアドレスの動的割り当てや、あらゆる管理の一元化が可能になる。本記事ではその方法を紹介しよう。 SOHO（個人および小規模事業者
はじめに この資料は「PHPでTDD&CIワークショップ」 http://atnd.org/events/16626 で @yamashiro が発表するための資料だよ。 ワークショップ参加者じゃなくても記事読むだけで完結するようには書いてあるよ。 概要としては、Jenkins を使って PHP のウンコレガシーなコードをいかに綺麗にして行くかということを説明する。 自画自賛だけど PHPMD とか PHPCPD の使い方の説明の資料としてもそこそこイケてる資料になってると思いました。まる。 この記事に書かれてることは、割とTemplate for Jenkins Jobs for PHP Projectsとかぶってるけど、プラグインを絞ってあるのと、一個一個のプラグインについて解説、また実際にエラーが起きたときにどうすればいいのか書くよ。 Java と Jenkins のインストールとJ
継続的インテグレーション 原題: Continuous Integration Martin Fowler Chief Scientist, ThoughtWorks Matthew Foemmel ThoughtWorks 「確実なビルドを行う」 -- これはどんなソフトウェア開発プロセスであれ重要なことだ。そのわりには、このことがきちんとされていないことに驚かされる。本論文では、Matt が ThoughtWorks 社でのある大規模プロジェクトにおいて採用したプロセスを紹介する。このプロセスは全社的な広がりを見せつつある。テスト部分も含めて「全てが自動化された」「再現可能な」ビルドを、「日に何度も」行うことに力点がおかれている。このプロセスを用いれば、開発者はインテグレーションを毎日行うことになるので、インテグレーションに伴う問題を減らすことができる。 継続的インテグレーションの恩恵
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 （写真はゆうすけべーさんです） この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由
まだC, C++がないようなので書いてみた。主にLinux(DebianとかUbuntu)での環境構築について。 コンパイラ まずはapt-getでコンパイラをインストールする。UbuntuやDebianなら以下のコマンドでgccやg++および標準ライブラリ等がインストールされる。 $ sudo apt-get install build-essential デバッグツール デバッガおよびデバッグツールは少なくとも以下の三つは入れる。(あとltraceも欲しいかな？) GDB 言わずと知れたGNUのデバッガ Valgrind メモリリークや不正メモリアクセスの検出 strace システムコールのトレース $ sudo apt-get install gdb valgrind strace ビルドツール C, C++のビルドツールといえばまずmakeが浮かぶけど、最近ではSConsやCMak
Selenium(Selenium Core, Selenium IDE, Selenium RC など)でテストケースを書く場合、かゆいところに手を届かせたい時に是非とも利用したいのがJavaScriptです。 しかし、まだまだその情報が気軽に手に入らないのが残念なところ。 「ないなら書いてしまえ！」ということでSeleniumでJavaScriptを利用したい場合に使える方法をまとめてみることにしました。 逆引き辞典にしたいのかリファレンスにしたいのかわけがわからんカテゴライズになっていますが、少しづつ増やしていくので気長にお待ちください。 使用バージョンはSelenium 1.0です。 目次 JavaScript基本編 Selenium空間とページ空間の違いによるJavaScriptの使い分け JavaScriptによるDOM指定でエレメント(要素)を特定する 各種コマンドの入力欄に
2. プロフィール上野 宣（うえの・せん）京都市生まれ、幼少期は実家がパソコンショップ、高専でロボコンに熱中し、豊橋技科大でインターネットにハマり、奈良先端科学技術大学院大学にて山口英教授の下で情報セキュリティを専攻EC開発ベンチャー企業で創業メンバー、東証マザーズ上場などを経験を経て、2006年6月に株式会社トライコーダを設立株式会社トライコーダ 代表取締役情報セキュリティ教育ネットワークシステム／Webアプリケーション脆弱性診断http://www.tricorder.jp/ 独立行政法人情報処理推進機構(IPA)セキュリティセンター研究員セキュリティ＆プログラミングキャンプ講師情報セキュリティ専門誌 ScanNetSecurity編集長Copyright©2010 Tricorder Co.Ltd. All rights reserved.2sen_u 3. 著書、連載など今夜わかる
はじめに 今回は、Silverlightで単体テストを行うためのテスティングフレームワークとその使い方を紹介します。テスティングフレームワークとはjUnitやNUnitなどに代表されるテストプログラムを書くためのフレームワークです。前編の今回は、導入と環境の構築、そして簡単なAPIのテストを説明します。 Silverlightのテスティングフレームワーク .NETでのテスティングフレームワークはオープンソースで開発されているNUnitやVisual Studio 2008以上のエディションで提供されている単体テスト機能がよく利用されています。Silverlightのテスティングフレームワークはこの連載の第4回でも少しふれましたが、公開されているコントロールのソースコードの中にアセンブリの形で配置されています。コントロールのソースコードは以下のリンクよりダウンロードできます。 http://
WebDriverとは WebDriverはWebブラウザを操作するためのJavaライブラリだ。WebアプリケーションのUIテストツールとして使用することが想定されており、JavaScriptを多用しリッチなUIを提供するアプリケーションのテストに効果を発揮する。 サポートするブラウザはFirefox、Safari(MacOS Xのみ)、Internet Explorer(Windowsのみ)となっている。また、実際のブラウザは使わずHtmlUnitを使用することも可能だ。この場合、Rhino(Javaで実装されたJavaScriptエンジン)を使用してブラウザ上で動作するJavaScriptの動作もエミュレートすることもできる。また、試験的にiPhone用のドライバの実装も進められているようだ。 同種のテストツールとしてはすでにSeleniumなどがあり、多くのユーザに利用されている。し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く