You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
XCTestでAPIクライアントのテストを書くときに便利だったテストケースクラスの実装をシェアします。 その前に、そのテストケースクラスを使った時にどうなるかbefore/afterで比較しましょう。 beforeは元の自分のプロジェクトで使われた環境で書かれてたテスト風のサンプルコードで、afterが便利TestCaseクラスを利用したコードです。 before 基本的にはOHHTTPStubsを使ってHTTPのリクエストをstubして、TRVSMonitorを使って非同期処理の待ち状態を作ってました。 毎回stubの定義を書いたりmonitorオブジェクトなど作成したり、テスト書くのに全然集中できないし、読んでても余計なコード大石イライラしますね。 #import <XCTest/XCTest.h> #import <OHHTTPStubs/OHHTTPStubs.h> #import
2. なにを発表するの？ 最近、Selenium2 + Ruby + RSpec でブラウザ テストの自動化に取り組んでます 「ブラウザテスト」？ ここでは「テスターがブラウザを操作して眼で結果 を確認する行為」という意味で使います 具体的にどんなことをやってるのかを紹介し ます。 (主にテストケースの構成について話します) 4. Slenium2って何？ OSSのブラウザテストツール プログラム言語でテストスクリプトを書いて使う 何ができるの？ 手動テストの代替 手動テストで行うのと同様に、実際にWebブラウザを起 動して操作できる ボタン押したり、文字列を入力したり取得したりetc 特徴・メリット ブラウザテストツールのデファクトスタンダード 情報＆使用経験者の数が多い 開発が活発 幅広いOS/ブラウザ/言語に対応
先週初めてGo言語を触る機会があったので、テストの書き方を調べた。 要約すると、標準ライブラリのtestingが好きになれず他に調べても気に入ったものが見付からなかったので自分でつくった。 testing Go言語にはtestingという標準ライブラリが用意されていて、 「go test」コマンドを実行すると「*_test.go」という名前のテスト用ファイルがそれぞれ実行される。 具体的には、そのファイル内で定義されたTest*という名前のテスト用関数がそれぞれ実行されるようになっている。 公式サイトの例ではこういうコードが紹介されていた。 type doubleTest struct { in, out int } var doubleTests = []doubleTest{ doubleTest{1, 2}, doubleTest{2, 4}, doubleTest{-5, -10}
Webシステムではメールをユーザー送り、メール内のURLクリックで処理を行うようなケースも間々あります。そんなプログラムの受け入れテスト、End-to-Endテストを行うには Request Specs や Steak に Email Spec で簡単に書けます。 Email Spec は Rails の ActionMailer のメール送信部分をフックし送信されたメール内容をライブラリー内に保持し、RSpecでテストを書けるようにするライブラリーです。 RSpecベースなので Request Specs や Steakだけでなく Cucumber でも使えます。 インストール Gemfile に gem 'email_spec' を追加し bundle install を実行。 spec_helper.rb に以下を追加 require 'action_mailer' require
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
GHUnitは，Mac OSX/iOSのかなり高機能なテストフレームワークである．これには，以下の様な特徴がある ・非同期通信のテストが容易にできる ・ iPhone実機・シミュレータで動作確認ができる ただ，デメリットの一つとして，GHUnitは通常シミュレータ(又は実機)上で立ち上げてボタンを押さなければ，テストが実行されない．というわけで，保存された瞬間にコマンドライン上でテストの結果を表示させたいと思います． GHUnitを導入する GHUnitの導入です．CocoaPadsを使うと導入が非常に楽です．使うことを非常におすすめします． CocoaPods を導入して GHUnit と OCMock を使って単体テストを書く｜クラスメソッド株式会社 開発ブログ を参照に，GHUnitを導入することができます． コマンドライン上で実行する Running from the Comman
Test::More で teardown/setup http://blog.ainam.me/2013/04/09/test-more-perl-testing/ http://lestrrat.ldblog.jp/archives/26535307.html package t::Util; use parent qw(Exporter); our @EXPORT = qw(lovetest $MOCK); use Test::More; sub lovetest { # setup local $MOCK = ...; # teardown は guard object で。 goto \&Test::More::subtest; } そしてテストケースはこう。 lovetest 'foo' => sub { ... $MOCK->do_something; }; というのがここ数
Test::Pretty supports prove! Test::Pretty now supports prove command! You can use it as following command line: % prove -PPretty t/ Output is here: Yes. It's not modified. But you adds '-v' option to prove, then you get cool output. % prove -PPretty -v t/ If you are testing only one file, output is more optimized: % prove -PPretty t/02_op.t Result code is here: That's all. Enjoy testing!
先日から社内で、今年度の新卒向けにテストの講師やってくださいと仰せつかり、 別に誰かに強制されたわけではないのですが、去年までの講義資料だとチュートリアル的な感じで終始してしまったいたので、 資料をスクラッチで書き始めてしまい、しばらく苦しみが続きましたが、そこそこ体系的に知識突っ込めたような気がします。 Perl Advent Calendar 2011 Test Trackとか,tokuhiromさんのPerl テスティングハンドブック読んだりしましたし、 Perlだけじゃなくてユニットテスト全般の話をしたかったので、Junit実践入門読んだり、レガシーコード改善ガイドとか、 The RSpec Book読んだりしました。 そんな中、Perlでユニットテスト書くのってどうするのが最強なんだ？って言う疑問がすごいあって、 Test::Classが最強なんじゃないかと思ったりしたのですが、
さっき nekokak さんと xaicron さんにそそのかされて Test::Mock::Guard ってモジュールを書いてみました。 そもそも Perl には Test::MockObject と言う汎用の Mock モジュールがあるんですけど、あれこれ余計な機能がたくさんついてたり Mock 化すると多分元に戻せないと言うのがあってもっとシンプルな奴がほしいなと思って作ってみた次第です。SYSNOPSIS のコピペですけど、 use Test::More; use Test::Mock::Guard qw(mock_guard); package Some::Class; sub new { bless {} => shift } sub foo { "foo" } sub bar { 1; } package main; { ### このスコープでは Mock 化されてる my
はじめに 忘年会シーズンまっただ中で皆さんは毎日お酒を飲んでいることでしょうが、僕は友達が少ないため忘年会とか全然無いので財布はまだホットな状態なんですが、なぜ僕の妹は小鳩ちゃんじゃないんだっていうかそもそも妹いないしもう死ぬって感じの xaicron です。こんにちは。 そろそろ prove について簡単に説明しときますよっと。 prove のよく使うオプション prove にはいっぱいオプションがあるんですが、ここではよく使いそうなやつをピックアップして紹介しちゃいますよ！ -v, --verbose # いっぱい出力する -l, --lib # lib を INC についかする perl -Ilib 相当 -b, --blib # blib/lib とか blib/arch を INC につかする -Mblib 相当 -c, --color # カラフルになる！ MSWin32 だと
YAPCで話すのは、2011年以来2度目です。そろそろおなじみとなってきたテストの話です。 Integration Testing Practice using Perl from Masaki Nakagawa 今回はいつもの若干スピリチュアル＋概要な流れに加えて、少しだけケーススタディを交えてテストの実例を紹介しました。サンプルコードもう少し書こうと思ってたんですが、前日余りにも眠くて力尽きてしまいました。本番は40分トーク枠で39分くらいかかったので、サンプル入ってたら無理だったなと勝手に自己完結しています。 1日目は資料書いていたのであまり話も聞けませんでしたが、2日目は朝一でトークだったので、それが終わってからは、他のセッション聞いたり、HUBで座談会の後編やったり、基調講演で緑の光る棒振ったりと、なんやかんやで楽しんでいました。 スタッフのみなさん、本当にお疲れさまでした。そし
7/24 (水) に Testing Casual Talks #1 を開催しました。 名前からわかるかもしれませんが、個人的には MySQL Casual Talks を大いに参考にさせてもらったのですが、ああいうノリで気軽にイベントやったっていいじゃない、という感じです。 現在テストエンジニアとして仕事しているわけですが、そうなると例えば他社さんではどんなことをされているのか、あるいは他の方がどんなアプローチをとっているのか、など気になってくるわけです。そこで交流できるイベントができればなーと考えていて、この度開催に至ったというところです。 というわけで、自分は "Software Engineer in Test at DeNA" というタイトルで発表しました。スライドは以下です。 Software Engineer in Test at DeNA from Masaki Nakag
QUnit とTAP を用いた JavaScript のテスト環境構築の話です。 前提として、QUnit でテストを実行出来る環境が構築できていることとします。 QUnit の実行のやり方等は以下のエントリが詳しくてマジ最高なので、ご参照下さい。 QUnitの基本的な使い方 - Block Rockin’ Codes さて、今回例として扱うディレクトリの構成としてはこんな感じです。 . ├── lib │ ├── qunit.css │ └── qunit.js ├── main.js ├── test.html └── test.js main.js: テストの対象となる JavaScript ファイル test.html: テストの結果を表示するための html ファイル test.js: JavaScript のテストコード lib以下: QUnit 本体 この段階でtest.htm
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
