DroidKaigi 2019 で発表した資料です。
DroidKaigi 2019 で発表した資料です。
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
If you missed Part 1 of our Testing Angular 2 Apps series, I encourage you to take a look at it here. Note: Article is based on Angular 2 beta.2 Up-to-date Gist with examples for whole series is here: Angular 2 testing gist Starter project with setup for tests is here: https://github.com/wkwiatek/angular2-webpack2 Testing Services The easiest thing to start testing real Angular 2 thing is Service.
師走も半ばの2014年12月14日、東京赤坂のヤフー株式会社の会議室をお借りして、昨年に続き2回目となる「システムテスト自動化カンファレンス2014（STAC2014）」が開催されました。今年のテーマは「広く普及しキャズムを超えてきたシステムテスト自動化について、そのアーキテクチャやパターンについても考えていこう」というものです。なんとイベントの受付開始から24時間を待たずに191名の定員が埋まり、最終的には200名近いキャンセル待ちが出るという超人気イベントとなりました。今回はイベントの内容と共に現場の熱気もお伝えしたいと思います。 STAC2014はテスト自動化研究会（STAR）によって運営されています。STARは「テスト自動化技術における高度なスキルを検討・定義し、それを広く世に広く啓蒙する」ことを目的として2012年に発足し、本カンファレンスを主催しているコミュニティでもありま
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの
Frisby makes REST API testing easy, fast, and fun. Frisby.js comes loaded with many built-in tools for the most common things you need to test for to ensure your REST API is working as it should, and returning the correct properties, values, and types. When you need something custom, Frisby.js also provides an easy way to customize and extend assertions to make your job easier, with less repetitiv
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
以下は様々なプログラミング言語のためのコード駆動型のユニット・テスト・フレームワークの一覧である。全てではないが、これらの幾つかはxUnitに基づいている。 名前: この列はフレームワークの名前及び、Wikipedia内にその項目があればそれへのリンクを含む。 xUnit: この列はフレームワークがxUnit型のフレームワークであるかどうかを示す。 TAP: この列はフレームワークがTAP準拠のテスト・ハーネスを出力できるかどうかを示す。 ジェネレータ: この列はフレームワークがデータ・ジェネレータをサポートするかどうかを示す。データ・ジェネレータはあるテストの入力データを自動的に生成し、生成した各データについてそのテストを実行する。 フィクスチャ: この列はフレームワークがテスト毎のフィクスチャをサポートするかどうかを示す。テスト毎のフィクスチャは個々のテストに対して環境の設定が行えるよ
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
あらすじ Androidのテストを自動化したいので、テストツールの選定をしてみたが、昔の記事がヒットする事が多く、何を使えばいいのかよくわからん。 とはいっても、明確に「どんなテストがしたい」という方針もなく、とっかかりとしてどんなツールがあってどのくらい盛り上がってるのかが知りたかった。 環境 Windows 7 AndroidDeveloperTools Build: v21.1.0-569685 とりあえず Win メインで。 とっかかり ロジックまわりのテスト ロジック的なものは、 JUnit 拡張の TestCase クラスを使えば何とか書けそうというのはわかった。 Androidアプリ開発テスト入門（2）：Android SDKでビジネスロジックのテストを自動化するには (1/3) - ＠IT 2011 年の記事だけど、 JUnit で書くという大前提は崩れていないはず…。 画
開発部の栗田です。End-to-Endテストの効率化をテーマにプレゼンを行いましたので概要を紹介させて頂きます。 繰り返しのテストを自動化してくれるSelenium WebDriver。（以下WebDriverと呼びます） 過去長い時間マニュアルテストをしていた私には、夢の様なツールで大好きです。 スモークテストを自動化して、随分助けて頂きました。 しかし確認作業を全部自動化出来るかというと、実はそうでは無いようです。値の検証は得意で動作テストは概ね自動化できそうですが、「見た目の不具合（レイアウトバグ）」を見つけるのは苦手だと思います。 レイアウト確認をマニュアルで行おうとすると、確認に至るまでの操作もマニュアルで行う事になります。そうなると、動作確認を自動化するするメリットが減ってしまいそうです。 そんな苦手分野を克服する方法の紹介です。 <目的は時間の削減、自動化は方法、半自動でも時
はじめに 今回はSelenium WebDriverをご紹介します。ブラウザ操作を自動化する際には最適な仕組みです。Webシステムのend-to-endテストを自動化する際には、ブラウザ操作が必要になることがあります。そんな時にSelenium WebDriverはとても便利です。 Selenium Seleniumとは、ブラウザをプログラムで動かすフレームワークです。この仕組みを使うことで、ユーザーテストなど、様々な処理を自動化できます。現在のところ、Seleniumは以下のWebブラウザを制御できます(公式サイト)。 Internet Explorer Firefox Chrome Opera Android標準Webブラウザ Safari (iPhone標準Webブラウザ) 実際に使用する際には、以下の2つの仕組みのどちらかを使用します。
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0064 号 バックナンバー Rubyist Magazine 0064 号 Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist
The biggest news in Rails 2.3 is its support for Rack, the WSGI inspired Ruby web server interface. Of all the Rack goodness that has come along lately, the one that has me the most excited is Bryan Helmkamp's Rack::Test library, of which Bryan said "Basically, I extracted Merb’s request helper code into a small, reusable, framework agnostic library." I loved Merb's request specs. I suspect that I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く