Wandering about JavaScript Testing - Mar 8, 2011 at Test.js, presented by Shibuya.js
![js テスト放浪記](https://cdn-ak-scissors.b.st-hatena.com/image/square/8daff9c8535efe795795b818c5362453190dfd71/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fwanderingaboutjavascripttesting-110308215118-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Wandering about JavaScript Testing - Mar 8, 2011 at Test.js, presented by Shibuya.js
id:torutk:20110130(インストール編)の続きです。 FEST-Swingのサイトには、最初の一歩(Getting Started)となる解説が掲載されています(以下URL)。 http://docs.codehaus.org/display/FEST/Getting+Started このサンプルコードはTestNG用なので、ちょっとだけ(アノテーション部分)JUnitでは変更する必要があります。 import org.fest.swing.fixture.FrameFixture; public class MyFrameTest { private FrameFixture window; クラス定義はJUnit 4.x と同様です。フィールドにFEST-Swing特有のFrameFixtureを定義します。 import org.junit.BeforeClass; i
Swingクラスのユニットテストを自動化するFEST-Swingは、IBMのdeveloperWorksの記事をはじめ、ユニットテスト関連の記事でしばしば目にしていました。JUnitまたはTestNGと組み合わせて使うこともできるので、普段のユニットテスト環境に追加するのも問題なさそうです。 ライセンスは、Apache 2.0です。 入手 ダウンロード場所を探してさまよってしまいました。 まず、FEST-Swingのホームページ(代表URL)は以下です。 http://fest.easytesting.org が、直接ダウンロードを示すリンクがありません。文章中に For more details, please visit the Swing Module Wiki or the JavaFX Module Wiki. とあり、"Swing Module Wiki"の部分がリンクになって
テストにおけるxhrのハンドリングについて 今までの記事は、「ブラウザで動くJavaScriptのテストを難しくしているのはDOMとxhrである」と最初にのたまった割にはDOMのことしか書いてないじゃないか、と鋭い人はちゃんと思ったのではないかと思う。 なのでJavaScriptにおける外部リソース操作の双璧をなすところのxhrについてもちょっと書く。 xhrによる外部リソースの操作を含むアプリのテストを(本物のサーバサイドアプリを使わずに)行う場合の方法は主に二つあると思っていて、 1. テストフレームワークの側で、xhrに対してレスポンスを返すようなモックcontroller(?)を書けるようにしておく 2. xhrそのものをモックオブジェクトにしちゃう 1. はつまり、pushによる自動化を行うようなフレームワークだと何らかの形でWebサーバを起動しているはずなので、その中でxhrか
前回からの続きで。 DOMエミュレーションの戦略 一方で、本物のブラウザを使わずに何らかのJavaScript実行環境でDOMをエミュレートして、その上でテストを走らせよう、という戦略もある。 この分野の大御所はEnv.js(http://www.envjs.com/)ということになっているのだけど、Env.jsのイヤンなところは導入がめんどくさい所である。何がめんどくさいって、antでビルドしなくちゃいけない。テストのためにどの程度の環境構築コストをかけられるかは状況において違うだろうが、例えばJSをメインでやっているエンジニアが「ちょっとテスト環境整えたい」っていう時にantから入れて頑張るだろうか?Javaの経験や、こういうビルドツールの導入/利用の流れに慣れている人だと全然問題ないレベルなんだけど。 というわけで、Env.jsは結構力を入れて開発されたものではあるのだろうけど、僕に
一週間のうちまる一日くらいは、「あーあのJavaScriptコードのテストってどうするのがいいかしら?」と考えている。 嘘です。多分45分くらい。 考えている時間の長さはどうでもいいんだけど、JavaScriptのテストは場合によっては中々ややこしい問題に成り得る。DOMなどの外部リソースにタッチすることのない「純JavaScript(オレオレ用語です)」であればブラウザ上であろうとRhino上であろうとNode JS上であろうと(理論上は)テストを動かせるのだが…。 JavaScriptであろうとなかろうと、外部のリソースに依存している(外部のリソースを操作する)コードはそうでないコードよりテストが面倒になる。ファイルR/WやDBの操作などIO系は勿論そうだし、どこかのサーバに何かしらのプロトコルで話しかけるようなコードもしかり。 JSのテストがややこしくなるのは、JavaScriptの
ユニットテストを記述する際に問題になるのがモックの作成方法だ。テストケース時にモックに差し替えることを想定してしたコードであればテストケースでモックに差し替えることは難しくない。しかし、差し替えるモックを作成する手間は馬鹿にならない。そこで登場するのがモックライブラリだ。 モックライブラリはテストケースで使用するためのモックオブジェクトを手軽に作成するためのものだ。実際にモックオブジェクトのクラスを定義しなくても、動的にモックオブジェクトを作成できるものが多い。 Java向けのモックライブラリにはJMock、EasyMockなどさまざまなものがあるが、本稿で紹介するのはMockitoという比較的新しいモックライブラリだ。 MockitoのWebサイト MockitoはMITライセンスで開発されているオープンソースソフトウェアで、他のモックライブラリと比較して直感的な記述でモックの挙動を設定
単体テストを“神速”化するQuick JUnitとMockito:ユカイ、ツーカイ、カイハツ環境!(16) Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション(CI)によるテストの自動化や、テスト駆動開発(TDD)の普及などにより、ユニットテスト(単体テスト)のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
Project status Please see the release notes page. Updates are announced via Twitter Follow @mockitojava and mailing list . Mockito downloads and instructions for setting up Maven, Gradle and other build systems are available from the Central Repository. The documentation for all versions is available on javadoc.io (the site is updated within 24 hours of the latest release). Still on Mockito 1.x? S
TDD is an iterative development process where each iteration starts by writing a test which forms a part of the specification we are implementing. The short iterations allow for more instant feedback on the code we are writing, and bad design decisions are easier to catch. By writing the tests prior to any production code, good unit test coverage comes with the territory, but that is merely a welc
Software Engineering RadioというPodcastの、ケント・ベックのインタビュー(以下URL)が面白かったので要点を日本語訳したい、という話がもちあがった。 http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/ 平鍋さんがご自身のブログで言い出した話である。 http://blogs.itmedia.co.jp/hiranabe/2010/10/the-history-of.html 平鍋さんの後を@urimaro(id:goh-m)さんが引き受けて、さてその後が続かないようで、「誰か続きをやりませんか?」と平鍋さんがツイッターでつぶやいたのを見て、ちょっと面白そうかも、と思ったわたくしが酔った勢いで「やりま
平鍋さんがTwitterで、Kent Beckのインタビューについてつぶやいていたのが目に留まったのですが、 リンクが張られていなかったのでソースをお聞きしたしたところ、 「協力して訳してみませんか」という話になりました。 大して英語できないし、何よりアジャイルソフトウェア開発についての知識が乏しいので躊躇しましたが 「このチャンスを逃してはもったいない」と、思い切って参加させて頂きました。 元ネタは「Software Engineering Radio」のインタビューです。 http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/ まずは、平鍋さんに訳して頂きました。訳は平鍋さんのブログに公開されています。 http://blogs.
"Software Engineering Radio" という PodCast の Kent Beck のインタビューがとても面白かったので、要点を日本語訳したい。 http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/ 1時間くらいのインタビューなので、一人で全部やるのは辛い。。。と思い、リレー形式でこれを訳するプロジェクトを @urimaro さんと(勝手に)立ち上げました!参加したい人は、ぼくか@urimaroさんがこの PodCast を訳したブログや日記に、参加意思表明のコメントをください。基本、先着でまわしたいと思います。 ではここから。正確に訳しているのではなくて、ポイントを日本語にしていきたいと思います。インタビュー
describe("Jasmine", function() { it("makes testing JavaScript awesome!", function() { expect(yourCode).toBeLotsBetter(); }); }); Documentation User Guide Release Notes API Documentation Contributor Guide Download For pure JavaScript projects: VersionSizeDateSHA1
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く