GitHub - catchorg/Catch2: A modern, C++-native, test framework for unit-tests, TDD and BDD - using C++14, C++17 and later (C++11 support is in v2.x branch, and C++03 on the Catch1.x branch)You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Haskellでデザインレシピ - あどけない話
お茶の水女子大学 理学部 情報科学科 准教授 浅井健一さんインタビューを読んで、思い出しだので書いておきます。 デザインレシピを使ったプログラミングを実践するなら Haskell が最適です。以下に簡単な例を示します。 目的 作成するプログラムが何をするのかを考える。何を受け取り何を返すのかを特定し、それをもとにプログラムのヘッダを作成する。 例として、数字の文字列を取り整数を返す関数 stringToInt を考えましょう。まず、関数の型注釈を書いて、本体を undefined にしておきます。 module Foo where -- | Converting 'String' to 'Int. stringToInt :: String -> Int stringToInt = undefined コンパイルが通ることを確認しましょう。 例 プログラムの動きをより明確かつ具体的にするた
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
はじめての Chromium Land - steps to phantasien(2011-02-19)
はじめてまじめに ...といってもたぶん 500 行くらい... WebKit ではなく Chromium 側のコードを書いている. まだレビューをとおってないため現在形. でかすぎてビルドの遅い Chromium より Mac WebKit をいじる方が快適という同僚もいたけれど, コード自体は Chromium の方がだいぶモダンだよなあ. 普通に unit test が書けるありがたさといったらない. Developer testing まず gtest が良くできていて感心する. static initializer を使ってケースの登録を分散化したり, コマンドラインフラグでテストケースを一覧選別できたり, プロセスを分離してクラッシュに強くしたり, クラッシュしたテストケースの backtrace をだしたり. でかい C++ のコードベース相手にテストをスケールするための工夫
Island Life - コードに対するテストも要るんじゃないかなあ
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...ループを使わずに1から100までMore... 最近のコメント shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハイポハイポのシューリンガン (2022/04/02)ベアトリーチ
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
C++用xUnitでのテストの書き方 - 2009-11-07 - ククログ
注: 長いです。 スクリプト言語でのxUnit実装を使ったことがある方なら、テストを定義するだけでテストが実行されることが当たり前ではないでしょうか。c2.comのWikiによると、これはTest Collectorというそうです。定義したテストを自動的に集めてくる機能のことです。 一般的にTest Collectorの機能は言語が提供するリフレクション機能やメタプログラミング機能を使って実現されます。 例えば、Rubyのtest-unit 2.xでは、リフレクションを使う方法とメタプログラミングを使う方法の両方をサポートしています。リフレクションを使う方法ではObjectSpace.each_object(Class)ですべてのクラスを取得し、その中のTest::Unit::TestCaseのサブクラスを集めます。メタプログラミングを使う方法ではTest::Unit::TestCase.
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
【ハウツー】シンプル&タイプセーフなJava用モックライブラリ"Mockito"の魅力 (1) Mockitoとは? | エンタープライズ | マイコミジャーナル
ユニットテストを記述する際に問題になるのがモックの作成方法だ。テストケース時にモックに差し替えることを想定してしたコードであればテストケースでモックに差し替えることは難しくない。しかし、差し替えるモックを作成する手間は馬鹿にならない。そこで登場するのがモックライブラリだ。 モックライブラリはテストケースで使用するためのモックオブジェクトを手軽に作成するためのものだ。実際にモックオブジェクトのクラスを定義しなくても、動的にモックオブジェクトを作成できるものが多い。 Java向けのモックライブラリにはJMock、EasyMockなどさまざまなものがあるが、本稿で紹介するのはMockitoという比較的新しいモックライブラリだ。 MockitoのWebサイト MockitoはMITライセンスで開発されているオープンソースソフトウェアで、他のモックライブラリと比較して直感的な記述でモックの挙動を設定
http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/
For full functionality of this site it is necessary to enable JavaScript. Here are the instructions how to enable JavaScript in your web browser.
Ruby による Win32OLE プログラミング - Excel プログラミング（初級編）
はじめに ここでは，前のセクションで作成した FileSystemObject クラスを使って Excel ファイルをオープンするプログラムを書いてみましょう．ただオープンするのではなく，読み取り専用で Excel ファイルをオープンするツールを作ってみます． なぜこんなツールを作るのかという理由を少しだけ書いておきましょう．以前かかわった仕事ですが，そのプロジェクトでは開発文書が Excel ファイルとして Unix 上に大量にありました．ところが， Samba 経由で Excel ファイルを開くと何も修正していないのにファイルの更新日付が勝手に変わってしまうのです．これは困るので，急遽作ったのがここで紹介するExcelファイルを読み取り専用で開くツール xls.rb です．このツールを バッチファイル xls.bat から呼ぶようにして Meadow の dired から Exce
C言語・C++言語用テスティングフレームワーク - Cutter
最新リリース 2019-09-13にリリースされた1.2.7が最新です。 [ダウンロード] [変更点] Cutterとは Cutterは書きやすさ・デバッグのしやすさを重視したC言語・C++言語用のテスティングフレームワークです。メンテナンスしやすく、利用効果の高い単体テスト（ユニットテスト）の開発を支援します。 また、テストを苦痛ではなく、楽しいものにすることも重視しています。スクリーンショットはテスト結果の通知機能を利用している様子です。文字としてテストのパス・失敗を伝えるだけではなく、視覚的にも通知することで、テスト結果をわかりやすくします。わかりやすいので、頻繁にテストを実行したくなります。この機能はnotify-sendコマンド（Linuxや*BSDなどの場合）またはgrowlnotifyコマンド（macOSの場合）を利用します。 動作環境 CutterはDebian GNU/L
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論
FlawedTheoryBehindUnitTesting - 単体テストに潜む誤った理論 目次 この文書について 単体テストに潜む誤った理論 単体テストに潜む誤った理論 この文書について "The Flawed Theory Behind Unit Testing" の日本語訳です http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 私は Google の blogsearch 一式を使って単体テストに関する話題を拾っている。 普段は一週間に数十の blog やメーリングリストの議論に目を通す。 新しい話題もたまにはある。けれど、多くの話題は繰り返しだ。同じ主張が何度も現れる。 その中でもひときわ私を悩ませる
仕様に基づいたテストスイーツを書く - 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 を提唱します。 趣味としてのプログラミングは、ビジネスとは無関係です。それは、人生に与えられた有限の時間の使い道として、あなたが選んだ選択肢です。なぜ、プログラミングを趣味とするのか、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メンテナンス可能な自動受け入れテスト
InfoQ: より良いユニットテストためのガイドライン
InfoQ: "古典派"TDD 対 "モック派"TDD、これは本当の対立軸だろうか？