Spring Bootを使ったWebアプリのユニットテスト自動化について
Spring BootでRDBやRedisを使うWebアプリのユニットテスト自動化について書く。とりあえず、H2DBとRedisをUnitテスト実行時に自動的に立ち上げるようにしてテストの自動化が出来るようにする。 WebアプリのUnitテストWebアプリを作るとき、MySQLやRedisなどのミドルウェアにデータを保存する。開発時にもMySQLやRedisが必要になる。当然、書いたプログラムのUnitテストを書くことになるが、これらのミドルウェアにデータが保存されるとなると開発時だけでなくUnitテストのときにも同等の役割をするミドルウェアが必要になる。また、DBの中に保存されているデータの管理もしなければならず意外とメンドウ。 次の項目があるとテストが楽。 環境の自動構築 (DBを立ち上げたり、停止したり)テストデータの用意 (DBへのmigrationを含む)という、無理矢理な説明だ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
Eclipseプラグイン コード品質のカイゼン(JUnit Factory)
これはすごい!?コード品質のカイゼン化プラグイン2種：CoolなEclipseプラグイン（24）（1/3 ページ） ソフトウェアの品質と保守性を向上させるために、テストケースの作成は重要です。しかしながら、時間がない、面倒だなどの理由によりユニット（単体）テストが省略されることはしばしばあります。 また、ソフトウェアの修正や仕様変更を考慮すると、保守性の高い（分かりやすい／読みやすい）コードにする必要があります。 本稿では、ソースコードからJUnitをベースとしたたテストケースを自動的に生成する「JUnit Factory」とコードの保守性の指標であるCRAP（Change Risk Anti Pattern）を計測する「Crap4j」をご紹介します。 テストケースを自動生成するJUnit Factoryとは？ JUnit Factoryはソースコードからテストケースを自動生成し、しかも生
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか？ グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
Visual Studio 2008単体テスト機能のすべて ― ＠IT
Visual Studio 2008単体テスト機能のすべて：特集：Visual Studio 2008単体テスト機能徹底活用（前編）（1/4 ページ） 連載目次 Visual Studio 2005（以下、VS 2005）では上位エディションであるTeam Developerでのみ利用可能だった単体テスト機能が、Visual Studio 2008（以下、VS 2008）からは、Professional Editionでも利用可能になった。 VS 2008の1機能として導入されるほど単体テストが脚光を浴びるようになったのは、やはりアジャイル開発の普及だろう。アジャイルで開発する場合、単体の品質が非常に重要になる。また、リファクタリングなどで繰り返しテストが必要になるケースが多いため、テストを自動化するという考えが生まれ、単体テストの注目度はさらに増している。 本稿では、このVS 2008
テストの実行 - ソケットによる WCF サービスのテスト
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 February 2010 Volume 25 Number 02 テストの実行 - ソケットによる WCF サービスのテスト Dr. James McCaffrey | February 2010 今月のコラムでは、Windows Communication Foundation (WCF) のテスト チームでシニア ソフトウェア開発エンジニアを務める Carlos Figueira の協力を得て、ネットワーク ソケット ベースの手法を使用する、WCF サービスのテスト方法について説明します。 何をしようとしているかは、図 1、図 2、および図 3 のスクリーンショットをご覧になれば一目瞭然です。図 1 は
テスト自動化とは - ソフトウェアテスト自動化まとめサイト なんでも自動化サイト
1.V字開発プロセスモデルによる分類 1.1.要件定義 VDM 形式手法(Formal Methods)により仕様の自動検証などを行う。 1.2.システム設計 モデル検査 Spin モデル検査により状態遷移図の状態で自動検証を行う。 LTSA モデル検査により状態遷移図の状態で自動検証を行う。 NuSMV モデル検査により状態遷移図の状態で自動検証を行う。 モデル駆動 ZIPC(商用:キャッツ株式会社) 状態遷移図による検証が可能 MDA モデルを実際に動かして動作検証する。Executable Umlなどを使用して仕様を記述。 IAR visualSTATE(商用:IAR SYSTEMS) ステートマシンを設計、検証、実装できるツール。20ステートまでの無料の評価版あり 1.3.詳細設計 Enterprise Architect(商用:SPARX SYSTEMS) テストツールではないが
.NET Tools：テスト・シナリオを自動生成できるテスト・ツール「.TEST」（ドットテスト）（1/3） - ＠IT
テスト報告書など書いている時間がないのに しばしば遭遇する状況なのだが、開発プロジェクトも追い込み状態で、だれもが手いっぱいなのに、決められたドキュメントを出せ、と官僚主義的にいわれる状況がある。もちろん、適切な予算とスケジュールが設定され、ドキュメント作成のための工数も取られているのなら問題はない。しかし、予算とスケジュールが破はたんし、プログラム本体を完成させるだけの工数も不足していて、そこにドキュメント作成の工数など割り込ませる余地がないことも、しばしばある。そのような状況で、プロジェクトを崩壊させないで軟着陸させるには、どうしても必要な作業に集中する必要がある。もちろん、プログラムの性能にも信頼性にもさほど影響を与えないドキュメントの作成などに工数を取ることは、ぎりぎりの軟着陸を破たんさせかねない。それでも、ドキュメントを出せと要求されるケースが確かにある。しかも、要求をコロコロと
xDDについて考える(その1)
※このブログはデブサミ後のTwitterで話題になっていた時に下書きしていたものをそのままUPしています。 先日TDDBootCamp北陸に参加して少し考えたところもあるのですが、それは別エントリに。 最近xDD(???-driven development)という言葉が色々取り上げらています。 TDD(Test-driven development) BDD(Behavior-driven development) SDD(story-driven development) DDD(Domain-driven development) ※ここでTiDD(Ticket-driven development)のような技法を含んでいないのは、ちょっと方向性が違うかなと思ったためです。 デブサミでも話題になったそうで、Twitter上でも色々議論が流れているようですが、 ちょっといま忙しくてほと
Flex/AIRにおける単体テストフレームワーク
情報はそんなに多くなく選択肢もそれほど多くない。 おかげでどれを選ぶべきか悩む。 ①FlexUnit（0.85、0.9） 本家Adobeさんとこで公式に使用されている。 情報は一番多いようで、バージョンが違えばコードも違ってくる上 あまりバージョンを記載していないサイトが多い。 サンプルコードは比較的多いので無難？ 情報が少ないが非同期テストもできるようである。 http://sites.google.com/site/shin1ogawa/adobe-air/flexunit ②Fluint 非同期テストの情報が多い。 というより、FlexUnitとの住み分けは非同期テストができるとこにあるようだ。 サンプルコードもわかりやすかった。 http://sites.google.com/site/shin1ogawa/adobe-air/fluint ③AS3Unit 日本産のフレームワーク
テスト駆動開発やユニットテストを定着させるには
ユニットテストやテスト駆動開発(TDD; Test Driven Development)については、メリットや作り方の説明ばかりが先行している気がします。 現場にとって本当に必要なのは、どうやったら開発の現場に定着させることができるのかということではないでしょうか。 カバレッジだとか、より効果的なテストコードだとかは、ユニットテストが継続的に実施されるようになってからのハナシだと思います。 私が実際に、開発現場にユニットテストとテスト駆動開発を導入した経験から、この問題を考えてみたいと思います。コンテンツ障壁ユニットテストしたくなる環境オススメ障壁 まず、最初に意識しておいていただきたいのは、テスト駆動開発を導入する際に、障壁となるのは誰かということです。 テスト駆動開発の導入をもっともシブるのは、経営者でもマネージャでもありません。 技術者です。 普通、技術者(に限らないとは思いますが
STBBS.NET blog: Springベースのユニットテストに DbUnitを組み合わせる方法
DbUnitは、JUnitにデータベース入出力のテストを行うための各種便利機能を提供するための拡張である。 ここでは、フィクスチャのロードを行う機能にスコープを絞って DbUnitを取り上げる。 フィクスチャとは、ユニットテストの事前条件となるテストデータである。 DbUnitを使うには、クラスパスに下記のjarファイルを追加する。 dbunit-*.jar slf4j-api-*.jar slf4j-jcl-*.jar フィクスチャを使うユニットテストは、各テストメソッド毎に下記のような流れで実行される。 a) トランザクション開始 ↓ b) フィクスチャをデータベースにINSERT ↓ c) テスト対象メソッドの呼び出し ↓ d) 実行結果のチェック ↓ e) トランザクションをロールバック a, e は Springの機能で自動的に行われる。 c, d はテストケースの実装者がコーデ
ソフトウェアテストの分類
静的テスト／動的テスト （ ※↓ ） 1.静的テスト、2.動的テスト モデルベーステスト ／ モデルベースではないテスト （ ※↓ ） モデルベーステスト モデルベースではないテスト 2.1. アドホックテスト、2.2.探索型テスト ホワイトボックス・テスト ／ ブラックボックス・テスト ／ グレーボックス・テスト （ ※↓ ） ホワイトボックス・テスト （ ※↓ ） 1.制御パステスト、2.データフロー・パステスト ブラックボックス・テスト （ ※↓ ） 入力値および出力値の項目を決定する方法 1.同値分割、2.境界値分析 テストケース（テストを行う入力値と出力値の項目とその組み合わせ）を決定する方法 ディシジョンテーブルを使った方法 1.単純なディシジョンテーブルの使用、 2. 原因結果グラフ、3. 実験計画法、4. 原因流れ図（グレーボックステストの一種） 状態遷移テスト ファズ・テ
Canoo WebTest White Paper
プログラマが気にすること プログラマーとして、我々は、我々のWebアプリケーションが期待通りに動くことを確信したい。 我々の仕事を検証したい。我々は、「ああ、僕らはちゃんとやったよ。うん、動くとも。 そう、これはもう終わったんだ。もちろん、既存の機能は一つも壊してない。」と、堂々と言う為の裏づけが欲しいのです。 もし、システムにフルセットのテストを毎日適用できれば、レポートされた欠陥の原因を見つけるのは簡単です。 だってそれは、昨日チェックした何かに違いないから。 もしテストが欠陥を見つけたら、我々はすぐにそれを直したいものです。 その為に、我々はその予想外の振る舞いを再現しなければなりません。 このエラーにつながるステップはどんなものか？どのようなシーケンスで？ その中間の結果はどうなってるんだ？ このような情報がありさえすれば、エラーを追い詰めるのがどんなに楽になることか！ どん
Grails WEBTEST Plugin を試す
ドキュメントはここです。 GrailsのPluginには、先日のseleniumとcanoo WEBtestと、今のところ二つのPluginがある。 両方とも善し悪しあるようですが、どうなんだろう。ためしてみます。 とっつきやすいのは、Seleniumで、書き方とかみると、UnitTestと同じように見えるので、canoo WEBTESTの方がよさげ。 インストールは、上述URLの下の方にあるSVNから grails-webtest-0.5.zip をダウンロードして、プロジェクトのディレクトリで grails install-plugin 落としたディレクトリ/grails-webtest-0.5.zip でインストール完了 こちらは、Grails1.0.2で今のところすんなりいけたっぽい。 grails create-webtestで domainClassのWEBテストを自動で書いて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
backstop-crawl
5分で"もっと"わかるActiveReports帳票（2008年度版）－帳票完成時にチェックしておきたいポイント集
