potatotips #7 2015/5/15 at DeNA
"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 を訳したブログや日記に、参加意思表明のコメントをください。基本、先着でまわしたいと思います。 ではここから。正確に訳しているのではなくて、ポイントを日本語にしていきたいと思います。インタビュー
平鍋さんが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.
単体テストを“神速”化するQuick JUnitとMockito:ユカイ、ツーカイ、カイハツ環境!(16) Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション(CI)によるテストの自動化や、テスト駆動開発(TDD)の普及などにより、ユニットテスト(単体テスト)のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
GAEのSDKを1.3.3にバージョンアップしたら、データストアの単体テストがコンパイルエラーに! ドキュメントを見ると、どうやらテストケースの書き方が変わったらしい。(1.3.1 - 1.3.2はスルーしていたので、実はずっと前からかもですが) ということで、SDK1.3.0の頃に書いたテストケース作成手順を1.3.3での手順に更新しておきます。ユーティリティクラスが用意されて、以前より少ないコードで済むようになってますよ。 単体テストとは? 単体テストでは、 ローカルでGoogle App Engineのサーバーを起動することなしに、 データストアにアクセスするモジュールのテストを記述できます。 公式なドキュメントはこちら。日本語のドキュメントはまだ更新されていない(2010-05-01 現在)ようなのでご注意。 概要 必要なモジュールをプロジェクトに追加 テストケース内でLocalS
JUnitとEclipseを使って学ぶ、“テスト”の常識:Webアプリの常識をJSPとStrutsで身につける(10)(1/4 ページ) 本連載は、JSP/サーブレット+StrutsのWebアプリケーション開発を通じて、Java言語以外(PHPやASP.NET、Ruby on Railsなど)の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です いまさら聞けない、“テスト”の考え方やポイント 今回は、「テストの常識」と題し、Webアプリのテスト方法を説明したうえで、実際にJUnitを使用してWebアプリのテストを行ってみましょう。 そもそも、テストとは何のために行うのでしょうか? ただ何となくテスト項目を作成して実施するのでは、作成したWebアプリの品質が低かったり、開発コストが高くなったりと後々、後悔することになります。まず「テストをなぜ行うのか」「何を
slim3 でプログラムを生成すると、自動的にテストコードも作成してくれます。 ただ、テストコードは jUnit 4.7 を使用しているため、3.x 系とは色々と違うところがあります。 (私は知らなかったのでハマりました…) 今回は、jUnit 3.x 系との違いをまとめてみました。 具体的な違い 1.@Testアノテーションの存在 jUnit 4.x 系では、@Test アノテーションのついているメソッドがテストケース(テストメソッド)になります。 jUnit 3.x 系では、テストケースにいちいち testXxx() という名称をつける必要が(事実上)ありましたが、jUnit 4.x 系では、テストケースに好きな名称をつけることができます。 メソッドの命名に自由度が広がるので、テストコードの可読性・保守性を高められそうです。 ※Eclipse や Maven で jUnit 3.x 系
下記のAppEngineアプリケーションの自動テストシリーズに続く、第五回目です。 AppEngine用のアプリケーションの自動テストについて(1) #AppEngine 用のアプリケーションの自動テストについて(2) - Datastoreに関するテスト #AppEngine 用のアプリケーションの自動テストについて(3) - メール送信に関するテスト #AppEngine 用のアプリケーションの自動テストについて(4) - TaskQueueに関するテスト URLFetchサービスのテスト?シミュレート? URLFetchのテストと言っても、目的は2種類分かれると思います。 ひとつは「想定通りのリクエストが組み立てられているか」という事です。 こちらはこれまで説明してきた通りの 「サービスをフックしてサービスへリクエストとして送信されるバイト配列をJavaオブジェクトとして組立て直す」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く