JJUG CCC 2012 fall / 札幌Javaカンファレンス2012での発表資料です。 ソースコードは https://github.com/shuji/demo-refactering-unittest から取得してください。Read less
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス(の部品)やオープンソースプロジェクトです。 まず、以下の2点を原則として考えています。 origin masterを壊さない origin masterの(1st parentをたどるツリー)にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
クライアントからシステム開発案件を受注し、開発成果物を納品する際に、エビデンスとして、Excel上に貼り付けたスクリーンショット(以下、スクショ)を、成果物の仕様書や納品書と共に納品する場合がある。この作業は、クライアントに「こういったテストを実行しました」という証拠を提示するものとなる。クライアントに成果物の機能や制限事項などを説明する場合に大変に有効なものとなっているのが現状だ。 実際、Excel上に記述したテスト仕様書や納品書にスクショを張り付けて、成果物の一部として納品しておくと、後々何らかのトラブルが発生した場合も問題解決に大きく寄与することになる。 しかし現実問題として、成果物の機能のスクショを、Excel上に手作業で延々と張り付けていく作業は単純作業であることもあり、開発者にとっては苦痛この上ない作業だ。 そこで、そのような作業を自動化し手助けをしてくれるツールとして「Sel
先週の4/26に開催された第38回HTML5とか勉強会「Webアプリ×テスト最新事情」で、JavaScriptのテストについて話させてもらいました。 発表資料はこちら。 JavaScript Unit Test Why? What? How? from teppeis 恥ずかしいビデオはこちら。http://www.ustream.tv/recorded/31976691 発表内容は、前回のWEB+DB PRESSで書かせてもらった内容の要約版+アルファでした。 個人的には、最近ようやく実践テスト駆動開発(通称GOOS本)を読んで、2重のフィードバックループとアジャイルテストの4象限、TDD/BDDなんかが自分内でガシーンと、ザ・ワールドが時の歯車をがっちり掴んだときのようなつながった感があったのですが、まだ言語化するには早かったらしくあまりうまくは伝えられなかったかなと反省しました。 座
答え:テストできるように作る 周りでAndroid開発してる話を聞くのですが、どうもテストがしづらかったり、修正が大変だったりする模様。ここを直してあそこがバグるみたいな。 本屋で参考になりそうな本を探すも、入門系かリファレンス系が殆どで、「どういう設計にするべきか?」とか「Android Test」とかAndroid向けフレームワークの話がさっぱり無い。そんな状況なので、入門書片手にアプリを書き始めた人は、ViewとLogicを始め、色々なものが適切に分けられてないコードを作り、テストの無いレガシーコードが量産されていくのかな、と。 そういう分けで最初の結論になります。 ちょうど、ちょっとしたAndroidアプリを書いてみようと思ってたので、ここら辺を参考に実際のアプリに先立っていくつかのフレームワークを組み合わせたAndroid-Development-Suiteを作成。 いわゆるサン
Uncategories Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み こんにちは。QAの井上です。 今回は現在QAチームで行っている自動テストに関する課題、それに対する取り組みについて紹介します。 まだまだ詰めが甘いところがあると思うで、フィードバックいただけるとうれしいです。 早速ですが、QAチームではCIツールにJenkinsを使用していて、約8割がSeleniumによるテストケースでできています。 テストケースの作成から実行まではざっくりですが、以下のようになっています。 - テストケースはFirefoxのIDEを使用して作成 - 作成したテストケースはSVNに保存 - 毎日夜中に最新のソースコードに対してテストを実施 - テストの実施は、Jenkinsのseleniumhqプラグインを使用して、複数台のクライアント(Windows)上でSelen
AndroidプログラミングのTOPへ これはWebアプリ開発者にとっても,モバイルアプリ開発者にとっても朗報である。 下図は,「Webアプリ + モバイルアプリの,自動テストツールの技術動向」を表す。 ┌─── Webの自動テスト────┐ ┌モバイルの自動テスト┐ | | | | | Selenium WebDriver | |Robotium─→Sirocco | | (2004, (2009, Google)| | (2010) (2010) | | ThoughtWorks) | | | | | | | | └────────┐ | | | | | | | | | | | | | | | | ↓ ↓ | | ↓ | | Selenium WebDriver | | NativeDriver | | (=Selenium 2.0, 2011/07〜) | | (Google, 20
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。 予期せぬバグはスケジュールに致命的な影響を与える。 手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。 達人プログラマーはどうするのか?p.241 第8章 達人のプロジェクトより 早めにテスト、何度もテスト、自動でテスト 書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。 このテストをあながた手を動かしてやっている暇はありません。 あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。 自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く