『好きな食べ物がみつからない』を読んだ 古賀及子さんが『好きな食べ物がみつからない』という本を出した。中に僕の記事に触れてくれるパートがあって、その関係でいただいて早めに読むことができた。 これは古賀さんが好きな食べ物を探す本。エッセイというと、短い話がたくさん入っているものしか読んだこと…
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
多くの開発プロジェクトで試験の自動化をきちんと行えているところはどのくらいの割合あるのでしょうか？理想的なプロジェクトでは単体試験はもちろん、画面の打鍵テストや性能のベンチマーク試験など多くの試験を自動化するのが良いとされていますが、私の経験上そこまでできているプロジェクトは時間やスキルの制約から皆無でした。 ただし、最低限JUnitの単体試験だけでもきちんと作成、メンテナンスできているだけでも相当優秀で、それだけでもまったく試験の自動化をやっていないところに比べるとプログラムの品質には雲泥の差があるように思います。 試験の自動化がしやすいアーキテクチャーの構築は開発に携わるアーキテクトの仕事としては非常に大切なポイントであると思います。そして、試験の基本である単体試験*1だけに絞って考えてみても モックオブジェクトを利用した単体試験 データベースにデータを挿入して行う試験 DIコンテナー
自分は Ruby コードの単体テストに RSpec を使ってるんですが、プログラムコードやテストコードを更新する度にいちいち手動でテストを実行していました。 autotest というのを使えば自動でテストが実行されるという話は聞いていたので、ちょっと調べてみました。 使用しているバージョンは RSpec 2.3.0, ZenTest 4.4.2 です。 インストール autotest は ZenTest という gem に入っているのでそれをインストールします。 # gem install ZenTest 実行 プロジェクトのトップディレクトリからのツリーが次のようになっている場合、 ./lib/hoge.rb ./lib/fuga.rb ./spec/hoge_spec.rb ./spec/fuga_spec.rb次のように実行します。 % autotest --style rspec2
はじめに¶ このページは，Google Mock のドキュメント類を日本語訳したものです．翻訳に関しては，誤りのないように配慮しておりますが，至らない点も多々あるかと思います． 誤訳・誤字・脱字や不適切な表現を発見されましたら， ご連絡頂ければ幸いです（ http://opencv.jp/forum ）． 原文は英語であり，この訳文はオフィシャルなものではありません．なお，免責事項として，本訳を利用者が利用するにあたり，いかなる損害に対しても訳者はその責を負いません． Google Mock プロジェクトページ： http://code.google.com/p/googlemock/ ドキュメント¶ Google Mock のドキュメント（SVN trunk 版） このページには，Google Mock の SVN trunk 版 に対するすべてのドキュメントページが挙げられています．
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
[追記] 2013/9/1 三年前の記事が未だに読まれているようなので、一応書いておきますが、あれから色々変わってもっと良いものも出ています。 QUnit でも別に問題はないですが、今から QUnit を使うよりは http://visionmedia.github.io/mocha/:title=mocha] とかの方が個人的にはお勧めです。とにかく、今は色々あるのでもっと別の選択肢調べて見ることを個人的にはおすすめします。別に QUnit は使わないほうが良いとは言いません。 JavaScriptのテスティングフレームワークはいろいろありますが、自分は今主にQUnitを使っているので、少し使い方をまとめて見たいと思います。 [追記]今回作成したソースを上げました。ninja.js QUnit とは QUnitはもともと、jQueryをテストするために開発されたJavaScript Un
xUnit.NETは.NET 2.0以上で動作するテストツールで、MicrosoftのBrad Wilson氏とJames Newkirk氏が中心となって開発を進めています。xUnit.NETは拡張性の向上、カスタム属性の減少、メソッドごとのインスタンス生成を特徴としており、Moq、Ninject、Oxite、KiGGなどのOSSにも採用されています。以下、xUnit.NETの導入方法、テストコードを紹介します。 xUnit.NET の入手と環境設定 xUnit.NET はCodePlexから入手できます。執筆時点での最新バージョンは1.6です。「xunit-1.6.zip」をダウンロードして適当なフォルダ(本稿ではC:\Sample\xunit)に展開します。これには以下のようなファイルが含まれています。 xUnit.NETのWebサイト インストールウィンドウ(xunit.instal
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー みなさんテストしてますか？ Pythonには沢山の便利でステキなテストツールがあります。標準ライブラリに入っているunittestやアジャイルドキュメンテーションとも呼ばれるdoctestなど，標準の機能だけでもかなり強力なのですが，外部のツールを使うとより快適なテストライフが送れるのです。 python.orgにあるPython testing tools taxonomy(Python用テストツールのまとめ)というページがあり，ここに有益な情報が集まっているので例によって超訳してみました(ユニットテスト関連のみ)。 ツール カテゴリ 作者 ツールが含まれるフレームワークなど 特徴
ruby 界隈でよく使われている自動テストツール autotest の Symfony + Lime 用スタイルを書いて公開しました。 プロジェクトのローカルルールに合わせてあるのですが、軽く手を入れれば他のプロジェクトでも、また Symfony や PHP 以外でも使えると思います。 TDD で書いていないと不安が高じて動悸と息切れが始まる red-green-refactoring を唱えなさいとじっちゃに言われた growl の red を見ないとコードが先に進まない よくある話だと思います。 まずテストが無いと何も始まらない！書いたテストはがんがん自動実行して使い倒したい！ となるとやはり、自動テストの出番ですね。 インストール手順 autotest コマンドをインストールします。rspec + autotest + インストール辺りでぐぐってください。 mac の人は a
メタデータからテスト件数を取得する 前回はテストファイルやテストデータの数からテストプランを計算するモジュールを紹介しました。今回はその続きとして、テストファイルのメタデータからテストの数を求めるモジュールを紹介していきましょう。これらのモジュールの多くは1994年にケント・ベック（Kent Beck）氏がSmalltalk向けに書いたSUnitを祖先にもつ、いわゆるxUnit系のフレームワークに属するものですが、Perlにはそれ以前からTest Anything Protocolを使った独自のテスト手法が存在していたため、Javaなどで使われている同種のフレームワークとはやや毛色の違う部分もあります。一般的にはクラスをひとつ書くたびに対応するユニットテスト用のクラスを書くのがよいように言われていますが、ここではもっとゆるく、テストを自動的に検出してくれるだけでなく、テストの事前事後になん
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
Test::More の 0.94以後(2009-09-02)では subtest という機能が導入されており、これが非常に便利なのだが意外と利用されていないようなので、ちょっと宣伝させてもらいますね。 以下は Data::Recursive::Encode のテストケースなのだが、似たようなケースが頻出するわりに、抽象化するのが面倒だし、わけわからなくなること必至であり、かつまた、こんなものを複数のファイルにわけていてはメンテナンスが面倒なことは考えるまでもない。 チミチミと似たような数行のテストをかいたファイルを複数つくるぐらいならば、このように subtest の利用を考えるべきだとおもう。 ただし、これも他のツール同様、なんにでも適用すればいいというものではなく、使い方をまちがえれば、関係ないものがゴッチャリはいった .t ができあがるので注意するべきだろう。 use strict
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
When working with large test suites, using procedural tests for object-oriented code becomes clumsy after a while. This is where Test::Class really shines. Unfortunately, many programmers struggle to learn this module or don't use its full power. Please note that article assumes a basic familiarity with object-oriented Perl and testing. Also, some of these classes are not "proper" by the standards
Twitterにて。Uncle Bob Martine曰く: Testing through the GUI is just SO seductive. But the diseases you get in the end just aren't worth the momentary pleasure. GUIを通したテストってのはすっごく魅力的だけど、その一時的な快楽と引換に待っているのはヤバい病気だ。 本来Unit TestでやるべきようなテストをGUI経由で--例えばSeleniumとか--叩くのは非効率だし、実は肝心な部分をテストできていない(しかもテストできてないことに気づかない)結果に終わるのがオチ。
原文(投稿日：2009/11/04)へのリンク "TDDによってペースが鈍ると考えている人は石器時代で生きつづけているようなものだ"と主張したことで議論を巻き起こしたブログに続き、Bob Martin氏は現実のTDDの適用可能性、役割、恩恵に対する深い洞察を試みている。 氏はまず"TDDはアーキテクテャの代替物か？"という大きな問題を取り上げ、実例を背景に「そうではないですが、しかし...」と答えている。 いちから始めて次々にテストケースを書いていくことで実行可能なアーキテクチャを生成できるという意見は全くばかげたことです。テストしないという決断を下す必要もあります。 もちろんこれらの決断の多くはできるだけ先延ばしにすることができるし、そうすべきです。例えば、データベーススキーマは恐らく長い時間待つことが可能なものです。Spring、JSF、Hibernate、JPAなどを使うかどうかの決
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く