タグ

testに関するhiroponzのブックマーク (46)

  • ActiveRecordを試すときに便利なやつ - r7kamura - Medium

    手元で ActiveRecord を試したいときに、いちいちデータベースを用意したり、再現性のあるコード片に整えたりするのは、結構な手間に感じてしまうかもしれません。この記事では、そういったケースで利用できる知識を幾つかまとめておこうと思います。 以下は今回題材に使うコード例で、これを上から順に説明していきます。 ActiveRecord で .count の挙動を試す例bundler/inlinebundler/inlineBundler 1.10 から追加された機能です。これを利用すると、Gemfile を独立したファイルとして用意することなく、スクリプトの中にその定義を埋め込めるようになります。 続くスクリプトがどのバージョンの Gem で動かせるのかということを明示でき、必要であればライブラリを実行時に自動的にインストールし、依存関係を調べて $LOAD_PATH を調整し、

    hiroponz
    hiroponz 2018/04/16
    便利情報
  • GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST - ブロッコリーのブログ

    はじめに FLAKYの内容が今はっきりした!#JaSST— broccoli (@nihonbuson) 2018年3月8日 と書い(てしまっ)たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。 JaSST'18 Tokyoについては以下のページを参照してください。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo お知らせ この記事の内容を4/11に発表しました! nihonbuson.hatenadiary.jp 発表スライドはこちら speakerdeck.com 目次 はじめに お知らせ 目次 Micco氏のお話 ICSTでの話 基調講演「Advances in Continuous Integration Testing at Google」 講演資料 テスト文化について (3ページ付近) 回帰テスト (4ページ付近) Mil

    GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST - ブロッコリーのブログ
  • 【用語解説】John Micco氏の言う"Flaky"なテストとは? - JaSST東京実行委員ブログ

    JaSST'18 TokyoではGoogleのJohn Micco氏が基調講演とチュートリアルで登壇します。 この2つのセッションのキーワードとなるのが「"Flaky"なテスト」です。 Flakyなテストって? みなさんCI回してますか? CI回していると一定の割合でコードもテストも環境にも変更を加えていないのにたまに失敗するテストってありませんか? 今回の基調講演者のJohn Micco氏が所属するGoogleでは、このような「同じコードでpass/failどちらの結果にもなってしまう」テストを、"flaky"(nondeterministicとも呼ばれます)なテスト結果と呼んでいます。 We define a "flaky" test result as a test that exhibits both a passing and a failing result with the

    【用語解説】John Micco氏の言う"Flaky"なテストとは? - JaSST東京実行委員ブログ
  • Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記

    昨日のRails Developers Meetupで綺麗なテストコードの書き方について発表してきました。 Rails Developers Meetup #1(東京会場) - connpass 資料はこちら 余談 もともと数年前くらいから、テストコードの書き方についてまとめたいなーと思っていたのですがなかなかキッカケがなくて手を付けられていませんでした。今回のミートアップ駆動で一通り形にするところまでいけて今とてもスッキリした気持ちです 😇 もっと多くの人にテストコードの書き方を意識してもらいたいので、また機会があればどこかで喋りたいですね。 昨日発表した内容はGitHubリポジトリにまとめたものの一部です。綺麗なテストコードの書き方について詳しく知りたい方は下記のリンクからどうぞ。 willnet/rspec-style-guide お願い 今回まとめた内容はあくまで僕が考えるテスト

    Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記
  • Rails アンチパターン - 錆びついたファクトリー (factory_girl) - アジャイルSEの憂鬱

    技術書典は書く側で参加したい気持ちはあるけど、書くネタと書く時間があるかどうか…— 神速@リリカルエンジニア (@sinsoku_listy) 2017年4月9日 あー、自分の知ってるRailsアンチパターンとか書きたいかも。自分の犯した罪(アンチパターン)を贖罪したい…。— 神速@リリカルエンジニア (@sinsoku_listy) 2017年4月9日 技術書典2 に行ったら無性にを書きたくなったけど、書くのは 面倒 大変です。 というわけで、とりあえずブログに記事を1つ書いてみた。 factory_girl factory_girl はテスト用データを作成するときに使う gem です。 下記は User のモデルを定義するファクトリーです。 FactoryGirl.define do factory :user do first_name "John" last_name "Doe

    Rails アンチパターン - 錆びついたファクトリー (factory_girl) - アジャイルSEの憂鬱
    hiroponz
    hiroponz 2017/04/10
    ためになる
  • How I sped up our Rails Test Suite by 267%

    This is the first post in a series I’ll be doing here at Codeship on speeding up our test suite. I also released a gem that detects the slowdowns in this part for you. Making test suites run fast has always been an obsession/passion of mine, in fact it all started back in 2010 when I spoke about faster testing in the talk Grease Your Suite. Since then, having a fast test suite is something I maint

    How I sped up our Rails Test Suite by 267%
  • テストを使いサービス開発を駆動していくために取り組んでいること - クックパッド開発者ブログ

    技術部の松尾(@Kazu_cocoa)です。 最近、 @moroや私を中心に、テストから開発を駆動するという方向で、とある活動を始めました。その活動の中では、 @t_wadaさん を 技術顧問 として巻き込んで活動を進めています。そんな取り組みを少しここにまとめます。 取り組みの前段階 先日、私はテストエンジニアというロールに焦点を当ててテストという言葉に対する2種類の話をいたしました。TDDのようにテストによって開発を駆動していく側面の話と、人の認知・感じ方に寄った仕様自体含めてテストしていく側面の話です。 クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました! クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました! その際、会の傍でt_wadaさんらと私たちが開発するWebアプリケーショ

    テストを使いサービス開発を駆動していくために取り組んでいること - クックパッド開発者ブログ
  • サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ

    技術部の taiki45 です。 現在のクックパッドでは、cookpad.com 内のデータを利用するようなプロダクトでも、cookpad.com を提供しているアプリケーション(体アプリケーション)とは別に新規のアプリケーションとして設計・実装しています。また、すでに体アプリケーションの一部として実装されているプロダクトについても、トレードオフを考慮しながら場合によっては、体アプリケーションから独立した別のアプリケーションとして設計・実装することが増えてきています。これらの体アプリケーションや、新規にあるいは体アプリケーションから独立させて設計・実装したアプリケーションのことを「サービス」と呼んでいます。また、この体アプリケーションから独立させることを「サービス分割」と呼んでいます。 制御できないほどの巨大な複雑なまとまりを制御するために、その巨大なまとまりと単純なまとまりに

    サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ
  • Writing One-Liner RSpec Tests in Rails with Shoulda-Matchers - Semaphore

    Raymond works with SaaS developers, showing them how to improve their metrics through product integrations, micro-targeting and partnerships. He can make your micro SaaS product eat competitor's launch too. Introduction Shoulda Matchers provides Test::Unit and RSpec-compatible one-liners that test common Rails functionality. It helps you write tests that would otherwise be much longer, more comple

    Writing One-Liner RSpec Tests in Rails with Shoulda-Matchers - Semaphore
    hiroponz
    hiroponz 2015/08/20
    Shoulda-Matchersを使うとテストをワンライナーで書ける
  • seed.rbの内容をテストで使う - ひげろぐ

    テスト用DBを構築してスキーマも整えた上で以下のコマンドを打つ。 $ rake db:seed RAILS_ENV=test 簡単な話だ。 そしてautotestで回しているうちはこれで問題なかった。 が、rakeやrake specでテストを実行するとテストDBのデータがクリアされてしまい、seed.rbで入れたデータも消え去ってしまうという問題に遭遇。 どうしたものかとRakeタスクの内容を追いかけてみたが、テスト関連のタスクから完全にスルーされているのでseed.rbをテストに使うのはいかんのかとか、seed.rbって実はそんなに使われてないのかななどと言う考えが頭をよぎる。 とはいえseed.rbの内容(マスタ類)をやっぱり使いたいので、結局はspec_helper.rbに以下の行を追加することで対応した。 system("rake db:seed") もっと賢いやり方があれば教え

  • Sauce Labs - Selenium-based Downloads,Hosting and Support

    Website and mobile testing at every stage of development The world relies on your code. Test on thousands of different device, browser, and OS configurations–anywhere, any time.

    Sauce Labs - Selenium-based Downloads,Hosting and Support
    hiroponz
    hiroponz 2014/01/09
    クロスブラウザでの表示確認ができる
  • テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー

    一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき

    テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
  • RubyMotion のテスト、継続的インテグレーション - naoyaのはてなダイアリー

    昨日は RubyMotion のもくもく会でした。 先日の RubyMotion Kaigi 2013 で 実践RubyMotion という題目で発表したのだけど、テストについてはprintデバッグ上等だ、このクソムシがとか言ってかなり適当に済ませてしまった。ので、もくもく会ではテスト周りに手をつけるぞと思い、そういえば Travis CI が RubyMotion に対応してたのも思い出し RubyMotion のテストを Travis CI で回すのを検証した。 が、手間取るかと思った Travis CI 周りはとっても簡単で、.travis.yml に language: objective-c と書くだけであっさり動いてしまった。 というわけで RubyMotion アプリの継続的インテグレーションは .travis.yml を一行書けば完了です。終わり・・・じゃあまったくブログ記

  • RSpecによるユニットテストの書き方 — recompile.net

    2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる(かもしれない)。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと

    RSpecによるユニットテストの書き方 — recompile.net
    hiroponz
    hiroponz 2012/04/19
    ユニットテストの書き方
  • neue cc - Rx + MolesによるC#での次世代非同期モックテスト考察

    最近、妙にテストブームです。Chaining Assertionを作ったからですね。ライブラリドリブンデベロップメント。とりあえずでも何か作って公開すると、その分野への情報収集熱に火がつくよね。そしてテスト厨へ。さて、ユニットテストで次に考えるべきは、モックの活用。C#でモックといえばMoqが評価高い。メソッドチェーンとExpression Treeを活かしたモック生成は、なるほど、良さそうです。読み方も可愛いしね。もっきゅ。もっきゅ。 というわけでスルーして(えー)Molesを使いましょう。Microsoft Research謹製のモックフレームワークです。PexとのセットはMSDN Subscriptionが必要ですが、MolesのみならばFreeです。VS Galleryに置かれているので、VSの拡張機能マネージャーからでも検索に引っかかります。 Moles。Pex and Mole

    hiroponz
    hiroponz 2011/09/20
    C#でのテスト作成の参考にする
  • neue cc - メソッドチェーン形式のテスト記述ライブラリ

    Chaining Assertion for MSTest 昨日の今日で特に更新はないのですが、せっかく画像作ったので再解説。命名は見たとおりに、メソッドチェーンで切らさずアサーションが書ける!ということから付けました。テストを、限りなくシンプルに素早く迷いなく書けるようにしたかった。その答えが、メソッドチェーンで最後に値を取ることです。 // 全てIs一つでメソッドチェーンで流るまま! Math.Pow(5, 2).Is(25); "foobar".Is(s => s.StartsWith("foo") && s.EndsWith("bar")); Enumerable.Range(1, 5).Is(1, 2, 3, 4, 5); Assert.AreEqualの最大の問題は、どっちがactualでどっちがexpectedだか悩んでしまうこと。一秒でも引っかかったら「気持よくない」のです

    hiroponz
    hiroponz 2011/04/20
    chaining assertionの説明
  • Chaining Assertion for MSTest

    すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画テレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W

    Chaining Assertion for MSTest
    hiroponz
    hiroponz 2011/04/20
    テストを書きやすくする拡張
  • 「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは?

    「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは?:誰にでも分かるSEのための文章術(11)(1/2 ページ) 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな

    「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは?
    hiroponz
    hiroponz 2010/07/22
    顧客に提出するテスト仕様書の書き方
  • テストファーストの弊害

    テストファーストは、XP(エクストリームプログラミング)の中でも特に広く浸透したプラクティスの1つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め

    hiroponz
    hiroponz 2010/06/30
    テストファーストで陥りやすい罠。たいして重要でない簡単なテストケースが量産されて、開発工数の浪費につながる危険性がある
  • 脱Excel! TestLinkでアジャイルにテストをする

    今回はTestLinkをテスト工程でどのように使うのか、テスト特有のマネジメント手法や概念を、TestLinkの機能に合わせて詳しく説明した。 【1】TestLinkの概要 TestLinkはPHPで作られたテスト管理Webシステムである。最新版はVer 1.8.3 (2009年6月)で、GPLで公開されている。WAMP、LAMP環境で動作する。 主な機能は下記である。 (参考:「きちんと学びたいテストエンジニアのためのTestLink入門」(gihyo.jp)、「簡易マニュアル - TEF有志によるテスト管理システムTestLink日語化プロジェクト」) 数千から数万のテストケースを一括登録して貯蔵できるので、テストケースを再利用できる テストケースとは別に、テスト実施結果を履歴として残せる テスト実施結果をいろいろな観点で集計できる テストケースからバグ管理システムと連携してバグ修正

    脱Excel! TestLinkでアジャイルにテストをする