C言語向けユニットテスティングフレームワーク Unityについて - 千里霧中
C言語のユニットテストのフレームワークには、昔はCUnit+自前のテストコードジェネレータを使用していたのですが、前々からUnityの使用機会が増えています。 理由は色々ありますが、自分の場合だと以下の点で便利なのが特に大きいです。 移植性に優れるため組み込み環境（ホスト、ターゲット両方で）でも使える 標準で自動テストディスカバリ機能（テストランナーの自動生成）を持っているので、そのままTDDのような軽快なテスティングを実現できる 特に組み込みCでTDDをやる場合は、PCUnitと並ぶ有望なテスティングフレームワークだと感じます。 少し前にTest Driven Development for Embedded Cの読書会にて解説を行う機会もあったので、今回Unityについて簡単にまとめたいと思います。 特徴 組み込み開発も対象に含むC言語向けユニットテスティングフレームワーク サイト:
テスト駆動開発は戦略である - 偏見プログラマの語り！
本稿は、前回の記事 『テスト駆動開発について僕は誤解していた』 を踏まえた上で僕が TDD について思うことのまとめです。 どうも TDD は「あらゆる開発現場で適用できる」「大掛かりな仕掛けは不要である」「やった方が良いらしい」ことが見えてきました。ということは、世間は「TDD を実践するのが当たり前」になっているはずです。しかしどうもそうなっていないようです。何かがおかしい気がします。 Siri に聞いてみましたが教えてくれませんでした。 1. 手間がかかるから実践されていないのだろうか。 テストコードを書く手間はゼロではありません。お金儲けをしている以上、かける手間は少なければ少ないほど良いわけですよね。「手間がかかるからやらない」という意見はありえそうです。もしかして、これがネックになっているのでしょうか。 2. みんながやってないから実践されていないのだろうか。 前回の記事を書い
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
うのらぼ。 - 【Javascript】QUnit導入と単体テスト–第1回社内勉強会
qUnit本体 http://dev.jquery.com/view/trunk/qunit/testrunner.js CSS http://dev.jquery.com/view/trunk/qunit/testsuite.css jquery http://jqueryjs.googlecode.com/files/jquery-1.2.6.min.js メソッド test(name, test_func) … 通常のテスト asyncTest(name, test_func) … 非同期テスト module(name) … テストのグループ化 ok(state, message) … stateがtrueならテスト通過、falseならテスト不通過 テストが正常に通過したか、関数が正常に動作しているか、などのチェック sample $(function(){ module('samp
Day 13 - Test Driven Infrastructure with Vagrant, Puppet and Guard
This was written by Patrick Debois (www.jedi.be) What's the next step once you implement some config management tools? Testing, right? Wouldn't you like to automate that with some nice clean and sandboxed environment for testing your config management changes? You can use Vagrant to help ease the VM management. It is a great tool often used as a sandbox environment to develop Chef recipes or Puppe
TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組
@t_wada「TDDはスキルです。量は質に転化する」 TDD Advent Calendar2011の記事になります。 TDD Advent Calendar jp: 2011 : ATND 前：@irof テストと言うパートナー #TddAdventJp - 日々常々 次：@yuya_takeyama さんです。 はじめに これは僕の主観であって、間違いもあると思います。それは僕の勉強不足から生じるものです。 どちらかというと、これを読んだ方に「そこはちょっと認識が一般的じゃない」「そもそも違うよ」って突っ込んでもらうためのものです。 「TDDよくわからないので教えてください」っていう記事です。 TDDをはじめたい人、TDDに行き詰まっている人 TDDがどんなものかよくわからない人、とりあえずテストコードって書いているけど毎回つまずいて成長が実感出来ない人、現場に導入したいけど伝え方が
An Introduction to Mock Objects in Ruby - James Mead
Outline What is a Mock Object? Why use Mock Objects? Examples using Mocha Hints and Tips Outline What is a Mock Object? Why use Mock Objects? Examples using Mocha Hints and Tips What is a Mock Object? Years later, Mock objects are still quite controversial, often misused and sometimes misunderstood. “Pintside Thoughts: Mock Objects History” —Tim McKinnon What is a Mock Object? Different things to
C言語・C++言語用テスティングフレームワーク - Cutter
最新リリース 2019-09-13にリリースされた1.2.7が最新です。 [ダウンロード] [変更点] Cutterとは Cutterは書きやすさ・デバッグのしやすさを重視したC言語・C++言語用のテスティングフレームワークです。メンテナンスしやすく、利用効果の高い単体テスト（ユニットテスト）の開発を支援します。 また、テストを苦痛ではなく、楽しいものにすることも重視しています。スクリーンショットはテスト結果の通知機能を利用している様子です。文字としてテストのパス・失敗を伝えるだけではなく、視覚的にも通知することで、テスト結果をわかりやすくします。わかりやすいので、頻繁にテストを実行したくなります。この機能はnotify-sendコマンド（Linuxや*BSDなどの場合）またはgrowlnotifyコマンド（macOSの場合）を利用します。 動作環境 CutterはDebian GNU/L
テスト自動化の目的 - 千里霧中
最近あるMLでテスト自動化の目的について考える機会があったのですが、今回は整理としてそこで言及したことをまとめたいと思います。 色々な目的 よく言及されていますが、テスト自動化の目的は単に「人がやっていることをツールにやらせて楽をする」といったものに限りません。思いつくものでも、例えば以下があります。 繰り返し作業を効率化する 何度も繰り返す作業を自動化して、繰り返しによる作業重複分を効率化します。 継続的なテストの実現 テストの繰り返し実行を容易にして、高頻度の回帰テストを実現します。例えばCIへのテストの組み込み等を実現します。 素早いフィードバックの実現 継続的なテストの実現により、コミットといった小さな追加・変更のステップごとのテスト実行を実現します。これによりプロダクトやテストの追加・変更を小さな単位でテストをしつつ進められるようにします。 バグの早期検出の実現 頻繁な回帰テスト
Developer's Test 勉強会 (XPJUG関西 分科会)
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
あんなテスト、こんなテスト(this and that about testing)
Similar to あんなテスト、こんなテスト(this and that about testing) (20)
WebTest vs. Selenium: Real and Simulated Browser Testing
Achieving Seamless Integration Through User Co-Design Savannah Kunovsky and Jenna Fizel, co-managing directors of IDEO’s Emerging Technology division, talk about the future of technology in general and how we can work with our users to build the most impactful product. They explore prototyping and co-design techniques, as well as how generative AI can help with rapid prototyping.
ソフトウェア構築自動化技術トレーニング 〜Continuous Delivery〜に行って来ました！その１ - ShiroKappa Blog
07/21にAgile Conference Tokyo 2011の連動企画「ソフトウェア構築自動化技術トレーニング 〜Continuous Delivery〜」に行ってきました。参加費75,000円の高額なイベントですが、あの"Martin Fowler"（マーチン・ファウラー）氏と、「Continuous Delivery」の著者である"Jez Humble"（ジェズ・ハンブル）氏によるトレーニングとあっては行かないわけにはいきません！ 【参考URL】 ソフトウェア構築自動化技術トレーニング 〜Continuous Delivery〜 ・・・ 開催概要 両氏に会えたこと、最前列中央に陣取ったおかけで目と鼻の先で両氏の生の講演を聞けたこと、トレーニング終了後に[twitter:@haradakiro]さんのおかげで両氏と立ち話に立ち会えたことは良い体験ができました！ 主催者には貴重な機会
ソフトウェア・テストPRESS総集編 | 技術評論社
著者 ソフトウェア・テストPRESS編集部 編 定価 2,717円（本体2,470円＋税10%） 発売日 2011.7.15［在庫なし］ 判型 B5 頁数 80ページ ISBN 978-4-7741-4733-8 概要 特集1 JSTQB Advanced Level対応！ テストマネジメント実践入門 JSTQB（ソフトウェアテスト技術者資格認定試験）では、2011年の8月に、Advanced Levelの本試験第1回としてテストマネージャの試験が開催されることになりました。本誌Vol.10では、Advanced Levelシラバスの章構成に従って、テストマネージャが学習すべき内容についての解説がありましたが、本稿では視点を変えて、開発の流れに沿った形で、テストマネージャに必要な知識、実施すべき作業、考慮すべき事項などを解説します。テストに関するさまざまな活動において、どのようなことを行わ
続・テストコードのリファクタリング - 千里霧中
「テストコードのリファクタリング - 千里霧中」の続きです。 十分に実施できる方法 テストコードを対象としたリファクタリングの回帰テストについてですが、現実性があり、十分に実施できる方法は主に次の２つとなると思います。 テストコードのインプットとなるテストケース仕様にもとづいて、ミューテーション分析を実施。ミューテーションテストと正常系のテストを実施することで、バグがなければパスし、バグがあれば失敗することを確認する。 テストコードに対する入出力・間接入力（テストフィクスチャからの入力など）・間接出力（Assertionメソッドへの出力等）を、Test Doubleやロギングで網羅的に記録。変更前と変更後で、入出力、間接入力・間接出力が変化しないことを確認する。 ただ現実性があるといっても問題もあります。ミューテーション分析については、テストケース仕様からミューテーションテストの仕様を作成
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mocking wxPython - dirtSimple.org
YAPC::Asia Tokyo 2011 - あんなテスト、こんなテスト (this and that about testing)
https://cacheonix.com/blog/?p=15
This domain is for sale! » Using just enough automation to dramatically improve the testing process