プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
スタブ・モックは本当に悪者なのか？〜テスト駆動開発をやめて、なお残すべき習慣とは (2)
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
CakePHP + PHPUnitでの TDD 超入門 - Qiita
はじめに このエントリーは TDD AdventCalendar 2013 の第21目の記事です。 前日のエントリーは、tq_jappyさんによる「レガシーテストコード改善ガイド #TddAdventJp」でした。 わたしも Advent Calendar 初参加です。どうぞよろしくお願いします。 この記事では主に TDD とはなにか聞いたことはあるけど、実践したことはない、というような方を対象に、 CakePHP と PHPUnit を使った TDD の進め方をご紹介したいと思います。 CakePHP と PHPUnit はそれぞれ開発環境にインストールされて、使える状態になっていることを仮定します。 準備 まずは CakePHP インストール直後の、この画面が出るところから始めます。 何をテストするか 今回はテスト対象として、ソーシャルゲームでよくあるような処理を取り上げてみたいと思い
【javascriptを使う人に知って貰いたい（エンジニア、デザイナ問わず）】karmaを使ったテスト駆動開発入門（ついでにJasmineも）
$ karma init Which testing framework do you want to use ? Press tab to list possible options. Enter to move to the next question. > jasmine Do you want to use Require.js ? This will add Require.js adapter into files. Press tab to list possible options. Enter to move to the next question. > no Do you want to capture a browser automatically ? Press tab to list possible options. Enter empty string to
TDD(テスト駆動開発)を学ぶための動機になる話 | Act as Professional
TDDがアジャイル開発では前提ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテストリファクタリングテスト駆動開発（TDD）継続的インテグレーションこれら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニア一人一人
QUnitの基本的な使い方 - but hopeful
[追記] 2013/9/1 三年前の記事が未だに読まれているようなので、一応書いておきますが、あれから色々変わってもっと良いものも出ています。 QUnit でも別に問題はないですが、今から QUnit を使うよりは http://visionmedia.github.io/mocha/:title=mocha] とかの方が個人的にはお勧めです。とにかく、今は色々あるのでもっと別の選択肢調べて見ることを個人的にはおすすめします。別に QUnit は使わないほうが良いとは言いません。 JavaScriptのテスティングフレームワークはいろいろありますが、自分は今主にQUnitを使っているので、少し使い方をまとめて見たいと思います。 [追記]今回作成したソースを上げました。ninja.js QUnit とは QUnitはもともと、jQueryをテストするために開発されたJavaScript Un
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JS開発におけるTDDと自動テストツール利用の勘所