Developer Test から Customer Test へ #swtestadvent2011 - やさしいデスマーチ
これは、「Software Test ＆ Quality Advent Calendar 2011」の12/15分のエントリーです。ソフトウェアテストや品質に関するAdvent Calendarという事で、前のエントリーは@kz_suzukiさんの「それでもやはり、品質を「予測」したい」になります。 Developer Test と Customer Test Developer Test と Customer Test とは、和田さんの講演の中で出てくる誰が何のためにテストを行うのかという観点で分類したテストの２つです。書籍「実践アジャイルテスト」の中でもテストの４象限モデルとして、ビジネス面/技術面の軸とチームの支援/製品を批評の軸によるテストの分類が紹介されていますが、ほぼ同じものと考えて良いでしょう。 Developer Testとは、開発者が開発者の為に、開発を行いやすくするため
軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ
これは、TDD Advent Calendar jp:2012 の16日目のエントリーです。前日のエントリーは、@pocketberserkerさんの「Specs2のParameterized Testのはなし」でした。 ご存じの方も多くなっていると思いますが、「テスト駆動開発（以下、TDD）」とはテストコードを先に書くテストファーストを基盤とした開発手法です。先にテストコードを書く事により、これからどのようなプロダクションコードを書こうとしているかを明確にすることができることが特徴です。このため、テストの技法というようりは設計の技法です。 テスト駆動開発を実践することにより多くのメリットを得ることができます。このことは2011年のAdvent Calendarで言及しました（TDDを学ぶべき10の理由 #TddAdventJp）。TDDは簡単に導入することができる一方で、実践するのは非常
JUnit実践入門の読みどころ #junitbook - やさしいデスマーチ
先日のエントリーではたくさんのブクマありがとうございます。Amazonでの予約も好調とのことで、うれしい限りです。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本（ソフトカバー）購入: 14人 クリック: 273回この商品を含むブログ (69件) を見るというわけで、書影も出てきました！ 思えば、JUnitのセカイというエントリーで、たくさんの「わっふる」をいただき、出版の決意を固めたわけですが、気がつくと書き始めて1年経ってました。ようやく、情報を公開できる段階まで来たわけです。 今回のエントリーでは、JUnit実践入門の発売に先立ち、本書の構成と各章の概要をお伝えします。予約を迷っている方は、本エントリーを読んだ上でご検討いただければ幸いです。
JUnit実践入門 ー 体系的に学ぶユニットテストの技法 が出ます！ #junitbook - やさしいデスマーチ
Twitter等でアナウンスしましたが、ついに著書『JUnit実践入門』がAmazonに登録されました。11/14発売予定11/21発売（1週間ずれました、すみません＞＜）で、480ページと大ボリュームとなっています。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本（ソフトカバー）購入: 14人 クリック: 273回この商品を含むブログ (69件) を見る 副題の『体系的に学ぶユニットテストの技法』は、レビュワーとしても参加していただいた@irofさんの案を元にしました（ありがとうございます！）。 この本の特徴は、この副題に集約されていると言っても過言ではありません。 フィクスチャ、モック、パラメータ化テストなどなど、xUnit Test Patt
JavaFXとSwing技術者の流出のツイートについてひとこと言っておくか - やさしいデスマーチ
昨日、札幌Javaカンファレンスという事でJavaに関するイベントが開催されたのですが、講演の内容を受けて、このツイートが広く拡散（RT）されてしまいました。一言で言えば、ツイートされた内容のある程度は事実と思われますが、非常に語弊を生みかねない内容であり、不適切な内容であったと思います。すぐに風化されて忘れられる話かもしれませんが、内容が内容だけに主催者として黙っておくのは無責任と思い、このエントリーを残しておきます。 まず、このツイートのなにが問題であるかという点ですが、「（Oracleによる）JavaFX（2.0）の方針がSwing関係のエンジニアの流出の原因」としている点です。 SunのOracleによる買収・Swing・JavaFXに関して時系列順にまとめると、次のようになります。 Swingの開発がだいたい限界となる（Java6リリース前後） AWTを引き継いでいることに対する
Java開発者の読むDjangoの設計思想 - やさしいデスマーチ
Djangoのサイトには「Djangoの設計思想」というドキュメントがあります。どんなフレームワークでもそうですが、設計思想を理解し、その流れをつかむ事で正しい利用への最短ルートです。もし、自分の思想にあわないならば問題です。可能であれば、そのフレームワークの検討を取り止めるべきでしょう。それが出来ないならば利用している時にはそのフレームワークの思想で思考することが求められます。 Djangoの設計思想は、緩く結合し、必要最低限のコードで、だが隠蔽せずに明示するという事です。DjangoではMVT（モデル／ビュー／テンプレート）と呼ばれるMVCに近い構造をとります。それらの３つのレイヤーはお互いに疎な関係を持ち、モデルとテンプレートはデフォルトの実装以外を容易に採用できるようになっています。また、ほどよく規約を適用し必要なコード量は少なくなっていまが、なんでもかんでも裏側で処理せずに、なに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
