テストを書くか書かないかの判断の話
writing_unit_test.md ユニットテストでテストを書くか書かないかの判断の話 お題 メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか テストとは まず、基本の考えとしてなぜテストをするのか？というのがあります。 テストとは、エラーをみつけるつもりでプログラムを実行する過程である。(via ソフトウェアテストの技法 [Glenford J. Myers]) という言葉のとおり、最小の手間でプログラムのエラーを見つけ出そうとする試みがテストです。裏を返せば、エラーが見つかる可能性が低いのにすべてのことを試すのはテストではありません。 判断するときの論点 いくつかこれを判断するときの論点があります (Boolean に限らず、「そのテストは必要か？」と考えるときの観点ともいえ
MySQLテストデータを自動生成&インポートする、PHPライブラリ「MagicalGirl」を公開 | LIVESENSE made*
テスト・開発に使用するデータ生成の必要性 動作確認テストや開発時に使用するデータベースのデータ、どのように準備していますでしょうか？毎回手動で作成している、本番環境から持ってくる。これらは一番良くない例ですよね。 毎回手動で作成していては、開発環境構築の度に、テスト実行の度に作業コストがかかり、オペレーションミスも発生しやすくなります。知っていないと用意できないデータ項目などもあるでしょう。それらを毎回一つ一つ確認するのは大変な作業です。 本番環境のデータを使用することが危険であることは言うまでもないと思います。個人情報を扱っているシステムであれば、情報保護の点から大変なリスクを犯す行為です。メールアドレスを保存してあるシステムであれば、オペレーションミスにより不要なメールを実際に送信してしまう危険性も伴います。 特に、動作確認の際に自動テストを実行する場合、想定通りのデータが入って
型駆動開発？テストコードを減らせるかもしれない個人的に注目のアイディア · 株式会社クラフトマンソフトウェア
開発していると、○○駆動開発という言葉をよく耳にしますね。 テスト駆動開発、モデル駆動開発やReadme駆動開発などいろいろあります。 今日、紹介するのは「型駆動開発」です。英語でType Driven Development。 型駆動開発って何？ Maciek Próchniak氏によると、型駆動開発とは一言で、テストコードでチェックしている部分をコンパイラで行うという開発スタイルだそうです。 確かにコンパイラでバグが見つけられれば、テストコードを書く手間もないですし、 テストコードはビルドするときに実行し忘れてしまったら問題があっても気づけないですが、 コンパイルは実行前に必ず走るので、チェック漏れも減りそうです。 コンパイラがあれば手軽に始められるのも良さそうですね。 型駆動はバグを防ぐ方法のひとつ 同氏によると、型駆動開発以外でバグを防ぐ方法は 防衛的プログラミング 契約プログラミ
障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか？」 | POSTD
私はポストモーテム（事後分析）の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleとMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は（まだ）きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、
Go言語でPerlのテストを早くする
Test::mysqld::Multiというモジュールを書いてみたみたいな涙ぐましい努力により5分で終わるようになったテストですが、 プロジェクトのコードも増えて人も増えた影響で、 テスト時間が約7分まで伸び、テストのキューに10個近く並んで順番待ちさせられるという状況になってしまいした。 この状況を解決すべく go-prove というものを書いてみたので、そのご紹介です。 proveが遅い理由 proveがテストの結果を読むところがブロッキングI/Oになっているらしく、そのせいで遅くなっているらしいです。 Perl-Toolchain-Gang/Test-Harness#30 実際に結果読んでいるところはこの辺ですかね。 selectとか使っていてなるべくブロッキングしないような作りにはなっていそうですが、どこかでブロッキングしてしまっているようです。 今のプロジェクトだと32コアのCP
全国のSeleniumer必読 - Qiita
アナウンス Selenium 談話会 in Slack まだまだ活動続けています！！(2019/09/09追記) https://selenium-danwakai.connpass.com/ でアナウンスを出しています。 2015/春から「Selenium 談話会 in Slack」というものをはじめました Slack(チャット)を使って日々の困りごとなどを同士とリアルタイムで情報交換することができます 登録されたユーザは2015/06/25時点で35名 => 2019/09/09時点で596名 半年に１回程度でチャット上に集まってテーマを決めて話をしています Ex) 「第３回Selenium談話会 in Slack」 のまとめ 詳細、参加方法などは上記リンク先に書いています 2018/09/18時点で13回開催しています。ご興味のある方はお気軽にご参加ください https://sele
WebのUIテスト自動化 - Seleniumを使ってみる - Qiita
Appiumを色々触っているんですが、仕組みが同じSeleniumもちょっと触ってみました。 だいぶ色々なことができそうなのでこちらも触りつつメモを取っていこうと思います。 実際の動画デモ 実際にどんなことができるのか、参考動画を撮ってみました。 内容的にはネタな感じにしていますが、どんなことができるか分かってもらえるかと思いますｗ Seleniumとは Seleniumはクロスブラウザ、クロスプラットフォームのUIテストツールです。 ブラウザに表示される要素を操作し、取得して想定されうる状態になっているかをテストできます。 また、画面のキャプチャを撮ることもできます。 検索してみると有用な記事がいくつかあるので、詳細はそちらを見てください。 ここでは簡単に触ったメモや所感を書いていきます。 JavaScriptテスト自動化ツールSeleniumのこれまでとこれから（前編）。第1回 日本S
第21回 テスト駆動開発（1） まずテストを書こう | gihyo.jp
こうして必要な情報を調べてみるとBMIや肥満度に性別や年齢は必要ないのが分かります。そのとき、開発者は立ち止まって考えます。例えば、「必要ないので、実装は取りやめようか？」「しかし次回作成するUIには、性別を反映したい」「ここは今後のアプリケーションの発展の可能性を考慮して、残す方向で進めよう」といったように考えます。このように、ごく近い将来利用する要素であれば、先回りして実装しておくのも許容できます。しかし、利用する予定がないのであれば、きっぱり削除しましょう。必要になってから実装する（YAGNI]）というXP（エクストリーム・プログラミング）の原則です。 テストコードの作成と、目的のコードの作成 それでは、個人情報コンテナクラスをテストするコードを書いてみます。この段階で個人情報コンテナクラスそのものは、入力を受け付けますが中身は空っぽです。このような状態のコードを「スケルトンコ
JavaのユニットテストにSpockを適用する - Qiita
アトラクションルームクラス。ルームに人を追加するaddメソッドを持つ。キャパシティは合計20あり、男性の大人は3、女性の大人は2、子供は男女とも1を消費する。キャパシティがいっぱいになったら満員で、それ以上は人を追加できない 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 stati
脆弱性もバグ、だからテストしよう！
脆弱性もバグ、だからテストしよう 継続的セキュリティテストサービスVAddy プレゼン資料Read less
サーバの負荷テストのための、何百万ものHTTPリクエストを発生させる方法 | POSTD
(注記：6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ
CakePHPのControllerの画面遷移のユニットテストってどうやるの
CakePHP(PHPUnit)でユニットテストを書いているのですが、コントローラーで意図したページに正しく画面遷移しているかどうかをテストしたくなり、どうやったら実現できるか試してみました。 例えば下記のページに遷移することをテストしたい場合。 itemsに関連するModel, Controller, Viewが存在する状態とします(今回はbakeで作った)。 一般的かどうかはわかりませんが、返ってきたHTML文字列の中に「商品一覧画面」という文言が存在するかどうかで判定することにしました。 テストの実行は画面から確認します。 http://localhost/test.php テストコード まずはシンプルにこんな感じ。 これは$resultがnullなためFailedになります。 ItemsControllerTest.php
大規模 Web サービスの ブラウザテスト自動化・高速化
https://atnd.org/events/66159 で実施したプレゼン資料
RubyでSeleniumを使ってサクッとスタンドアローンなブラウザテストを作成する - Rails Webook
Photo by Flickr: Simon & His Camera's Photostream RubyでSeleniumを使ってスタンドアローンなブラウザテストをする方法を説明します。 テスティングフレームワークにはRSpec、SeleniumにアクセスするためにCapybaraをつかうことで簡単にテストがかけます。 メリットとして、スタンドアローンなので、ブラウザでテスト対象のページが開ければ、他の要素のサーバーのプログラミング言語やサーバーの配置場所など制約がなくテストを作成できます。 目次 必要なgemをインストールする ブラウザをインストールする テストコードを記載する 動作環境 Mac OSX 10 Yosemite Ruby 2.2.0 selenium-webdriver 2.45 chromedriver 2.15 rspec 3.2.0 capybara 2.4.4
UIテストの自動化！Node.jsとSeleniumでWebアプリのUIテスト環境構築 – ICS MEDIA
Webアプリケーションを開発する際、みなさんはどのようにテストを行っていますか？ Webアプリケーションは、ユーザーごとに異なるブラウザを使用しており、ユーザー操作も必要となるため、手作業でテストをされている方も多いと思います。また、機能改修やバグフィクス後に、リグレッションテスト（改修により既存機能への影響がないかを確認する回帰テスト）が必要となりますが、時間が取れずしっかりとテストができていない方も多いのではないでしょうか。 本記事では、これらのテストを自動化することのできる「Selenium Webdriver」（セレニウム ウェブドライバー）について紹介します。 入力フォームのバリデーション機能をチェックするデモ 簡単な入力フォームのバリデーション機能をチェックするデモを動画で紹介しましょう。入力値に対して期待するエラー文言が表示されているかのテストを実施しています。Seleniu
日本Seleniumユーザーコミュニティ
日本Seleniumユーザーコミュニティは、Seleniumに関する分からないこと・困ったことについてユーザー同士で助け合うグループです。
小さく始める JavaScript のテスト - Qiita
書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通にこのスクリプトを node/io
「セキュリティ対策」
「不正な入力に対して脆弱性を発生させないようセキュリティ対策としてバリデーションを行う」。アホか。プログラマならセキュリティ対策とか気にするな。いや、気にするなというのは言い過ぎだけれど、ほとんどの場合においてあなたの書くコードはセキュリティ対策の必要性はない。 攻撃者の細工した入力によってSQL/HTML/JavaScriptが壊れるとかバッファオーバーフローが発生するとか、そういった脆弱性と呼ばれるほとんどのものはただのバグだ。セキュリティ対策っていうのはコードとは切り離された領域で行うDEPだったりASLRだったりX-Frame-OptionsだったりCSPだったりiframe sandboxだったり、そういうものがセキュリティ対策だ。コード上で書くのは「アプリケーションとして正しく動作するための処理」だけだ。 もちろん例外もあるかもしれないけど、それはあくまでも例外だ。日常的に書く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドに秩序を取り戻す方法 〜はてなブログ編集画面をリニューアルするためにやったこと〜 // Speaker Deck
Redirecting