タグ

testとprogrammingに関するstarsky5のブックマーク (26)

  • BDDについて自分なりにまとめてみた - UKSTUDIO

    BDDについて自分なりにまとめてみた Published on 2011-07-02 Updated on 2011-07-02 BDDという言葉も割と人によって指すものが違うようなので「俺の中でのBDDはこうだよ」って内容のエントリ。別に絶対的なものでもないと思うので参考までに 結論から とりあえず結論だけ知りたい人向けに。 BDDにはふたつの種類がある TDDの言い換えのBDD(開発寄り) ATDD(受け入れテスト)でのBDD(ユーザ寄り) 振る舞い BDDは振る舞い駆動開発と言われたりするように、テストという言葉のかわりに振る舞いという言葉を使う。日語的には仕様と言うほうがわかりやすいかもしれない。多分、BDDのイメージが掴みにくいのはこの振る舞いという言葉にあると思う。と言うのも振る舞いと言うのは、人の立場よって変わるからだ。例えば、プログラマがあるクラスを実装している時に言う振

  • Perlのメモリリークを見つける方法 - Islands in the byte stream (legacy)

    Perlではメモリリーク検出ツールがいくつか開発されているので、top(1)の結果を眺めるよりそういうツールを使うほうが楽である。 さて、メモリリークが発生しているとき、その可能性としてはだいたい以下の4つが挙げられる。 Perlレベルでの循環参照 グローバル変数に値をどんどん足しているとき*1 XSレベルでリファレンスカウントの管理ミス XSレベルでmalloc()したメモリの管理ミス この1-3についてはすべてPerlインタプリタ内の出来事であり、Test::LeakTraceを使って検出できる。4を検出するのは難しいが、Test::Valgrindが役に立つ。 Test::LeakTraceのSYNOPSISは歴史的経緯によりごちゃごちゃしているが、テストで使うべき関数はno_leaks_ok()とleaks_cmp_ok()だけである。 たとえば、以下のようにして使う*2。 #!p

    Perlのメモリリークを見つける方法 - Islands in the byte stream (legacy)
  • テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組

    WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです! 次の形式で書いています。 WEBサイト名、資料名:発表者(敬称略):URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai

    テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
  • 第21回 Railsアプリの受け入れテストをCucumberで書こう | gihyo.jp

    はじめに Cucumberとは受け入れテストのためのテスティングフレームワークです。CucumberはRuby on Railsに依存しているライブラリではないため、例えば同じRuby制のフレームワークであるSinatraはもちろん、PHPなどで書かれたアプリケーションでも使用することができます。 Sinatraやフレームワークを使用していない素のRubyスクリプトなどをベースにCucumberの解説をすることも可能ですが、今回は仕事で使っている人が多く、また筆者自身もRailsを使って開発をしていることもあって、Railsをベースに解説させていただきます。 なぜCucumberなのか 筆者が勤めている株式会社RAWHIDE.では、Railsアプリを作成する場合、原則的にCucumberでテストを書くようにしています。Cucumber採用当時は、社内にナレッジが少ない、不慣れなど、なかなか

    第21回 Railsアプリの受け入れテストをCucumberで書こう | gihyo.jp
  • Test::Unit と RSpec と Shoulda

    昨日の記事 続・Rails 3.x 時代のテストフレームワーク では、Rails で使用できるテストフレームワークの基礎知識と相互関係についてまとめました。 今日は、Test::Unit と RSpec と Shoulda を具体的に比較してみたいと思います(Cucumber については、別の機会に…)。 例として「変数 @total に文字列 '100' をセットすると、式 @total.to_i は 100 を返す」というテストケースを考えましょう。 純粋な Test::Unit ではこのように書きます。 require 'test/unit' class SimpleTest < Test::Unit::TestCase def test_should_return_100 @total = '100' assert_equal(100, @total.to_i) end end R

  • いまからでも間に合う開発者テスト - mixi engineer blog

    はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、

    いまからでも間に合う開発者テスト - mixi engineer blog
  • ゆーすけべー日記

    サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ

    ゆーすけべー日記
  • iUnitTest - リンゴの水やり?(はてな)

    iPhoneのUnit TestフレームワークiUnitTestを公開しました。会社として公開したのでプレスリリースなんか出したりしてます。 http://github.com/katsuyoshi/iunittest/tree/master インストールはいたって簡単で、ソース一式を持って来たらそのディレクトリで'sudo ./setup'を実行するだけです。 XcodeにiUniTestアプリケーションのテンプレートが追加されるので、それからテスト用のプロジェクトを作成します。*1 テスト用のクラステンプレートも追加されているので、わざわざimportしたりテスト用に設定をしたりという事は必要ありません。 テストはIUTAssertion.hに書いてる"ASSERT"から始まるマクロを使用します。 メッセージを入れる事も想定してますが、実装してません。exceptionを扱う物もありま

    iUnitTest - リンゴの水やり?(はてな)
  • プログラマーにとってのテストの重要性

    優れたエンジニアはテストコードをとても重視している、という話を人たちから直接聞く機会が最近ありました。 オープンソース会の重鎮として知られる楽天のよしおかひろたかさんは「下手なドキュメントを書くくらいだったらテストコードを書くべきだ」「ソフトウェアはテストコードと体のコードの両方が必要。テストコードがないのは未完成品」と、テストコードの重要性を話してくれました。「全部書き直したいような(他人の)ソースコードを見たときでも、テストを書いていると心が落ち着いてくる(笑)」(吉岡氏)。 JavaのフレームワークSeaserの開発者などで知られるひがやすを氏は、コードレビューのときに「テストコードを見る」ことがほとんどなのだそうです。「テストコードがちゃんと書けていればOK」(ひが氏)。 これは1月30日に行われた「Source Code Reading Workshop Japan 2010

    プログラマーにとってのテストの重要性
  • (修正)float型とdouble型を比較した場合、常にfloatが速いと思ってはダメらしい - 強火で進め

    すみません、以前のプログラムにポカがありました 以前、以下のエントリーを書きました。 float型とdouble型を比較した場合、常にfloatが速いと思ってはダメらしい - 強火で進め http://d.hatena.ne.jp/nakamura001/20090226/1235641233 そして今回、この速度差がどこから来てるのかアセンブリレベルで検証しようと色々と前回のプログラムを見直していたところ大ポカをやらかしている事に気がつきました。 具体的には以下の様な部分です。 NSLog(@"double : time=%f\tval=%f", elapsedTime, floatTotal); こちら double での計算結果なので来でればここで指定するのは floatTotal ではなく doubleTotal です。 このようなポカをやらかしたせいで doubleTotal

    (修正)float型とdouble型を比較した場合、常にfloatが速いと思ってはダメらしい - 強火で進め
  • Kazuho@Cybozu Labs: Perl のテスト用に MySQL 環境を自動で構築するモジュール Test::mysqld を書いた

    ORM やウェブアプリケーション関連のライブラリなどのテストケースを書くにあたっては、 RDBMS へのアクセスが必要になります。しかし、SQLite のようなスタンドアローンのデータベースと比較すると、サーバ型データベースである MySQL に接続してテストを書くのは、既存の MySQL の権限設定やデータベース名を気にする必要があったりと、いろいろ不便です。そこで、MySQL のインスタンスをテンポラリディレクトリに自動生成し、テストが終わったら削除してくれる Perl モジュール Test::mysqld を書きました。こんな感じで使います。 use DBI; use Test::mysqld; use Test::More; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '' }, # TCP接続を

  • いやなブログ - スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl

    スクリプト言語用のデバッガの使い方 - Ruby, Python, Perl スクリプト言語用の CUIのデバッガの使い方を簡単にまとめました。対象言語は Ruby, Python, Perl です。 私は C, C++ でプログラムを書いているときはデバッガ (主に GNU/Linux 上の gdb) を頻繁に利用します。しかし、スクリプト言語ではそれほどでもありません。これはおそらく次のような理由によります。 ビルドが不要なので printf デバッグが容易 (ある程度大きい C++ のプログラムではビルド時間が長いので printf の挿入はしんどい) 異常終了時にスタックトレースが表示される (Ruby, Python なら自動、Perl の場合は use Carp; $SIG{__DIE__} = \&Carp::confess; など) オブジェクトのインスペクトが簡単 (Ru

  • 第7回 Catalyst::DispatchType::Chained:チェーンドアクションはむずかしい? | gihyo.jp

    モダンPerlの世界へようこそ 第7回Catalyst::DispatchType::Chained:チェーンドアクションはむずかしい? 5.7系列の目玉だったチェーンドアクション 3年前に登場したCatalyst 5.7系列で導入された機能のひとつに、チェーンドアクションと呼ばれるものがあります。これは慣れると非常に便利な機能なのですが、それまでのURLとクラスの対応を根底から覆してしまう大転換だったわりにドキュメントが不足していたため、活用の仕方がわからないという声もありました。 今回はCatalyst 5.8系列で導入された新しいツールを使いながら、このチェーンドアクションの使い方を紹介していきます。スペースの都合でCatalystの基はある程度理解しているものとして話を進めますので、わからないことがあったらCatalyst体のドキュメントやCatalyst::Manualなどを

    第7回 Catalyst::DispatchType::Chained:チェーンドアクションはむずかしい? | gihyo.jp
  • Test::More - テストを書くためのもう一つのフレームワーク - perldoc.jp

    名前¶ Test::More - テストを書くためのもう一つのフレームワーク 概要¶ use Test::More tests => $Num_Tests; # または use Test::More qw(no_plan); # または use Test::More skip_all => $reason; BEGIN { use_ok( 'Some::Module' ); } require_ok( 'Some::Module' ); # 「ok」と示すためのさまざまな方法 ok($this eq $that, $test_name); is ($this, $that, $test_name); isnt($this, $that, $test_name); # STDERR に出力するよりも "# here's what went wrong\n" diag("here's what

  • はじめてのTest::Simple

    テストが届いたのでテストをしてみるテスト。勉強日記の公開テストもかねて。 Perl Testing: A Developer's Notebook (Developers Notebook) Test::Simpleはじめの一歩 #!/usr/bin/perl use strict; use warnings; use Test::Simple tests => 1; sub hello_world { return "Hello, world!"; } ok(hello_world() eq "Hello, world!");

  • Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

    『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

  • チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー (2007-09-07)

  • Google,Webアプリ用試験ツール「ratproxy」をオープンソースとして公開

    Googleは米国時間2008年7月1日,Webアプリケーションの安全性を確認できるツール「ratproxy」をオープンソースとして公開した。同社のWebサイトから無償ダウンロード提供している。 同ツールは,これまで同社が社内でWebアプリケーションを試験する際に使っていた。プロキシ・サーバーとして作動し,クロスサイト・スクリプティングに悪用される恐れのあるコードや,情報漏えいにつながる問題などを調べられる。従来のセキュリティ・ツールと違い,意識することなく利用でき,オーバヘッドも小さいという。 ソフトウエア・ライセンスはApache License 2.0。現在のバージョンは「1.51ベータ」。Linux/FreeBSD/Mac OS Xと,Windows向け疑似UNIX環境Cygwin用に開発した。 [GoogleのMichal Zalewski氏によるブログ投稿記事]

    Google,Webアプリ用試験ツール「ratproxy」をオープンソースとして公開
  • 「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found

    2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必

    「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
  • メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ

    その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの

    メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ