Seleniumアレルギーのための処方箋 - Qiita
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
enzyme+mocha+power-assertでReactコンポーネントのフルレンダリングテスト - wadackel.me
公開されている React コンポーネントのテストコードを見てみると、enzymeを使ってテストしているものを結構見かけます。enzyme はReact 公式でも押しているっぽいので、積極的に使っていきたいです。 Note: Airbnb has released a testing utility called Enzyme, which makes it easy to assert, manipulate, and traverse your React Components’ output. If you’re deciding on a unit testing library, it’s worth checking out: http://airbnb.io/enzyme/ 日本語の紹介記事では@syossan27さんの記事が参考になりました。 React のテストを Enz
テストエンジニアの面接の際にするとよい20の質問
みなさんこんにちは。@ryuzeeです。 DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。 ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます。 もちろん一度作ったらそれで終わりではなく、新しい質問を追加したり、いろいろな候補者から期待と違う回答があった場合には質問自体を見直すといったことも必要になってきます
自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
Vim script版 power-assert! テスト書いてないとかお前それ Vim script の前でも同じこと言えんの? - haya14busa
Vim script で最高の assertion 体験，vital-power-assert を作りました haya14busa/vital-power-assert テスト書いてないとかお前それ Vim script の前でも同じこと言えんの? ということで Vim script 版 power-assert, vital-power-assert を作りました. Vim script でも power-assert できてテストをバリバリ書けるんだから Vim で書いてる他の言語でテスト書いてないとか Vim が泣いちゃいますね…(煽り，そしてブーメラン) 使い方とか 力こそパワー!! 百聞よりパワー!! 使っている様子です 1 2 3 4 " in your vimrc NeoBundle 'vim-jp/vital.vim' NeoBundle 'haya14busa/vital
MinitestとRSpec、FixturesとFactoryGirlの良いところ悪いところをコードを書いて比較してみた - give IT a try
（2022.5.4追記） FactoryGirlはFactoryBotという名前に変更されています（参考）。この記事は昔の名前である「FactoryGirl」を使っています。 はじめに 今年のゴールデンウイークはMinitestとRSpec、FixturesとFactoryGirlについていろいろ研究（？）していました。 具体的にはこんなことをやっていました。 Rails Tutorial 第3版を写経した（第3版ではMinitestとFixturesを使っている） Rails TutorialのテストコードをRSpecとFactoryGirlで書き直した Everyday RailsのテストコードをRSpec + FactoryGirlからMinitest + Fixturesに書き直した The Minitest Cookbookを読んだ 今回のエントリではMinitestとRSpec
第56回PHP勉強会＠関東で PHPUnit について話してきた | Born Too Late
最近 HTML5 化した Slideshare ですが, エラーで表示できないスライドが多すぎてまともに閲覧できないようです. この記事に掲載している Flash 版は今まで通りの問題なく表示できるのですが... スライドが完成したのが勉強会への出発 15 分前で, 通しで練習することすらできず, 発表はかなりひどいものとなっていまいました. 最低限, スライドの流れぐらいは頭の中に入れて発表すべきですね… スライドだけ見てわかるような作りにはなっていないので, 以下で補足したいと思います. ただし, 序盤は省略し, 本論となる書法編とパターン編についてのみとなります. それぞれ該当するスライド番号も付記してありますので, よければご活用ください. 書法編 1: ヘルパーメソッドを使う (25 ~ 30) テスト対象のオブジェクト, それを生成するのに必要な依存オブジェクトの生成には, ヘ
テスト駆動開発／振る舞い駆動開発を始めるための基礎知識
連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」（Test Driven Development、以下「TDD」）は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 本稿では、そうしたTDDの発展や、振る舞い駆動開発（Behavior Driven Development、以下「BDD」）など他のテストファースト手法への展開についても解説します。 ※編集部注：ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J
Rubyのテスティングフレームワークの歴史（2014年版） - 2014-11-06 - ククログ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU
Vagrant環境下におけるブラウザテストについて（Chrome編）
ユニットテストなどは当たり前に行われるようになっていますが、Webブラウザベースのテスト（いわゆる結合、機能テスト）はつい後に放っておかれがちです。UIは頻繁に変わるケースがあり、それがシステムと関係のない部分であってもテストが落ちる可能性があるため、一旦落ち着くまではそのままになり、いつしかテストが行われなくなったりします。 もちろんそのままで良いわけではなく、実際のユーザが使っている環境下でこそ正しく動いているか確認できなければなりません。そのためのツールとしてよく知られているのがSelenium + WebDriverでしょう。 現在の開発、テスト環境 クライアントPCの性能が向上するのに合わせてクライアントPC上に開発用のWebサーバを立ててその場で実行結果を確認する開発方法が当たり前になっています。さらにWindowsユーザの場合、開発環境と本番環境が異なるケースが多く（サーバが
go言語のテスティングフレームワークについて — さにあらず
長いので結論だけ先に。 BDD風味に違和感が無いなら、Ginkgoがオススメ。 もっと軽くてシンプルなのが良いなら、Testifyがオススメ。 テスト対象となるコード 公式のHow to Write Go CodeからYour first libraryにあるコードを持ってきます。 package go_testing // Sqrt returns an approximation to the square root of x. func Sqrt(x float64) float64 { z := 1.0 for i := 0; i < 1000; i++ { z -= (z*z - x) / (2 * z) } return z } 標準で組込まれているテスト用ライブラリについて testing.* 実用性は確かにあって必要なものは揃ってる感あるのだけど、僕にはいくばくかの辛みがあ
TDDを諦めることと、RSpecをやめること - 高柴ラボ
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
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
Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より）
Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より） 2014年8月3日日曜日 ITニュース うつ病 最近一部で話題になっている「SEがテスト工程で画面のスクリーンショットをExcelに延々と貼り続ける作業」について、実際にスクショ貼り職人を経験した自分としては、何か残しておかねばと思い、この記事を書きます。 自分はSEでしたが、うつ病でもうすぐ2度目の休職に入ります。Excelスクショ職人を経験しています。そんな自分が、「Excelスクショに対して疑問を抱いている方」と「今現在Excelスクショ職人な方」へ、お願いと励ましの言葉を述べさせていただきたいと思います。 【参考】 SIerの闇・Excelにエビデンス貼付け - Togetterまとめ あるシステムを開発したら、必ずテスト工程があります。プロジェクトによっては、全くユーザーインタ
Notable Changes in RSpec 3
Myron MarstonMay 21, 2014Update: there’s a Japanese translation of this available now. RSpec 3.0.0 RC1 was released a couple days ago, and 3.0.0 final is just around the corner. We’ve been using the betas for the last 6 months and we’re excited to share them with you. Here’s whats new: Across all gems Removed support for Ruby 1.8.6 and 1.9.1 These versions of Ruby were end-of-lifed long ago and RS
『「メソッドに対してテストをするな」という話題について』への反論 - assertInstanceOf('Engineer', $a_suenami)
「メソッドに対してテストをするな」という話題について - その手の平は尻もつかめるさ 記事の内容が間違ってるとまでは言いませんが、これだけではミスリードしてしまう可能性が高いと思いましたので、簡単にですがアンサーエントリ書いておきます。タイトルでは「反論」と書きましたがどちらかというと「補足」に近いかもです。 前提の整理 「メソッド」という言葉が使われているため、オブジェクト指向的なパラダイムを持つ言語に限定した話であるという認識で書きます。その前提自体が間違っていたらご指摘ください。 元エントリの主張である「テストが説明的であるべきだ」ということを否定するわけではありません。ただ、それと「メソッドに対してテストをするな」という意図が異なるのではないかと主張したいだけです。 元エントリは Perl でサンプルコードで書かれているようですが、僕が Perl にそれほど明るくないため、このエン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chibineko: The simplest test supporting tool
あなたの安心を高速に守る Container-based CI
ShouldBee - テスト作業を限りなくゼロに
http://blog.inouetakuya.info/entry/2013/10/27/200111
