http://seleniumjp.connpass.com/event/24206/ 第3回日本Seleniumユーザーコミュニティ勉強会の資料です。 Seleniumのアンチパターンについてです。Read less
というわけでKonachaです。https://github.com/jfirebaugh/konacha なにこれ、粉茶？ JavascriptのテスティングフレームワークとしてはJasmineやらMochaあたりがメジャーどころのようだけど、セットアップが難しかったりして「これだ！」というものがなかった。個人的には。 で、今回、よーし、お父さんCoffeeScript書いちゃうぞー！というタイミングにあたって、もう一回いろいろ探してみたところ、これが一番スジがいいっぽかった。 KonachaはRailsでMochaとchaiを使いやすくしたGemらしい。Mochaとchaiは使ったことなかったけど、公式を5秒ほどみたところ、nodeでうごくrspecライクなテスティングフレームワークということでJasmineとかとあんまかわらないんじゃないかと推測。chaiはマッチャーのライブラリのよ
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
仕事でUnix系OSを触る必要が出たためにLinux(主にUbuntu)を勉強しがてら、自宅のPC環境にも取り入れてみるブログ。のはずが、最近PC全般の困ったことメモになりつつある。 FirefoxでのHTTPSアクセス時のエラーに関するお話 ※今回はWindows7でのお話です Firefoxを利用して自己証明書サーバ(正規にサーバ証明書を発行してもらっていないサーバ)にHTTPSアクセスすると通常は下のような画面が表示され、「危険性を理解した上で接続するには」をクリックして強引にアクセスすることができる。 ところがある時、 安全な接続ができませんでした 無効な証明書を受信しました。サーバ管理者またはメール送信者に次の情報を知らせてください (エラーコード：sec_error_reused_issuer_and_serial) というエラーが表示されるようになった。(下) この画面では、
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ペースが速い現代のソフトウェア開発環境では、テスト駆動開発（TDD）という言葉をよく聞きます。その利点だけでなく欠点についてもソフトウェア開発コミュニティでよく議論されています。TDDについて、”自己嫌悪に陥って屈辱を味わっている者に対する非現実的で効果のない道徳教育のようなものだ”と言う人もいれば [1] 、”リファクタリングを使って迅速な設計を支援するただのツールだ”と言う人もいます [2] 。 「ダメなプログラマは全てに答えを持つが、優れたテスタは全てに疑問を持つ」 Gil Zilberfeld しかし、TDDは新たな手法というわけではありません。広く知られている最も古い文献は1957年に出版されたD.D. McCracken著の『Digital Computer Programming: The First General Introduction in Book Form, St
会員事業部サービス開発グループ長の村田です。 私は2015年1月から会員事業部でサービス開発エンジニアをやっていますが、2014年4月までは技術部開発基盤グループで Web サービス開発を加速させる様々な取り組みを実施していました。本稿では、開発基盤グループ時代に私が取り組んだ開発者テストの失敗を追跡しやすくする取り組みについて説明します。 クックパッドの Web サービス開発と CI クックパッドのサービス開発は、大きくても5名くらいの小さなチームが一つの機能を担当します。しかし、多数のチームが1つの大きな Rails アプリケーションを同時に変更するのが特徴です *1。 Web サービス開発を加速する工夫には様々な方向性が考えられますが、ここでは、クックパッドのようなスタイルでの Web サービス開発を加速するために開発者テストを何如に円滑にするかを考えます。 図: オムキンス クック
こんにちは、インフラストラクチャ本部の@nagaseyasuhitoです。このエントリは GREE Advent Calendar 2014 10日目の記事です。昨日はイケメンmoritaさんによる男性エンジニアリングマネージャが長期育休を取った話でした。 エンジニアブログのアカウントは2年くらい前からあるのですが、これが初エントリになります。グリーでは比較的珍しいJavaEEを始めとしたサーバーサイドJavaアプリケーションの開発、SolrやHadoopといったミドルウェアの周辺機能開発や運用などを行っています。どうぞよろしくお願いします。 最近はPvE/PvP/GvGなどユーザー同士がリアルタイムに協調プレイする際、クライアント-サーバー間を常時接続通信で行うゲームが増加しています。このような場合はHTTPのREST APIなど慣れ親しんだプロトコルでは要件を満たしきれないため、Web
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と相対するドリームマッチが開催された。この会談の
package spockexample; import org.junit.Before; import org.junit.experimental.runners.Enclosed; import org.junit.experimental.theories.DataPoints; import org.junit.experimental.theories.Theories; import org.junit.experimental.theories.Theory; import org.junit.runner.RunWith; import static org.hamcrest.core.Is.is; import static org.junit.Assert.assertThat; @RunWith(Enclosed.class) public class Perso
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
7. 通常のWebサーバとの通信 <html> <body> <form action=“register” method=“POST”> 氏名:vultest<BR> メールアドレス:vulte[email protected]<BR> 性別:男<BR> （以下略） </html> POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name=vultest&mail=vultest%40example.jp&gender=1 HTTP Response HTTP Request 8. 色々いじってみてどういう応答があるか確認 POST /confirm.php HTTP/1.1 Host: example.jp （以下略） Cookie: PHPSESSID=xxxxxxxxxx name
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 コードを書き続けるためにやってること(by Voluntas) なんか流行っているので乗ってみます。 趣味コード 趣味とはいっても、暇つぶしだったり、流行りもののチュートリアルに触って「おれ新しい◯◯やってみたぜ」みたいなのは極力しないようにしてます。仕事で必要になった時に、仕事の時間の中で集中的に学ぶ方が学習効率が高いので、趣味時間の活用という意味ではもったいないですよね。幸い、まったく未知の基礎的な内容というのはほとんど出会わなくなってきて、新しい技術といっても、既存の知識を土台にして、軽く検索すればOKなことがほとんど。ということで、趣味といっても、将来の仕事で役に立ちそうな種となる可能性のあるものを作るように心がけています。実際に種になるかどうかは運次第なので、命中率に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
