FIT/FitNesseと多重マークアップ／多重データ構造 - 檜山正幸のキマイラ飼育記 (はてなBlog)
先週末／今週初めにかけて、Kuwataさんに説教されました（→ http://twitter.com/ckuwata/status/9061149061）。どういうことかと言うと； Catyのテストシステム／テスト体制がまったくなってない、と、そんなことです。 ウォード・カニンガムのFIT/FitNesse それで、「テストシステム作んないとね」となったわけです。テストとは言っても、プログラマがxUnitなどを使って行う構造テスト（ホワイトボックス・テスト）とは違います。実行可能な仕様記述に近いものが要求されます。そうはいっても、形式仕様記述言語（例えばOBJファミリー）を使うのはシンドイし、通常の開発作業とスムーズに接続するのが難しい。 安直に実行可能仕様記述を書ける方法として、僕が思い起こしたのはウォード・カニンガム（Ward Cunningham）のFIT/FitNesseです。おお
オンラインゲームと社内テスト
（株）Aimingの社内勉強会で使われたスライドです。開発中のタイトルの画像は削除してあります。ご了承ください。
Haskellの単体テスト最前線 - あどけない話
この記事の最新版は、githubで管理されています。 これはHaskell Advent Calendar 2012の5日目の記事です。 Haskellで作成したパッケージに対して、単体テストを書くための最新情報をお届けします。 要約 要点は4つです。 利用者に見せたい振る舞いは、doctest で書く 利用者に見せたくない振る舞いは、hspec で書く テストを自動化するフレームワークとしては Cabal を使う doctest でも hspec でも、純粋なコードに対しては、できるだけ QuickCheck などの性質テストを書く この記事で一番伝えたいのは、3) です。例題としては、Base64 という符号化を取り上げます。Base64 は知っていると仮定して話を進めますので、知らない人はあらかじめ Wikipedia の Base64 の説明でも読んで下さい。 この記事で利用するコ
oreilly.com
More than 5,000 organizations trust O’Reilly to help their teams learn the technologies of today—and be ready for what’s next. We can help yours too. It’s time to upskill your teams to leverage generative AI LLMs aren’t just the future of work—they’re the now. Learning to use large language models is vital for every business and every knowledge worker. O’Reilly has all the resources your team need
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
デフォルトでテスト成功にするという JUnit の設計判断とその功罪について
きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm @t_wada デフォルトで成功には違和感を覚えますね。。。故にIDEのJUnit自動生成ではスケルトンコードで失敗するようになっているんでしょうけど。一番怖いのがリファクタリング時にもし何かassertを消してしまった場合にも成功するというのが。 2011-05-22 16:05:24 Takuto Wada @t_wada @kyon_mm リファクタリングで assertion を消すことがあるかは疑問ですが、デフォルト成功というところには予想以上に多くの初心者が足を取られているようですね。 2011-05-22 16:11:01
Seleniumを使ったWeb UI自動テストシステムの構築でやったことまとめ - うなの日記
Seleniumを使ったWeb UIの自動テストシステムを作ったので、やったこと・感想などをまとめてみます。 テスト対象 テスト対象は、AJAXなWebアプリです。 サーバーはREST APIを提供するのみで、UIは全てJavaScriptという構成。 サポートブラウザはIE7以降,Firefox3.6以降。(特定の組織内で使うものなので、Operaなどは未サポートです。) 使用したSelenium 2.x 系列を使いました。 WebDriverと統合されたあとのやつです。 言語はJavaを使用。 テストの目的 以下を目的としました。 機能追加/不具合改修でのデグレード防止 機能追加や不具合改修に伴う動作不正を検出し、デグレードを未然に防止する。 動作確認コストの削減による開発効率の向上 ブラウザごとの動作確認を自動テストを利用して行うことで、機能実装時の確認工数を減らす。 リリース前のリ
テスト観点のとらえ方
鈴木三紀夫 @mkoszk テスト観点で僕が対立語／漢字を重視しているのは、仕様記述者がある見方で固定される（武道でいうところの居つく感じかな）というか、勝手な思い込みというか、そういうのを揺さぶるためです。この対立語／漢字を使うというテクニックは、レビューでも使えると思うわけで。 2013-02-06 15:37:43 鈴木三紀夫 @mkoszk でね。基本が「揺さぶり」なわけですから、本来ならば、レビューというよりも「分析」で行うべきと言えるわけで、そうなると、テスト観点→レビュー観点→分析観点となり、余計に混乱すると。おそらく観点は独立してあって、どのアクティビティで使うかによって名前が変わると思って異るんだけどね。 2013-02-06 15:40:02 鈴木三紀夫 @mkoszk テスト観点を用いたテスト設計を数回繰り返すと、似たようなテスト観点が現れることに気づき、このテスト観
[lib] モックとスタブの違い
TEST http://d.hatena.ne.jp/devbankh/201001 モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002 モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124 簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次
![[lib] モックとスタブの違い](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
東京Node学園で発表してきました。 - Block Rockin’ Codes
遅くなりましたが、 東京Node学園 1時限目 : ATND で「Node におけるテスト手法」について発表してきました。 追記 2011/10/24: SlideShare に上げました。 リンク 自分の発表は HTML5Rock のプレゼンツールを用いて作成しています。 とりあえず直でスライドへのリンクを張ります、余力があれば PDF 化して SlideShare にも上げたいと思います。 録画と一緒に見て頂くと良いかと思いますが、録画に映っている物とレイアウトが若干変わっています。内容は("捕捉" に書いたの以外は)一緒です。 Test it in Node.js View more presentations from Jxck :) 自分の資料 録画1 録画2(自分はこちら) Togetter 今回の発表について 「テストについて」ということで、今回は Node でテストってどん
TDDのはじめかた #TddAdventJp - 千里霧中
本エントリはTDD Advent Calendar jp: 2011の12/8の担当分の記事で、id:t-wadaさんの「右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記」に続くものです。 はじめに TDDはシンプルな原則に則った手法ですが、とっつきの悪さもしばしば持たれがちです。また一連のTDD Advent Calendarで起こった議論や会話の中でも、TDDの始め方はどうすれば良いかという話が散見されましたので、自分の担当枠では「TDDのはじめかた」についてまとめたいと思います。なお紹介するのはあくまで数ある入門方法のうちの１つです。たぶん他にも色々な良い入門方法があると思います。 全体像 紹介する入門方法は以下のようなステップバイステップの構造となります。 いつでも軽快に使えるユニットテスト環境を構築する 必要と感じたらすぐテストを活用する テスト並行を
単体テスト/結合テストなんて存在しない
テストプロセスを再定義する時代が来た。 単体テスト、結合テスト、システムテストといったテストレベルがテスト設計において寄与しているメリットはあるのか？ また、それらが結局はプロジェクトのマイルストーンをひくための単なる慣習的な単語であり、実作業に悪影響を与えているのではないか。 という疑問をもったうさみみことkyon_mmの話にソフトウェアテストクラスタの方がつきあってくださいました。 kyon_mmは現在、ソフトウェアテストを勉強しはじめたばかりの人です。 続きを読む
ソフトウェアテストの勉強室
CEGTest はJavaScriptを使って、オフラインでも動作するように実装していますが、ウェブ版ではニフティクラウド（mBaaS）を利用して、いくつかのサンプルデータを取得できるようにしました。 サンプルデータは、原因結果グラフの演習で公開しているデータが利用できます。なお、演習問題のページで紹介している模範解答はあくまで「解答例」の一つですので、仕様の考え方や何の検証を優先するのか、などによって原因結果グラフは異なります。 今後は、FacebookやTwitterなどSNSとの連携ログイン機能やログインユーザ毎のデータ保管などを考えてみます。
デシジョンテーブルを使用してテストしてみよう #TddAdventJp - 世界のやまさ
この記事はTDD Advent Calendar jp: 2012 : ATND の6日目です。 前日(5日目)は @a_suenami さんの 受託開発でTDDを導入するということ でした。 デシジョンテーブルを使ってテストしたい！ 仙台で行われている、仙台ソフトウェアテスト勉強会とデシジョンテーブルとSpockで試すTDD（ネタ） - pocketberserkerの爆走にインスパイアされ、テスト技法としてデシジョンテーブルを書いた後に、具体的にどのようにテストの自動化を行うか考えてみました。 今回は（も？）FizzBuzzをお題としたいと思います。 デシジョンテーブルとは？ デシジョン・テーブルを活用するを参照してください。以下引用します。 デシジョン・テーブル（ディシジョン・テーブル）は decision table、 つまりそのまま訳せば「決定表」です。 様々な事情・条件を考慮し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
パスワード認証
パスワード認証
bitbucketの使い方
JS開発におけるTDDと自動テストツール利用の勘所
Amazon.co.jp: Real-World Solutions for Developing High-Quality PHP Frameworks and Applications: Bergmann, Sebastian, Priebsch, Stefan: 本
