RSpec をやめて Test::Unit に戻る - tmtms のメモ
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
Test::Nginxでnginxモジュールのテストを自動化する - Qiita
use lib 'lib'; use Test::Nginx::Socket; #repeat_each(2); plan tests => repeat_each() * 2 * blocks(); run_tests(); __DATA__ === TEST 1: list --- http_config upstream backends { zone zone_for_backends 128k; server 127.0.0.1:6001; server 127.0.0.1:6002; server 127.0.0.1:6003; } --- config location /dynamic { dynamic_upstream; } --- request GET /dynamic?upstream=zone_for_backends --- response_body 127
Ruby標準のテスティングフレームワークで手軽にテストコードを書く方法 - Qiita
はじめに 僕が一番使い慣れているテスティングフレームワークはRSpecです。 普段の業務でも大半はRSpecでテストコードを書いています。 しかし、ごくごく簡単なRubyのコードを書く場合は「わざわざRSpecを書くのは大げさかな」と思うことがあります。 簡単なコードであれば、テストコードも簡単なものになるのでassert_equalが使えれば十分だったりします。 というわけで今回の記事ではgemを使わず、Ruby標準のテスティングフレームワークでテストコードを書く方法をまとめてみます。 やりたいこと 「素のRuby」でぱぱっとシンプルなテストを書きたい（assert_equalだけで十分なケースを想定） gemのインストールはしたくない、他の人にもさせたくない Ruby 2.0以降ならどのRubyでも動いてほしい つまり、 「いつでもどこでも動くテストコードを書きたい」 というのが今回の
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
Go言語でテストしやすいコマンドラインツールをつくる
本記事はGo Advent Calendar 2014の18日目の記事です． Go言語は，クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い．自分もGo言語でいくつかのコマンドラインツールを作成してきた．例えば，GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている． コマンドラインツールをつくるときもテストは重要である．Go言語では標準テストパッケージだけで十分なテストを書くことができる．しかし，コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する．そのテスト，例えばある引数を受けたらこの出力を返し，この終了ステータスで終了するといったテストは，ちゃんとした手法が確立されているわけではなく，迷うことが多い（少なくとも自分は結構悩んだ）． 本記事では，いくつかのOSSツール（得に
h2spec で HTTP/2 サーバーをテストする
Dec 05, 2014 これは HTTP2 Advent Calendar の5日目の記事です。 先日、HTTP/2 の16番目のドラフトが公開され、いよいよ HTTP/2 の仕様策定も終わりが見えてきました。仕様の策定が進むに伴い、各種言語で実装されたサーバーやクライアントも増えています。自分も Node.js を使って実験用の HTTP/2 サーバーである「Sasazka」を実装したりしているのですが、HTTP/2 を実装する上でなかなか大変になるのが、フレームやストリーム、HPACK の圧縮コンテキストに関連する処理や、それに伴って発生するエラーの処理です。 HTTP/2 のドラフトには、各種フレームやストリームの処理の仕組みとそれに関連するエラーの処理が細かく記載されていますが、仕様そのものは HTTP/1.x よりが複雑になっているため、全てを実装して、それをテストのはなかなか
Testing Techniques
Testing Techniques Google I/O 2014 Andrew Gerrand Video This talk was presented at golang-syd in July 2014. Watch the talk on YouTube 2 The basics 3 Testing Go code Go has a built-in testing framework. It is provided by the testing package and the go test command. Here is a complete test file that tests the strings.Index function: package strings_test import ( "strings" "testing" ) func TestIndex(
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
テストについての個人の雑感 - tokuhirom's blog
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
Go の Test に対する考え方 - Qiita
この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg/testing/ 命名規則 では、
Hokkaido.pm #11に参加した報告とTestとDocumentの甘い関係に関して - その手の平は尻もつかめるさ
Hokkaido.pm #11に参加してまいりました． 以下が僕の発表スライドです． Hokkaido.pm #11 from moznion 言いたいことは大体スライドに書いてある通りで， TestとDocumentは同じ方向 (どちらも正しいソフトウェアの動作について論じている) を向いている 従って協調できるのではないか 協調するメリット Documentの不整合や陳腐化を防げる DocumentとTestをそれぞれ別個に書くよりもコストを低減出来るかもしれない 方法は2つあると思う Documentにテストケースを埋め込む方法 TestからDocumentを生成する方法 という感じです． “TestとDocumentを同居させる方法”というのは割と以前からある考え方っぽくて，PythonではDoctestというテストモジュールが一般的なようですし*1，JavaScriptにおいては
Go Testing Toolbox
A conglomeration of testing tools, from Autotest to Vagrant. Published on September 28, 2013. Toolbox sans box — this is not whac-a-gopher. Let’s explore some of the tools available for testing our Go code. Unit Testing Go has testing baked in. Below we contrast the standard testing package with Gustavo Niemeyer’s popular gocheck library: // with testing if !reflect.DeepEqual(value, 42) { t.Errorf
型一致ベースのテストに使えるPerlモジュール ~Test::Deep::Matcher,MouseX::Types~ | hirobanex.net
『PerlでTDD(テスト駆動開発)するなら覚えておきたいCPANモジュール群 』って記事書いたら、ありがたいことにikasam_aさんに「Tes::Deep::Matcherを書いたよ」ってご紹介頂きましたので、続けざまに型一致ベースのPerlのテストについていろいろと思うところを整理しておきたいと思います。 【宣伝】Yapc::Asia2012のトークに応募しています この記事アップしようとして、先の記事みたら、私のブログからしたらたくさんはてぶが付いているじゃありませんか!!そして、そのわり・・・。だったので、最初に紹介します。 Perlの最大のイベントYapc::Asiaが今年も開催されますが、今年はトークに応募してみました。バッチ処理とかジョブキューシステムとのQudoとかについて普段やっていることをまとめて発表する予定です。ご興味ありましたら、是非『不安定な環境の中でのバッチ処
What is wrong on Test::More? / Test::Moreが抱える問題点とその解決策
What is wrong on Test::More? / Test::Moreが抱える問題点とその解決策
おそらくはそれさえも平凡な日々: Plack::Middlewareで$envの中身を見るテストを書く方法
Plack::Middlewareの中で $env->{'psgix.hoge'} 的な何かを突っ込むことはあるん じゃないかと思うが、そのテストをどう書くかという話。 Plack::Testだとレスポンスは見られるが、$envはもう見られない。 結論を言ってしまうと、$envをシリアライズして、response bodyに突っ込んでしまう $appを作るのが乱暴かつお手軽かと思う。 以下サンプルコード。 package Plack::Middleware::Hoge; use strict; use warnings; use parent 'Plack::Middleware'; sub call { my ($self, $env) = @_; $env->{'psgix.hoge'} = 'fuga'; $self->app->($env); } このMiddlewareをテストす
Search | スラド
Re:むしろ光沢液晶をどうにかして欲しい。 (1 points, そのまま) by seisei on 2024年02月10日 5時53分 attached to バックライトがまぶしくてツラい人のためのディスプレー Re:スラドに変わるサイトを作ろう (1 points, そのまま) by headless on 2024年02月10日 1時06分 attached to スラドとOSDN、閉鎖せず受け入れ先募集へ Re:とりあえずは、生き延びた (1 points, そのまま) by headless on 2024年02月10日 0時39分 attached to スラドとOSDN、閉鎖せず受け入れ先募集へ Re:もう潰れた方がいいと思っている (1 points, そのまま) by headless on 2024年02月10日 0時30分 attached to スラドとOSDN
Test::Fixture::DBI で覚えるデータベーステスト - Articles Advent Calendar 2010 Hacker
さて、今年も JPerl Advent Calendar の季節がやってきましたね。こんにちわこんにちわ zigorou です。 今回は拙作 Test::Fixture::DBI でデータベースのテストをするお話をしますよ！ このモジュールはモバゲーオープンプラットフォームの API 開発時に必要にかられて作り、今では DeNA の社内でも普通に使われて来ているモジュールです。 レポジトリは github です。 はじめに とりあえずはテスト用の table を用意しましょう。 USE test; DROP TABLE IF EXISTS location; CREATE TABLE location ( id int(10) unsigned not null, user_id int(10) unsigned not null, title varchar(255) not null
Rails, RSpec, Spork(, Guard) で適切にクラスをリロード - 情報と音楽
もう少し簡潔に書けました。追記: Rails, RSpec, Spork(, Guard) で適切にクラスをリロード を参照。 Rails アプリケーションの開発時、spork と guard を使うと非常に効率がいいです。 この記事では spork 使用時にクラスを適切にリロードするための方法を紹介します (guard 関係ないけど、快適にテストできるとこまでのメモとして書いておきます)。spork と guard については、ググるか README みてください。 sporkrb/spork - GitHub guard/guard - GitHub guard/guard-spork - GitHub guard/guard-rspec - GitHub なお、ここではこの方法を確立した時点での最新リリースだった Rails 3.0.7 を想定してます。Rails 3.2 ではクラス
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
