連載インデックス 「フレームワークで実践! JavaScriptテスト入門」 しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載 Capybara+Cucumber+Sinon.JSでテストが変わる フレームワークで実践! JavaScriptテスト入門(5) RubyでWebKitをヘッドレス化し、日本語でテストを記述して、スパイを使ってAjaxのテストを行う方法などを紹介
連載インデックス 「フレームワークで実践! JavaScriptテスト入門」 しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載 Capybara+Cucumber+Sinon.JSでテストが変わる フレームワークで実践! JavaScriptテスト入門(5) RubyでWebKitをヘッドレス化し、日本語でテストを記述して、スパイを使ってAjaxのテストを行う方法などを紹介
JavaScriptテストの基礎知識と使えるフレームワーク6選:フレームワークで実践! JavaScriptテスト入門(1)(1/3 ページ) しっかりとJavaScriptの“テスト”を行うために、最近のJavaScript事情やテストを取り巻く環境、今注目のテストフレームワークを6つ紹介する JavaScriptでもテストを書こう @ITの読者の方たちのほとんどは、どのような言語を主に利用しているのかなどの違いはあるにせよ、日常的にプログラムを書いている方たちが多いかと思います。 アプリケーションを作る、ライブラリを作成する、オープンソースプロジェクトに貢献するなど、皆さんがプログラムを書く場面はそれぞれいくつかあるはずです。それらプログラムを書く場面に共通して大切な習慣の1つとして、「作成するプログラムに対しては必ずテストコードを書く」ことがあるのは、誰にでも同意してもらえることでし
TDDがアジャイル開発では前提ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテストリファクタリングテスト駆動開発(TDD)継続的インテグレーションこれら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニア一人一人
TDD及びペアプロを通じてプログラミングスキルを上げるべく、ネットで公開されている『お題』について色々情報収集してみました。 お題やテーマについては、見つけ次第随時追加していきます。 Stackユーティリティ from 『車窓からのTDD』 - 車窓からのTDD こちらについては自分でも試しに写経してみました。以下エントリ。 『車窓からのTDD』を写経してみた ( JDK7 / Eclipse4.2 / Quick JUnit / Mercurial / Bitbucket ) - Shinya’s Daily Report FizzBuzz問題 from TDDBC TDDBC お題 うるう年問題 from TDDBC TDDBC お題 LRU Cache from TDDBC TDDBC お題 ワードフィルタ from TDDBC TDDBC お題 以上、ここまでの4つのお題は和田卓人
Perlの単体テスト、特にMockObjectを使ったテストについての情報が少ない気がするのでまとめてみる。 前提 モジュールは、CPAN形式であると前提。雛形は、Module::Starterで作成すると良い。 テストは、Test::Perl::Criticを入れる。 インストール $ sudo cpan Module::Starter $ sudo cpan Module::Starter::PBP $ sudo cpan Test::Perl::Critic 初期セットアップ $ perl -MModule::Starter::PBP=setup モジュールの作成 $ module-starter --module=Ysm::Example $ cd Ysm-Example $ ls Build.PL Changes MANIFEST Makefile.PL README ignor
777ブログウェイ「つくるための三種の神器」というテーマで、 本日はカヤック京都支社の技術部アルバイトで働いている高江洲(たかえす)がご紹介します。 エンジニアとして働く上で、大切だなぁと思う以下3つのことについて自分が利用している(利用し始めた、今後も継続したい)ことを3つ取り上げてみたいと思います。 1. 情報収集 2. タスク管理 3. テスト駆動開発 1.情報収集 情報収集手段といえば、はてブの人気エントリーやヤフーのトップニュース、RSSリーダーなど様々な手段がありますが、最近はもっぱらGunosy(グノシー)を使っています。 TwitterやFaceBookでログインすると、興味のある分野についてのおすすめ記事のまとめを1日1回メールで受け取る事ができます。大手のニュースサイトから個人のブログまでの幅広く、僕は朝の通勤中にひと通り目を通す感じで使っています。 使い始めて2ヶ月く
A Test-Driven JS Assessment というテストを通るようなコードを書いて、JavaScriptを学ぶものが公開されていたので、それの紹介です。 JS Assessmentは最初に失敗するテストが用意されていて、そのテストコードを通るような関数などを書いていってJavaScriptの力試し、学習をするものです。 簡単にやり方を書くと、Node環境を用意した状態で git clone https://github.com/rmurphey/js-assessment.gitなどで、リポジトリをダウンロードして、 ダウンロードしたディレクトリ内で、 nodeを使って以下のようコマンドを実行してテストが実行できるローカルサーバを立ち上げます。 実行した状態で http://localhost:4444 というURLに行けば、Mochaで書かれたテストが走った結果が表示されます
manavee.comは、2017年3月31日を以って、サービスの運営を終了いたしました。 【利用者の皆様へ】 利用者の皆様には、ご不便をおかけして申し訳ありません。 授業動画は、YouTube上で引き続き掲載しております。講義で前提になっている資料は、別のページで利用可能にしております。 しかし、授業動画を引き続き掲載するかどうかは、それぞれの先生の判断に委ねられておりますので、利用ができなくなる場合もございます。 どうぞご容赦ください。 NPO法人manavee代表理事 花房孟胤 【支援していただいた皆様へ】 本サービスについては、個人寄付、法人寄付をはじめとして、様々な形で応援していただきました。それは、本サービスの継続的な発展が期待されていたからであったと考えております。この度、manavee.comの運営を終了することで、そうした未来への可能性が閉ざされることになります。皆様の期
こんばんは。 巷では「node.jsは軽量かつ高速だよー」と噂されてるにもかかわらず、色々探しても、どれほど軽量でどれほど高速なのかを検証しているところが日本語ではあまり見つかりません。 その為、今回は、WebSocketを用いたsocket.ioの速度/メモリ使用量調査をしてみました。また、msgpack-rpc改変版をWebSocketの上に実装したバージョンと比較もしてみました。 テストは以下ですが、次の注意点を踏まえてお試しください。 デモは、どちらもさくらのVPS 512、CentOS 5.7, kernel 2.6.18-274.18.1.el5 x86_64上に構築してあります。 node.jsのバージョンは、v0.6.12。socket.ioのバージョンは、0.9.1-1を利用していますので、最新版はより良いパフォーマンスが出るかもしれません。 socket-io版は、デモ
WEBサイトに情報を入力するだけで負荷テストができるLoad Impact、GUIから操作できるApache JMeterや、コマンドラインから使うcurl-loader・httperf・Siege・Pylot・abを簡単な使い方と共に紹介していきます。 Load Impact http://loadimpact.com/ Load ImpactはスゥエーデンのGatorhole AB社が管理している、フォームに必要な情報を入力するだけで負荷テストをしてくれるWEBサイトです。 ツールをインストールしたりする必要が有りませんので、非常に楽です。 毎月5回まで無料で負荷テストができます。 それ以上は10回/$30のクレジットを購入する事になります。 トップページのフォームにURLを入れて「Run free test」をクリックすると、世界各地のいずれかのAmazon EC2サーバから負荷テス
xUTP Magazine について 『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。 最新号 0004号 巻頭言 xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 TDD Live 番外編(TDD序破Q) 編集後記 バックナンバー 0003号 xUnitester Hotlinks: 第一回 和田卓人さん(下) goos 読書会への誘い 来年(2012年)のTDDBC予報 0002号 xUnitester Hotlinks: 第一回 和田卓人さん(上) xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 mockitoでサ
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く