hayst.comThis domain is registered at Dynadot.com. Website coming soon. hayst.com 2023 著作権. 不許複製 プライバシーポリシー
DevelopingJdbcApplicationsTestFirst
本ページは、http://mockobjects.com/wiki/DevelopingJdbcApplicationsTestFirstを勝手に翻訳したものです(2004/2/20にフリーマンに了解を得たとは言え向こうは日本語は読めないので翻訳の正当性が保証されるわけではない)。公開物に対するリンクと勝手に翻訳は一見似ていますが、そこには大きな差があります。それは翻訳が正しいかどうかの保証がないっていうことです。したがって、この翻訳を鵜呑みにせずに、原文も参照されることを勧めます。 なお、ここでは強い意志をもってできるだけ意訳するようにしています。すなわち、僕にとっては日本語の文章記述練習を兼ねています。より透過的にフリーマンの記述を読みたければ、原文は読みやすいので、そちらをあたってください。 [TDD] About MockConnectionのように、最新のMockObjectsで
第11回 テストの資産価値 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325613 宮澤さんからの質問 そうですね。またよい質問をいただきました。「テストの資産価値」という話をこれからしたいと思います。 小さいテストがすべて真っ赤っかに…… 私も「不安」ですし、新人の人だったら不安がいっぱいでしょうから、たくさんの小さいテストができることはあると思います。 その場合、小さい単位のテストを基盤にして、それらの学習結果やそれらの不安をもとにしたテストコードと、それらの上で実際に書かれたコードが存在することになります。 それに対して仕様変更があった場合、小さい視点のテストが全滅してしまう、もしくは真っ赤っか（テスト失敗だらけ）になってしまうということはよくあります。 そのときに、そのテストを一つ一つ直していくことに意味があるのか、割に合うのかという話が出てくると思います。実プロジェ
［動画で解説］和田卓人の“テスト駆動開発”講座：第4回 ナントカテスト ―― ユニットテスト，単体テスト，機能テスト，結合テスト，受け入れテスト｜gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第4回ナントカテスト ―― ユニットテスト、単体テスト、機能テスト、結合テスト、受け入れテスト ニコニコ動画：https://www.nicovideo.jp/watch/sm2195489 前回、テストをDeveloper Testing、Customer Testing、QA Testingの3つに分類しました。ここまでで何か質問はありませんか？ 担当からの質問 「受け入れテスト」というのはCustomer Testなんですか？ はい、そうです。 テストというと、よく「○○テスト」という言葉を聞くと思います。たとえば「受け入れテスト」以外にも、「ユニットテスト」「単体テスト」「機能テスト」「結合テスト」など、いろんな何々テストという言葉があります。質問にお答えする前に、まずテストの分類に対する視点を整理しましょう。 テストの分類に
第10回 テストの最小単位は不安 | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2316665 クロコさんからの質問 なるほど。連載第5回でも、「写経をやってみた、リズムもわかってきた。でもいざ自分でやろうとすると、最初はどういうテスト書こうかとか、どういう単位でテストを書けばいいのかとかで詰まってしまう」という質問をいただきましたね。 私は実は、明確にこういう単位でテストを書くべしという決まりはないと思っています。 不安をテストで表現する では、私がどういうときに小さいテストを書いているかというと、私は「不安」を最小単位の基準としています。不安を手がかりにしてテストを書きます。 私たちプログラマの手を止めるものは何でしょうか。私は「不安」だと思っています。「もしかしたら」という感情ですね。「もしかしたら、自分の書いているコードは間違っているかもしれない」「もしかしたら、ライブラリ
第14回 テスト厨、TDDの壁、DBやGUIのテスト | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2325911 宮澤さんの発言「俺ってばスゲー」という地点に達したあと、TDDの壁みたいなのはありましたか？ 俺ってばスゲー、TDDもスゲーと思ってから、はい、TDDの壁にはぶつかりました。「テスト駆動でできるところと、できないところがあると認識しなければならないところ」ですね。簡単に言うと、GUIを伴うテスト、画面を伴うテストっていうのは、すごく難しい。というより、割りに合わない感じが強いんですね。これは今でもそうです。 「テスト熱中症」「テスト厨」 テスト駆動開発をマスターするきっかけをつかんで、これはイケる！ これは素敵だ！と思った人が次に出会うのは、「テスト熱中症」「テスト厨」時代です。テストがすごく好きになり、テストに熱中する時期がやってくるんですね。 テスト熱中症（test infected）
『テストパターン』
JUnitとエクストリームプログラミング（XP）の普及によって、テストファーストやテスト駆動開発（TDD）が身近になった。Kent Beckが説くみたいにテストから書き始める、なんて極端なことをする必要はないと思うが、開発中のソフトウェアにそれなりの品質を保証しようとするなら、ソースコードにテストスイートくらいは付いてくることが期待されるようになっている。 とはいえ、実際にJUnitでテストを書いてみると、思ったより難しい。難しいので、あまりテストを書かなくなる。 なぜ難しいのかというと、テストコードというのはその性質上、「宣言的」だからだ。テストは、「何々という条件を入力したときに、何々という結果が発生しなければならない」というような、プログラムが満たすべき事前条件と事後条件をチェックする。分かりやすく言うと、「What」の記述だ。 一方で、たいていのプログラマが普段書いているプログラム
Latest topics > モックが必要な場面、モックが有効な場面 - outsider reflex
Latest topics > モックが必要な場面、モックが有効な場面 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « タブの追加・削除のアニメーション Main JsDoc ToolkitでJavaScriptコードモジュールのDoc Commentを出力する » モックが必要な場面、モックが有効な場面 - Aug 11, 2010 モック（Mock）とスタブ（Stub）の違いがよく分かってなかったんだけど、何が違うのか、そしてモックはどう使う物なのかということを、すとうさんに教えてもらって今更理解した。あとで会社のブログに書くつもりだけど、メモとして要点だけまとめておく。 テストは基本的に、粒度の細かいブラックボックステストにした方がいい。
Buildbot で継続的インテグレーション - mixi engineer blog
こんにちは。パートナーサービス部の加藤和良です。 前回、mixi における開発者テスト について説明しました。だいぶ間があいてしまいましたが、今回は、そのテストを定期的に実行する 継続的インテグレーション の仕組みを紹介したいと思います。 テストが遅い 実は、mixi のテストは「遅い」という大きな問題を抱えています。 Micheal Feathers は『レガシーコード改善ガイド』のなかで、単体テストが高速に実行できることの重要性を解き「単体テスト」を厳しく定義します。 次に当てはまるものは単体テストではない。 データベースとやり取りする ネットワークを介した通信をする ファイルシステムにアクセスする 実行するために特別な環境設定を必要とする (環境設定ファイルの編集など) 上記に該当するテストが悪いというわけではない。多くの場合において、そのようなテストを書く価値はあり、しばしばテスト
Python 2.7に搭載の新unittestモジュールはスーパークール — TRIVIAL TECHNOLOGIES 2.0
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー 先日リリースされたPython 2.7がなかなかいいかんじ。set型のリテラル，set/辞書内包表記やviewなど3.xからのバックポートを多く含んでいる。細かいところではネットワーク系モジュールのIPv6対応が進んでいたり，Python 2系最後のリリースとうたわれているだけあって，かなり意欲的なリリースとなっている。 なかでも，標準のunittestモジュールがものすごく大きな進化を遂げていて，かなり魅力的になっているので簡単に紹介したいと思う。 テストディスカバリ 単体テストは，たいていモジュールやクラス，または機能ごとに個別にファイルを作り，テストコードを書く。大抵のプロジェク
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
第16回 Haskellでのテストの自動化を考える
皆さんはプログラムが正しく動作することをどうやって調べていますか？ いちいち実行して確認している人もいるかもしれませんが，多くの人はツールや自作のプログラムを使って何らかの形でテストを自動化しているでしょう。ここ10年くらいで「テストの自動化」はプログラマにとってなじみの深い概念になりました。今回はHaskellでのテストの自動化を取り上げます。 型検査を利用する 実は，Haskellを使っていれば，すでにテストはある程度自動化されていると言えます。 第12回と第13回で説明したSTMでは，STMモナドという特別なモナドを使い内側にI/Oアクションを記述できなくすることによって，取り消し不可能なアクションが入り込むことを防いでいました。 Prelude Control.Concurrent.STM> atomically (writeFile "sample.txt" 12) <inter
文字列の先頭と末尾にあるスペースの削除 - みずぴー日記
30分プログラム、その614。文字列の先頭と末尾にあるスペースの削除 via http://gauc.no-ip.org/awk-users-jp/blis.cgi/DoukakuAWK_174。 元のやつでは、正規表現による文字列置換をしてるけど、ここではdropWhileを使ってみた。別に正規表現が嫌いという分けじゃなくて、こっちのほうが手軽なだけ。 あと、特に意図はしてないけど、ポイントフリースタイルになった。やったね。 使い方 $ echo "\t test \t " | od --format=a 0000000 ht sp t e s t sp ht sp nl 0000012 $ echo "\t test \t " | ./trim | od --format=a 0000000 t e s t sp ht sp nl 0000010 ソースコード import Test.
いまさらTDDを見直す - Inemuri nezumi diary(2007-07-25)
_ いまさらTDDを見直す いまさら「フェルマーの最終定理 (新潮文庫) 著:Simon Singh 訳:青木 薫」を読んだ*1。この本はすごくいい。 この本が指し示していることのひとつは、皆、汗かいて土木作業してたってことだ。ピタゴラス、ユークリッド、…、オイラー、ガウス、…、ソフィー・ジェルマン、…、志村=谷山…。 綺麗な命題/予想を産み出した彼/彼女らは、手を動かす計算をむちゃくちゃな量やってる。 型理論によれば、型は命題で、実装は証明にそれぞれ対応する。そして、テストは、実装の仕様記述の一部に対応する。具体例を計算することはテストすることだ、と言える。 つまり、XPとかTDDとか誰かが言い始めた2000年前から、数学家はひたすらテストファーストだったってこと。証明/予想を言い終えた後は、テストの結果は焼いて捨てたから残っていない。 反論もありそうなことを敢えて言うが、私自身、テスト
Inemuri nezumi diary(2007-08-23)
_ 独りで始める Concrete and Specific Programming (CSP) 実践 昨日のエントリから引き続いて。設計とテストスイーツを先に書き、実装を後に書く Concrete and Specific Programming を実際に行ってみます。ただ、私も人に教えた経験がないものですから、何を対象にすればいいものやら、わかりません。 そこで、プログラマの誰もが馴染んでいる単純な「データ構造とアルゴリズム」から具体例を取りたいと思います。 _ 具体例その1. Stack 一つ目の具体例としてスタックを取り上げます。 まず、夢メモを書きます。 Stack 夢メモ 日付:2007-08-23 作るもの: スタック(メソッドはnew, pop, pushのみ)。 どのように作るのか: 読者層に配慮して Ruby で。 Ruby についてくる Array を一つインスタンス
仕様に基づいたテストスイーツを書く - Inemuri nezumi diary(2007-08-22)
_ 独りで始める Concrete and Specific Programming(CSP) エクストリーム・プログラミング(XPとして知られている)は、ビジネス側と開発側の両者が共通の達成可能なゴールに集中するための、ビジネス及びソフトウェア開発の規律である。 Kent Beck [XPエクストリームプログラミング実行計画(The XP Series), Kent Beck and Martin Fowler, Foreword by Tom DeMarco 序言より引用] このエントリでは、開発側の夢を実現するためのプログラミング技術 Concrete and Specific Programming を提唱します。 趣味としてのプログラミングは、ビジネスとは無関係です。それは、人生に与えられた有限の時間の使い道として、あなたが選んだ選択肢です。なぜ、プログラミングを趣味とするのか、
Inemuri nezumi diary(2006-09-06)
_ RushCheck - a lightweight random testing tool for Ruby Ruby のランダムテストライブラリ RushCheck を公開している。これは3年前からつくり出したもので、PC で眠っていたものを今年の夏休みに公開したものである。Haskell の QuickCheck を Ruby でも使いたいなあと思ったのがきっかけであった。 ランダムテストというのはテスト手法のひとつである。テストケースに入力するデータをテストインスタンスと言うことにしよう。このとき、テストインスタンスを自動生成するというのがランダムテストの特徴である。たとえば文字列を入力とするテストならば、ランダムテストではその入力文字列をランダムに生成する。いくつもの異なった入力をランダムに生成して、同じテストケースを自動的に何度も実行するというテストの考え方である。 _ ラン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20100828/p01/
https://www.itarchitect.jp/print/?menu3=34462
haskell-jp:128