タグ

testに関するtsucchi1022のブックマーク (114)

  • 「メソッドに対してテストをするな」という話題について - その手の平は尻もつかめるさ

    ―「間違っているかもしれないので,その時はこの銃で僕を撃ってくれ,良いね?」 [2014-05-19T17:48:28Z 追記] http://a-suenami.hatenablog.com/entry/2014/05/17/131326 補足してもらったので読むと良いと思います. わかっちゃはいたけれど上手く言語化できていなかった部分,あるいはわかっていない部分について言及されていたので参考になりました.ありがとうございます. いやーつーかさー,「『メソッドに対するテスト』っていう言葉自体がわかりにくくね?」っていうのはその文言を見たり,この文章書いている間もずっと思ってて,つまり端的に言うとそういう事を言いたかったはずなのに,今このエントリ読み返すとそうした[趣主]旨から完全にズレててメッチャ違和感あるな! ってなりました.俺のバカ! これを仮に言い換えるとしたら「内部構造に対するテ

    「メソッドに対してテストをするな」という話題について - その手の平は尻もつかめるさ
  • Martin Fowler's Bliki in Japanese - ユニットテスト

    http://martinfowler.com/bliki/UnitTest.html 2014/5/5 ソフトウェア開発において、ユニットテスティングの話題になることが多い。私がプログラムを書きはじめて以来ずっと、ユニットテスティングという言葉はおなじみだった。 しかし、ソフトウェア開発用語の常として、ユニットテスティングという用語もきちんと定義できていない。 ユニットテスティングという用語の意味を実際よりも厳密にとらえてしまったせいで、混乱してしまっている人もよく見かける。 もちろんそれ以前からもユニットテスティングはやってきていたのだが、それを人前で公表したのは、Kent Beckと仕事をして Xunit系のツールを使い始めたころのことだった (この種のテストのことは、ユニットテスティングっていうより「xunitテスティング」って呼んだほうがいいと思うんだ)。 ユニットテスティングは

    Martin Fowler's Bliki in Japanese - ユニットテスト
  • 【翻訳】TDD is Fun - diskogs's diary

    @solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that

    【翻訳】TDD is Fun - diskogs's diary
  • TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん

    DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco

    TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
  • Faker::Precureというgemを作りました - くりにっき

    業務で堂々と rubicure を使いたくなったのでプリキュアでテストデータを作るためのgemを作りました。所要時間2時間くらい faker にインスパイアされてます github: https://github.com/sue445/faker-precure rubygems: https://rubygems.org/gems/faker-precure 使い方 各メソッドを呼ぶ度にランダムで文字列が返ります require "faker/precure" Faker::Precure.human_name #=> "黄瀬やよい" Faker::Precure.precure_name #=> "キュアアクア" Faker::Precure.title #=> "Yes! プリキュア5" Faker::Precure.transform_message #=> "レッツプレイ!プリキ

    Faker::Precureというgemを作りました - くりにっき
  • Test::Base::SubTest というモジュールを作った。またはテストケースとテストコードは分離されていたほうが嬉しい話 - Cside::Weblog

    2014-01-15 Test::Base::SubTest というモジュールを作った。またはテストケースとテストコードは分離されていたほうが嬉しい話 perl 自分は Test::Base が好きでよく使うのだけど、subtest 的な、テストのグルーピングができないのがずっっっと不満だったので、Test::Base::SubTest というモジュールを書いた。 https://metacpan.org/release/CSIDE/Test-Base-SubTest-0.1 https://github.com/Cside/Test-Base-SubTest 以下の様な拡張記法が使えるようになる。### でsubtestの 1 単位を表現する。 use Test::Base::SubTest; filters { input => [qw(eval)] }; run_is input =

    Test::Base::SubTest というモジュールを作った。またはテストケースとテストコードは分離されていたほうが嬉しい話 - Cside::Weblog
    tsucchi1022
    tsucchi1022 2014/01/16
    よさそう
  • Test::Synopsis::Expectationというモジュールをリリースしました - その手の平は尻もつかめるさ

    このたび,Test::Synopsis::Expectationというモジュールをリリースしました. https://metacpan.org/pod/Test::Synopsis::Expectation https://github.com/moznion/Test-Synopsis-Expectation 使い方や仕組み等をid:mackee_wさんの記事で紹介していただいたので,そちらの方も併せてご覧いただくと良いと思います. SYNOPSISのコメントを使ってテストするTest::Synopsis::Expectation - ぱいぱいにっき CPANに上がっているモジュールを使う時,多くの方が何は無くとも真っ先にSYNOPSISを見て使い方をザックリ把握するかと思います.とりあえずSYNOPSISのコードをコピペしてみて,動くかどうか見てみる的な. で,SYNOPSISのコード

    Test::Synopsis::Expectationというモジュールをリリースしました - その手の平は尻もつかめるさ
  • SYNOPSISのコメントを使ってテストするTest::Synopsis::Expectation - ぱいぱいにっき

    この記事はPerl Advent Calendar 2013の16日目の記事です。 Test::Synopsis::Expectation Perlのモジュールを作る際に便利そうな少し変わったモジュール、Test::Synopsis::Expectationを使ってみます。 その前にテスト対象のモジュールを作ります。ひな形作成に便利なMinillaを使ってスケルトンを作成します。 $ minil new AwesomeTargetそこで出来たAwesomeTarget/lib/AwesomeTarget.pmを以下のようにいじります。 package AwesomeTarget; use strict; use warnings; sub plusplus { my ($class, $num) = @_; return ++$num; } 1; なんのことはない、ただ++するだけのクラス

    SYNOPSISのコメントを使ってテストするTest::Synopsis::Expectation - ぱいぱいにっき
  • これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE

    和田卓人さんによるテスト駆動開発問題解説の寄稿です! バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中! by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上

    これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE
    tsucchi1022
    tsucchi1022 2013/11/26
    これめっちゃいいな
  • VOYAGE GROUP エンジニアブログ : プライベートメソッドのテストは必要ない!!

    2013年11月12日16:19 カテゴリprogramming プライベートメソッドのテストは必要ない!! こんにちは、RPAの関口です。 最近週に一度、来年の新卒達と一緒にTDDをやりながらワイワイガヤガヤしております。そのなかで「プライベートメソッドのテストはどうすれば良いのか?」 という話題がありました。プライベートメソッドのテストについては プライベートメソッドのユニットテストは書かないもの? がよくまとまっていると思います。プライベートメソッドのテスト方法について考える中で「TDDの手順に従えばプライベートメソッドのテストがしたくなることは無い」のではないか?と思うようになりました。 プライベートメソッドはリファクタリングの結果現れる! 数値の配列を渡すと平均を計算して返してくれる機能を持ったクラス、AverageCalculatorを作りたいとします。平均計算の手順をまとめる

    tsucchi1022
    tsucchi1022 2013/11/13
    ロジックの複雑性のせいでアクセス指示子が変わるのはおかしいと思うので、「必要ならプライベートメソッドもテストする」でいいんじゃないかなぁ
  • Test::Stub::DBI ってのを書いてみた - tsucchi の日記 2nd season

    多分、これの続きみたいな話。。。なのかな。 生SQLを使うロジックをテストする場合、データを突っ込む仕組みを作って SQL を実際に投げるか、DBD::Mock あたりを使うのが普通なのかな、 と思います。 DBD::Mock は凄く良く出来てて、エラー条件なんかも含めて、ほとんどの DBI の振る舞いを偽装できて便利なのですが、割と長大で設定がめんどい 感じするし(使うときは毎回ググってる)、最初に挙げた記事みたいに微妙に機能が足りなかったりして困る事もしばしばあります。 なので、じゃあ Test::Mock::Guard とか、そのへんのスタブ使って偽装作ろうとすると、それはそれで面倒だったりします。「$dbh ってなんだっけ?」(正解は DBI::db)とか、 「$sth って(ry」(DBI::st)とか、「'...is not a DBI handle (has no magic

    tsucchi1022
    tsucchi1022 2013/11/04
    記事書いた
  • テストと対応関係 - $shibayu36->blog;

    テスト書きすぎ問題 - hitode909の日記、階層を増やしすぎるとテストが多くなりがちという問題 - はこべにっき ♨みたいにテストの話が何個か出たので、ちょっと関係ないけど最近のテストで気をつけていることの一つについて書こうと思う。テストを書くときに気をつけていることとして、そのテストが何をテストしているのかという対応関係を明確にしながらテストを書くということを気をつけている。 例えば以下の様なクラスがあるとする。 package Blog; use strict; use warnings; sub new { my ($class, $args) = @_; return bless $args, $class; } sub has_favicon { my ($self) = @_; return !! $self->{favicon_path}; } sub favicon_

    テストと対応関係 - $shibayu36->blog;
  • 階層を増やしすぎるとテストが多くなりがちという問題 - はこべにっき ♨

    テスト書きすぎ問題 - hitode909の日記 いい話。だいたい同意見で、テストはなるべく書こうとしたい。後からコードに変更を加える人が安心できるように、テストには書いてるコードがどう有るべきかという情報が全部網羅されていてほしい。コードがあるべき状態ではなくなって動かなくなったときは、必ずテストが落ちて欲しい。 とはいえ、テスト書きすぎてしまって良くなかったなあと思うことはある。アプリケーションの設計の階層が無駄に深くなっていて、各階層ごとに似たようなテストをなんども書く事態に陥ったりするような場合だ。 例えば、何かブログみたいなWebアプリを作っていて、エントリー投稿する機能を実現する機能が以下のクラスに含まれていたとする。 Blog::Controller::Entry ディスパッチャから呼ばれるエントリーポイント Blog::Handler::Entry HTTPリクエストからE

    階層を増やしすぎるとテストが多くなりがちという問題 - はこべにっき ♨
  • テスト書きすぎ問題 - hitode909の日記

    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

    テスト書きすぎ問題 - hitode909の日記
  • データベースのテスト - パルカワ2

    ふわっとしたタイトル通り、中身はありません。 use strict; use warnings; use Test::More; subtest "A" => sub { # DBを扱ったテスト }; subtest "B" => sub { # DBを扱ったテスト }; done_testing; こういう感じで書いちゃうと、subtest "B"のテストコードが、subtest "A"に依存するとかよくしちゃう。 そういう事をするとsubtest "A"がいらなくなったから削除するとsubtest "B"がエラー吐くみたいなのが、とてもつらい。 「こういう事起きないように気をつけよう!」みたいなの、ずっと1人だったらそれでいいんだけど、チームで開発してるといつの間にか気をつけよう!は忘れ去られてる事が多い。 だから以下のようにapptestみたいな名前のやつをt::Utilに作って、そ

    データベースのテスト - パルカワ2
    tsucchi1022
    tsucchi1022 2013/08/20
    apptest で何やるか次第だけど、teardown相当の処理でrollbackかけるのが定番かなぁ
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    tsucchi1022
    tsucchi1022 2013/08/15
    BKだけど、役に立ちそう
  • Test::Moreのsubtestで困っていること - $shibayu36->blog;

    最近はperlでテスト書く時はTest::Classを使うようにしている。その理由の一つとして、subtestだけのテストだと少しだけ困ることがあるからだ。 具体的には以下の事がある。 subtestは書かれている順に実行されるため、前のテストの状態に依存したコードが書かれがち 特定のsubtestだけを実行するのが面倒 前のテストの状態に依存したコードが書かれがち 僕の中では、テストが前のテストの状態に依存しないようにすべきと思っている。各テストの依存度が増えると、その後テストを追加したいときにコードの見る範囲が増え、テストが書きづらくなってしまうからだ。 しかし、subtestは単に書かれた順にテストが実行されるので、前のテストの状態に依存したコードが書きやすいと思っている。例えば以下の様なコードが書かれがち(少し極端な例だが)。 use Test::More; # insert_en

    Test::Moreのsubtestで困っていること - $shibayu36->blog;
    tsucchi1022
    tsucchi1022 2013/07/17
    デフォルトでテストしたいメソッドが指定できるのは便利かも
  • パッケージ名が良くわからない物体をテストする - tsucchi の日記 2nd season

    tsucchi1022
    tsucchi1022 2013/07/17
    記事書いた
  • http://papix.hateblo.jp/entry/2013/07/09/211600

  • TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary

    Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように

    TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary