Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システムの開発をしていれば、開発したものをテストすると思います。 単体テストや結合テストなど、テスト手法はいくつか存在しますが、想定していなかったケースに対してテストを行うことは難しいです。また最後はシステムテスト(実際に動かして、触ってみるテスト)を行うことになると思います。 (テスト手法などについてはこちらを参照) テストを行うには相応の時間がかかり、テストに時間をかけられない場合もあります。また、開発者以外の人がテストを行うことも多くあります。 そして、いくらテストを行っても、バグを全て発見、修正することはできませんし、実際にゲー
負荷ツールとしてGatlingのことを少し前から耳にする機会が増えたので、利用してみることにした。 色々既出だとは思うが、公式のQuickstartに従って試してみたのでメモ。 GUIが必要だったので、今回は手元のMacで実行。 Gatlingとは Java/Scala製の負荷テストツール。 JMaterと似た感じのツールではあるが、 ハイパフォーマンス 見やすいレポートHTML developerフレンドリーなシナリオファイル というのをウリとして謳っている。 たぶん、3項目とも対JMater(重い・レポート見づらい・XMLのシナリオつらい)を意識したメリットだろうなー。 なお、シナリオファイルは。。。 Gatling simulation scripts are written in Scala, but don’t panic! わろた。 というわけで、触ってみる Install J
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
ごあいさつ はじめまして。アライドアーキテクツの石川と申します。 2月に入社してから早くも３ヶ月がたとうとしています。 私は前の職場ではほとんどjavaで開発していたのですが、 アライドに入社してからは主にPHPで開発をしています。 私の回では、その時その時に関心のある技術情報を発信していければ、と思っています。 皆様どうぞよろしくお願いいたします。 今の自分の課題はとにかくUnitテストを書くことなので、 今回はPHPのモッキングフレームワークである「Mockery」について書きたいと思います。 Mockeryって？ padraic / mockery こちらで御座います。 static methodのモック化が出来たり、テスト対象のメソッド内部で生成されるインスタンスをモック化したり、 PHPUnitでやろうとすると一手間かかることをサクっと出来てしまいます。 Let’s インストール
はじめまして、サーバ基盤チームの田中祥平(@xcir)です。 最近入社しまして、チームではいわなちゃんと呼ばれています。よろしくお願いします。 入社してからGREEの配信システムをVarnish Cache（以下Varnish）に置き換える仕事をしていたのですが、少し前に問題なく山を超えました。 そこで今回利用したVarnishの特にテスト機能について紹介しようと思います。 なお、今回の説明に利用するVersionは3.0.3です。 Varnishとは VCLというドメイン固有言語をもち、キャッシュもできる高速リバースプロキシです。 if文が書けるので柔軟に記述しやすいという特徴があります。 たとえば/admin/以下に許可したIP以外からのアクセスは弾くと言ったことは以下のように記述できます。
HDIfes #01「価値のためのテスト」 - UXDx開発xゲーム 情報交換会 #HDIfes 01 「価値のためのテスト」 - Togetter 関連する3つの団体？で言うと一番『DevLOVE』が近いですが、この hcdvalue DevLOVE IGDA日本 のコラボレーション、及び発表内容(告知)を見たところ非常に興味深いセッションが数多く予定されていたので、早速参加申込。そしてこの日参加して来ました。 開催会場は国立情報学研究所/National Institute of Informatics＠神保町。 国立情報学研究所/National Institute of Informatics 建物はめっちゃ高くそびえ立ってたので写真サイズに収める事が出来なかったw 当日日中はとても天気が良かったですね。空も綺麗です。 開始時刻になり、今回のイベント実現に至るまでの経緯等、運営メン
Capybara-Webkit＋Cucumber＋Sinon.JSでJavaScriptのテストはここまで変わる：フレームワークで実践！ JavaScriptテスト入門（5）（1/3 ページ） しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載。今回は、RubyでWebKitをヘッドレス化するフレームワーク、受け入れテストの記述が日本語でできるツール、スタブやモック、スパイが使えるライブラリを組み合わせたテスト方法などを紹介。 Capybara-WebkitとCucumberとSinon.JSを利用したJavaScriptのテスト 本連載の最終回となる今回は、これまでの連載のようなJavaScriptのロジックを単体テストするのではなく、Webブラウザ上の操作と、それによって動作
2013/11/28 新機能および新端末追加のお知らせ 2013年11月28日（木）実施のシステムメンテナンスが終了いたしましたのでご報告いたします。 尚、メンテナンス完了に伴い新規機種・機能を追加いたしました。 下記のとおり 1. Android 4.4に対応 Remote TestKitがAndroid 4.4（KitKat）に対応しました。 あわせてレンタルできる端末にNexus 5を追加いたしました。 ２．新規機能追加 自動キャプチャ ファーストビュー機能 「複数端末同時操作」による画像保存時にページ全画面のキャプチャに加え、端末ディスプレイに最初に表示される画面を同時に保存する機能を追加いたしました。 本機能によりレンタルした端末でWebページの確認をする際に1画面に表示される範囲がひと目で確認できるようになりました。 ３．レンタル端末の新規追加 最新端末の追加 ご要望にお答えし
この記事は賞味期限切れです。（更新から1年が経過しています） JavaScriptユニットテスト一年生の私が、Nettuts+ のチュートリアルで知ったテストツール 「testem」のお陰で大変捗ったので是非お勧めしたく、ここで紹介してみます。 testem ってなに testem via GitHub : airportyh/testem Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests. 要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応して
JavaScriptのユニットテストは2年ほど前にQUnitから入って、最近はもっぱらJasmineを利用していました。近年のJavaScriptテスト関連情報をまとめたいなと思い、改めてQUnit最新Version1.10.0のドキュメントとソースを読んで仕様を把握して資料にまとめてみました。 Qunit1.10.0 from Koji Nakamura サーバーサイドJSを開発する時にQUnitを採用する選択肢は僕の中ではないのですが、ブラウザJSを開発する時にはこのシンプルさと導入のしやすさはやはり利点だなと再認識した次第です。
takada-at 作の インターネット破壊 を Python + Gevent で書きなおした グリーン破壊 を公開しました。 なんで作りなおしたのか インターネット破壊は Ruby + rev 製なのですが、 Ruby のバージョンや gem まわりなどが Ruby に詳しくない人にとっては複雑で、セットアップに数時間かかることがありました。 また、インターネット破壊が使っている rev というライブラリはオワコンらしいです。 さらに、 Rev を使ってイベントドリブンの書き方をしているために複雑で、カスタマイズや デバッグが難しいという問題もありました。 結局、インターネット破壊が期待通りに動かなくて調査していた時に、調査するよりも Gevent で書きなおした方が早い！と思って書き直してしまいました。 パフォーマンス グリーン破壊は内部でコネクションプールを利用しており、 keep
データベースを使った自動テストについて データベースを使った機能テストや単体テストについて要点をまとめておきます。 筆者の経験を強く反映していますので比較的定性的な内容となります事を予めご了承下さい。 テストデータを保守する テストの実行前に投入するテストデータは、凡そcsvファイルやxmlファイル、エクセルファイル等で管理する事になります。 仕様の変更に伴いテーブルの定義を変更する事で、それらのファイルの内容とデータベースの間に不整合が発生します。 テーブル定義の変更とテストデータの保守は常にまとめて作業するべきです。 これは同じ作業者がやるべきという事ではありませんが、ほぼ同時期に行われるべきです。 RDBを使っている場合、ExcelやAccessといったデータベースにODBC接続し易いツールを使うとデータを作り込み易いのですが、 テストデータを長期間に渡って保守する事を考えると、 テ
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
2012年08月03日14:42 カテゴリPHPprogramming Behatでケータイサイトの受け入れテスト はじめまして、株式会社Flesselの田中と申します。 私は長いことケータイサイトを作る仕事に関わってきました。縮小傾向にあるフィーチャーフォンですが、まだまだ現役です。 このエントリーではPHPのストーリーテストツールBehatを利用して、ケータイサイトの受け入れテストを行う方法をご紹介します。 インストール今回は対象となるプロジェクトにcomposerを使ってBehatを組み込む方法をとります。 まずはcomposerをインストールします。curl -s https://getcomposer.org/installer | php※CentOS環境だと証明書の関係で動かないことがあります。 次にcomposerの設定ファイルであるcomposer.jsonをプロジェクト
rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
ここではRubyで記述されたコードに対するテスト方法の概要について説明します。Rubyには、ユニットテストをしやすくするフレームワーク（ライブラリ）が提供されています。通常は、個々のモジュールやメソッドなど小さな単位で十分なユニットテストを行って検証し、結合テストへと進みます。 提供されるフレームワークは、「テスト駆動開発(Test Driven Development:TDD)」や「振舞駆動開発(Behaviour Driven Development:BDD)」という思想がベースになっています。テスト駆動開発とは、プログラム開発手法の一つで、プログラムに必要な各機能について、最初にテストコードを書きそれが失敗することを確認し（テストファースト）、そのテストが成功するように必要最低限の実装を行った後、プログラムの振る舞いを変えないようにコードを洗練（リファクタリング）していく方法です。こ
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
