JavaScriptでテストを書こう！一覧CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
GebではじめるWebテスト 〜第1回 導入編〜 - MyBetaBook
はじめに読者の皆さんは、普段Webアプリケーションでの機能テストはどのように行っていますか？今日では商用・OSSを問わず、様々なWebアプリケーション向けのテストツールが存在していますので、既にWeb機能テストを自動化している方も多いと思いますが、まだまだ手動で実施している方もいるのではないでしょうか。また、テストツールを導入したものの、プロジェクトの開発手法に合わなかったり、テストスクリプトを修正するコストが高く、保守されなくなってしまったケースもあるかもしれません。 本稿では、Groovyを用いたWebアプリケーション向けの機能テストライブラリであるGeb（「ジェブ」と発音します）を用いたWebテストの実施方法を紹介していきます。Gebはアジャイル開発と相性が良く、簡潔なDSLでテストスクリプトを記述することのできるテストライブラリですので、これからWebテストの自動化を検討している方
Geb - Very Groovy Browser Automation
What is it? Geb is a browser automation solution. It brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language. It can be used for scripting, scraping and general automation — or equally as a functional/web/acceptance testing solution via integration with testing frameworks such as Spock,
テスト分析・テスト設計入門
© 2013 Fuji Xerox Co., Ltd. All rights reserved. ■JaSST 2013 四国 テスト分析・テスト設計入門 富士ゼロックス株式会社 ソリューション・サービス開発本部 秋山 浩一 2 自己紹介 1985年4月 富士ゼロックス入社 現在はHAYST法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会（ASTER） 理事 JaSST東京実行委員（2003年～） 日本最大のテストシンポジウム1600名の動員 JSTQBステアリング委員（2006～） テスト技術者資格認定を行う国際組織日本支部 日科技連 SQiP研究会 委員長（2011年～） Wモデル研究会 主査（2011年7月～） 電通大 西康晴先生、NEC 吉澤智美氏、MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26委員（20
TestFlight とりあえずどんなものか
iOSアプリを開発中、AdHoc版を用意するなどして、いくつかの異なるデバイス環境でベータテスティングを行いたい場合がよくあります。 純粋にAdHoc版を作って配布してがんばってきましたが、その労力をかなり軽減させてくれる便利なサービスが「TestFlight」です。 このたび（2012年12月）、Adobe AIRにおいても、Gaming SDKというのがリリースされ、その中にTestFlightに対応したANEが含まれていて、これはとりあえず触ってみないわけにはいかないと思います。（iOSアプリ開発の分野に力を入れまくっているアドビさんが買収しそうな匂いがプンプンしますね＾＾）[追記(2014.2.26)：買収したのはAppleさんでした。→「iOSアプリ開発に便利すぎるTestFlightがAppleへ」] というわけで、TestFlight環境をセットアップして、とりあえずベータビ
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
基礎から学ぶソフトウエア・テスト（1） - 基礎から学ぶソフトウエア・テスト：selfup
これから6回にわたってソフトウエア・テストの基本について解説します。テストの基本を理解することは，品質の良いソフトウエアを作るための大切な一歩となるはずです。今回から第3回まではソフトウエア・テストに必要な技術について，第4回から第6回は品質分析やマネージメントについて解説します。 まず，あるソフトハウスの上司と開発者の会話に耳を傾けてみましょう。 上司●設計は進んでいるか？ 開発者●仕様が固まらず遅れ気味です。 上司●それは困ったなあ。対策は？ 開発者●とりあえず今の仕様のままで設計を止めて，コーディングを開始します。幸いテスト工程を多めにとってあるので，徹底的にバグ出しをすれば品質は問題はないと思います。 ～1週間後～ 上司●コーディングは進んだか？ 開発者●それが…，仕様変更など手戻りが多くて遅れ気味です。 上司●おいおい，まずいなあ。対策は？ 開発者●テスト工程の一部をコーディング
ToDoリストのすすめ - 日々常々
TDDBCでTAやってぼやっと思ったことシリーズ。シリーズ？続くの？ - TDDBCのお題はざっくり「何ができるか」が書かれてることが多いですが、これはテストを書くのに十分な粒度ではありません。少なくともお題をそのままテストメソッド名にしてしまうのはダメなパターンです。簡単なところは上手く行くこともありますが、すぐに厳しくなると思います。 これは実際の開発でもよくあります。例え設計者が別に居たとしても、詳細設計書に書かれているものが十分であったことはあまり記憶にありません。咀嚼して適切な粒度に整理し直す必要があります。*1 TDDでのテストの歩幅は人それぞれだなので、明確な答えを示すことはできませんが、「何をテストすればこれができたと言えるか」が明確でない……言うなれば assert から書き始められない場合は、階段の段差の高さが自分のスキルに見合っていないと言うことです。 まず全体を見て
地獄Spec
38. ⑤失敗・教訓（充実してきた頃） カバレッジは万能じゃない -「レガシーコード=テストの無いコード」なので意 味はあるが・・・ -Reekを取るようにした（お手軽/ReekViewer） https://github.com/Shinya131/reekviewer FactoryGirlがパンクした -factory.rbに全てぶっ込むのではなく、 factoriesフォルダ以下にファイル分割配置 -リレーション指定やりすぎると破綻（メンテ不能）に
かっこ悪くて面倒でもテストコードを書こう - 今川館
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
Selenium
Selenium automates browsers. That's it!What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should) also be automated as well. Selenium WebDriver If you want to create robust, browser-based regression automation suites and tests, scale and di
ソフトウェアテストを勉強しはじめて10ヵ月でやったこと - うさぎ組
WACATE 2011 夏に誘われたのがキッカケでソフトウェアテストを勉強しはじめて10ヵ月くらいがたちました。 先日、わんくま名古屋でソフトウェアテストの勉強法についてLTしたのですが、みなさんにいろいろ聞かれたのでここにまとめておこうと思います。 本当は1年の区切りで書こうと思ったけど、まぁいいでしょう。 追記ここから わんくまで発表したLT資料はこちらです うさみみのソフトウェアテスト勉強法 View more presentations from Kyon Mm 追記ここまで こういうのを書くときに時系列で書くべきか、コツを書くべきか悩みますね。 でも、みんなが知りたいのは僕の歴史じゃなくってコツだと思うので後者で書きます。前者はTwitterとか勉強会とかお食事とかお茶でもしているときに聞いてみてください。 以下では多くの書籍を紹介していますが、僕がこの10ヵ月で読んだ本。ってい
テストリストの見つけ方
The document discusses test-driven development (TDD) and common smells or issues that can arise when practicing TDD. It notes that TDD aims to increase code quality by writing tests before code, but that tests can become overly complex or fail to adequately test the code. The document suggests some heuristics to address these potential problems with TDD, such as keeping tests simple, focusing test
Joel on Software - ジョエル・テスト
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある？かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った！そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか？ １オペレーションでビルドを行えるか？ 毎日ビルドを行うか？ 障害票データベースを持っているか？ 新
JaSSTソフトウェアテストシンポジウム-JaSST'11 Tokai
■あなたのバグ票、大丈夫ですか？ バグ票ワーストプラクティス検討プロジェクト ■ソースコード品質解析ツール「AdLint」及び品質評価ツール「Adqua」のご紹介 西田 美徳 （オージス総研) ■～開発文書の品質にご関心はありませんか？～ 森川 聡久（システム開発文書品質研究会（ASDoQ（アスドック））) ■自作テスト進捗管理ツールの紹介 安達 俊 （ソニーイーエムシーエス 東海テック 湖西サイト) ■テスト現場の改善事例 ～テストチームの奮闘記～ 八重樫 剛 （三栄ハイテックス) ■テスト技法から原因分析 ＴＥＦ東海 原因分析道場 ■トラブルの再発防止をどうしていますか？ ～交通の危険予知トレーニング（ＫＹＴ）の応用～ 良知 敦（ＮＥＣアクセステクニカ） ■ＳＩＭＰＬＩＡ（シンプリア）、ＩＮＳＴＡＮＴＣＯＰＹ（インスタントコピー）製品のご紹介 山本 智久（富士通） ■オフショア検証 ～
JMockitは理想的なモックフレームワーク - かとじゅんの技術日誌
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
DBUnitでデータベーステスト - それはBooks
業務でアプリケーションプログラミングを行っている人で、データベースを使わない案件はまれでしょう。ほとんどがデータベースに顧客データを格納したり、マスターデータを引っ張ってきたりするはずです。 そんなデータベースとのやり取りで、SQL文を書いたが、それがほんとうに合っているのか?、単体テスト時にテストデータを毎回手動でデータベースに入れては、プログラムで引っ張ってきた値と等しいかをチェックするのはばかばかしい、データを更新してはみたが、ほんとうに更新されているのかを確認しないといけない、なんて作業はとてもめんどくさくて憂鬱な作業ですよね。 そんな時に威力を発揮するのが、DBUnitという、データベースに関係する単体テストを自動で行ってくれるツールです。 もちろん、どんなテストケースがあるのかは自分で書かなければいけませんが、意図しているデータや、更新されたはずのデータはすべて外部のXMLファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストを分類してみよう!
Google Code Archive - Long-term storage for Google Code Project Hosting.