PHPUnitの主なAssertメソッド一覧 - QiitaRegister as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
PHPでブラウザテストの自動化！ Facebookの作ったツール「php-webdriver」で人生がときめく - Connehito開発者ブログ(サンプルコード付き)
こんにちは、コネヒトでPHP書いたりしています金城(@o0h_)ともうします。烏龍茶が好きです。 (テスト自動化おじさんの弊社内におけるイメージ) 突然ですが！ 皆さんも、自分の実装についていまいち自信が持てない時はございませぬか。 「あの実装・・頭をよぎる不安・・眠れない夜・・・・」そんな気分で毎日を過ごしていませんか？ 「誰かに許して欲しい、安心をください」。 そんな時はテストを書きますよね。緑色が好きな人、この界隈には私だけではないはずです！ ただ、どうしても検査しづらいな〜どうやって試せば良いかな〜と悩ましい時もあるのではないかと。 「エンドユーザーが直接触るのってブラウザでしょ、だったら実際にブラウザを使った操作が滞りなく可能なら問題ないよね・・」とか、考えたことありませんか？ ここで闇堕ちしたプログラマは、ぽちぽちとhttp://localhostを開いたGoogle Chro
ノンプログラマーが3ヶ月でWebサービスを作ってみた - Qiita
ノンプログラマーがはじめてWebサービスを作ってみた記録です。 2016.3.28 追記: リリース1年後について書きました。 はじめてのOSSリリース記 〜なぜ無料でソースコードを公開するのか？ 自己紹介 趣味でたまにプログラムを書く程度のノンプログラマー。 本業は SHIFT（ http://www.shiftinc.jp ） という会社でテスト自動化エンジニアをしています。 20代最後の年に何か新しいことを！と思い立ち、勢いでWebサービスを作ってみました。 作ったもの Chibineko - 世界で最もシンプルなテストツール https://chibineko.jp 面倒なテストはサクッと終わらせよう Chibinekoはテストケースの作成と実行管理を行うためのシンプルなテストツールです。 テスト項目を箇条書きにするだけで、あなた専用のテスト実行ページが瞬時に作成されます。 あとは
JavaScriptでのテストや開発についてのアウトプット - Block Rockin’ Codes
最近JavaScriptを個人的に勉強しているんですが、そんなJS初心者ながら色々試すなかで気が付いた開発とかTDDとかについて色々思うところをアウトプットしてみようかと思います。 一番多いのは、ClientSideJSで、使ってるのはjQueryとQunitが中心でした。 でもこれからは別のフレームワークや、ServerSideJSなんかも出てきますし、 今読んでる本が終わったら、こっちの本も見てみたいと思っているので、 Test-Driven JavaScript Development: Safari Books Online その前にこれを書いておこうという目的です。自分に付ける一つのTagという感じです。 あまり一貫性に拘らず、垂れ流したいと思います。 Ajax と API 以前こんな記事を書いたように、サーバ側がAPIでデータを提供し、ロジックをクライアント側に固めるタイプの開
Webの負荷テストに使えるフリーソフトウェア | OSDN Magazine
Webアプリケーションおよびサーバの高負荷時の挙動を確認する方法の1つが、擬似的に負荷をかけてテストを行うことだ。ここでは、そうしたテストを実施するフリーソフトウェアをいくつか試し、それぞれがどんなタイプのサイトに適しているかを調べた。 負荷テスト用のツールはいろいろあるが、メンテナンスが行われていないもの、フリーでないもの、インストール手順が明確でないものを除くと、curl-loader、httperf、Siege、Tsung、Apache JMeterの5つが候補として残る。 JMeterについては、すでにDaniel Rubio氏が取り上げているので、ここでは詳しく説明しない。ただし、最後のまとめでほかのツールと共に簡単に触れている。 curl-loader curl-loaderは、「SpirentのAvalancheやIXIAのIxLoadの代替として使える強力かつ柔軟なオープン
SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行
軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。本体のソースコードは約6万7200行（67.2KSLOC、Kilo Source Lines of Code：空行やコメントを除いた行数）なのに対し、テストコードはなんと4567万8300行（45678.3KSLOC）だと紹介されているのです！ これはテストコードが本体の約679倍もの大きさだということになります。 100％のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang
プログラマーにとってのテストの重要性
優れたエンジニアはテストコードをとても重視している、という話を本人たちから直接聞く機会が最近ありました。 オープンソース会の重鎮として知られる楽天のよしおかひろたかさんは「下手なドキュメントを書くくらいだったらテストコードを書くべきだ」「ソフトウェアはテストコードと本体のコードの両方が必要。テストコードがないのは未完成品」と、テストコードの重要性を話してくれました。「全部書き直したいような（他人の）ソースコードを見たときでも、テストを書いていると心が落ち着いてくる（笑）」（吉岡氏）。 JavaのフレームワークSeaserの開発者などで知られるひがやすを氏は、コードレビューのときに「テストコードを見る」ことがほとんどなのだそうです。「テストコードがちゃんと書けていればOK」（ひが氏）。 これは1月30日に行われた「Source Code Reading Workshop Japan 2010
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
どうしてこうなった〜(AAry、gdgdセブンネットショッピング - NullPointer's
⊂⌒⊃｡Д｡)⊃カジ速≡≡≡⊂⌒つﾟДﾟ)つFull Auto | セブンネットショッピング、会員の個人情報がダダ漏れ。さらにネラーに注文番号の規則性を解析される 注文番号が推測可能なんてのは全く問題ではないのだよ。そんなものは連番だって構わない。問題はユーザのアクセス権限の制御ができていないこと。ものすごい基本で難しくない事なのに、なんでこんな制御すらできていないのだろう…。 テストしてないのか、テストケースが「正しく表示される事を確認する」とかふざけた内容だったりするんだろうか。「ユーザが自分の注文を閲覧できる」というテストはあっても、「他のユーザの注文は閲覧できない」というテストをしてないとか… 内製で作ったそうだけど、経験値ゼロのプログラマ、エンジニアばかり集めたのか、あまりにプロジェクトがgdgdすぎてチームが無責任体質になってしまったのだろうか。 内製の価値って？ システムを作
第1回 テスト計画（前編） | gihyo.jp
柏田マネージャー： 5年前に新規事業としてソフトウェアの検証事業を自ら企画し、以来ずっとソフトウェアテスト関連事業を統括している。無類の釣り好き。 初めてのテスト計画！？ 中山君は入社5年目の若手テストエンジニアです。入社以来ずっとソフトウェアテストを担当し、主にテスト実施者として経験を積んできました。本人もテストについてはだいぶわかってきたと自信を持ち始めており、そろそろ大きな仕事もしてみたいと希望を持っています。 そんな中山君、ここ数ヵ月担当していたテストの作業が終わり、仕事がひと段落。次の仕事に備えて今までの資料の整理を行っていました。 中山君： 「ふぅ、ようやく片付いたぞ。なんだかんだで大変だったなぁ。でも、以前に比べてずいぶん仕事をこなせるようになってきたなぁ。そろそろ大きな仕事もしてみたいな…」 自分が仕事を始めた頃を思い出して感慨にふけっていたところに、同じ部署の大塚先輩がや
ウノウラボ Unoh Labs: WEBアプリのテストに必須なツール７種
こんにちは！やまもと＠テスト番長です。 前回satoさんの書いたエントリーが好評のようですね。 自分は実は美術系出身です。なので「デザインセンスのある人からみた～」というエントリーでも続けて書いちゃおうかなと一瞬思いましたが、世の中にはWEBデザインのプロの方もいらっしゃることだし、控えておきましょう。 センスってのも考え込むと難しいですしね。 個人的には、WEBデザインの美醜って「使いやすさ」とかなり直結な気がしてます。 さて、今回は僕が普段テストに使っているツールでもご紹介してみようかと思います。 Selenium 一年前くらいに登場した無償の自動実行ツールです。 有償の自動実行ツールは以前からありましたが、 ベンチャーが購入するには高価なものなので 大手以外にはあまり導入されていなかったであろう類のツールです。 テストシナリオにそってブラウザを自動で操作してくれます。
テストファーストの弊害
テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
JsUnit を使った JavaScript のユニットテスト - WebOS Goodies
アプリケーションを開発する上で、避けて通れないもの、それがテストです。とくにブラウザごとの非互換性が大きい Web アプリケーションでは、念入りなテストが必要です。でも、テストはあまり創造的な作業ではないし、やったからといってなにか機能が増えるわけでもない。できるだけ手間をかけずに済ませたいところですね。 そんなわけで、本日は JavaScript 用のテストフレームワークである JsUnit を利用したユニットテストの方法をご紹介しようと思います。 Ruby のユニットテストの記事でも書きましたが、ユニットテストによるテスト・ファースト開発は開発効率の面でも良い影響があります。まだ導入していない方は、ぜひこの機会に使ってみてください。 JsUnit について 今回利用する JsUnit は Java 用の JUnit を参考にして作られた JavaScript 用のユニットテストフレーム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
brass.to - a really cool domain parked on Park.io