Unity — Throw The Switch
CUnity is written in 100% pure C code. It follows ANSI standards while supporting most embedded compiler quirks. Portable Unity is equally happy running tests for an 8-bit microcontroller as it is a 64-bit processor on steroids. Expressive Unity is designed to help you make the most of your test suite. It features a rich set of assertions so you can find the perfect match for your needs HOW UNITY
IAR Embedded WorkbenchでCppUTestを試す - Qiita
テストフレームワークの一つであるCppUTestを実機（STM32F4DISCOVERY）で動作させてみる。 準備 ターゲットとサンプル ターゲットはCortex-M4コアのSTMicro社製マイクロコントローラSTM32F407VGを搭載した「STM32F4DISCOVERY」とする。ターゲット基板の詳細はこの辺りに記載されている。このページ下部にある「Related Tools and Software」という項目があり、そこにあるファームウェアパッケージSTSW-STM32068をベースにして進める事とする。クリックしてリンクを進むとドキュメントAN3983: STM32F4DISCOVERY peripheral firmware examplesとサンプル（Part Number : STSW-STM32068）をダウンロードするボタンがあるので、クリックして「stsw-stm3
JavaScriptの単体テストフレームワーク "simpleJsUnit" で，テスト駆動開発をしよう - 主に言語とシステム開発に関して
simpleJsUnitは，JavaScriptのコードを単体テストするためのライブラリ。 シンプルさが特徴。（たった５キロバイト） コマンドラインでも ブラウザ上でも テストを実行可能。 以下は，このツールを使って，テストファーストなJavaScript開発を進める方法。 ダウンロード http://www.name-of-this-site.org/codi... （１）「Hello, World」プログラムを，TDDで作ってみよう まず，入門的なテスト駆動のコーディングをやってみよう。 下記のような仕様の関数を作ることにする。 ファイル名はhoge.js，クラス名はHogeとする。 名前を受け取ったら，「Hello，（その名前）」と出力する。 引数が無効だったら，何も返さない。 ダウンロードしたunittest.jsと同じフォルダ上に，hoge.jsの名前で空のファイルを作る。 最初
最近のおっさんたち - steps to phantasien
Gisted のドッグフードをかねて InfoQ のインタビューやプレゼンを見るようになった。 いくつか面白かったのを紹介したい・・・とおもってるうちにバックログを溜めすぎた。一度に紹介するのは諦めて何度かにわけよう。 今日はおっさん、具体的には ThoughtWorks 周辺の面々を追いかけてみます。InfoQ 中心だけどそれ以外も若干あり。 When Geek Leaks “プロダクティブ・プログラマ ” の著者 Neal Ford が あるキーノートにつけたタイトルは ”When Geek Leaks“。 ここでの Leak は前向きだ。Geek の情熱がその主たる関心の外にも影響を与えていくといいですね、という話。 ファインマンが物理学という専門以外で発揮した数々のいたずら心、 ”Now Every Company Is A Software Company” という Forbes
Test-Driven Development for Embedded C 読書会に参加しました。 - きゃりんぐ びーくる ver 0.1
今年2月より始まった、Test-Driven Development for Embedded C（以下TDD for EC）の読書会が、今月始めに、めでたく最終回を迎えました。 全8回（うち1回は体調不良のため欠席）、10人前後のメンバーで、1年弱ほど続けてきました。 きっかけとモチベーション 読書会を知ったのは、Twitter上でした。フォローしていた方が呟かれていたのですが、TDD関連でその方を知り、フォローしたので、TDDについて追いかけていたことがきっかけでしょう。 TDDについて興味を持った理由はいくつかあります。 1. テスト自体への興味 私は、昨年2011年度卒として組み込み系プログラマになりました。プログラムの柔軟性や堅牢性については学生時代比較的意識していたのですが、テスト手法については、殆ど知識が なく、体系的な知識が欲しかったのです（これは現在進行形） 2. 開発ス
1年間の技術的負債を返すために読んだ3冊の本
[この記事を読む前に] タイトルに騙されて来た方はごめんなさい。 恐らく、知っていることばかりが書いてあると思います。 “3冊の本”もベストセレクションではありません。 “たまたま”選んだ3冊の本です。 それでも読んでくれる心優しい方はどうぞ、先にお進みください。 技術的負債は日々、返済していますか。 技術的負債って何？という方はこちらへ。 技術的負債 – Wikipedia えー、正直、私は技術的負債が溜まっています。 お知らせメールを本格的に初めて1年が経とうとしています。 何も無い状態から、手探りで始めて今の状態までなんとか持って行きました。 この計画が立ち上がった当時(2年ぐらい前かな)、自分ができたのは、 PHPが書ける(書けるだけ) サーバが少しわかる(cdとlsが打てるだけ) これぐらいです。 ちょっと大げさですが、あながち嘘じゃない。 そんなこんなで、試行
組み込みアジャイルコーチ James Grenning さんインタビュー ( 後編 ) | オブジェクトの広場
去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった質問について順次尋ねる形で進めました。 2012 年 10 月号の前編に続く後編の本記事では以下の話題についてお伝えします。 ・ モデリングやアーキテクチャ設計とTDDの関係
組み込みアジャイルコーチ James Grenning さんインタビュー ( 前編 ) | オブジェクトの広場
去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった以下の話題についての質問を順次尋ねる形で進めました。 ・ 組み込みソフトウェアに対するアジャイル開発やTDDの導入 ・ モデリングやアーキテクチャ設計と TDD の関係 ・
私が受け入れテストを自動化しない4つの理由
なんの自慢にもならないどころか、完全に自戒エントリです。まず、そもそも受け入れテストを自動化する試みは有効だという仮説を持っています。 言葉の定義が曖昧で申し訳ないですが、V字モデルを考えた時に右上のほうにあるテストのことを想定しています。ですが、あまり厳密にシステムテストとの違いとか、パフォーマンスや負荷はとかを区別していません。「右上のほう」くらいを考えます。 要求分析 -------> 受け入れテスト 基本設計 -----> システムテスト 機能設計 ---> 結合テスト 詳細設計 -> 単体テスト コーディング 反復的に、スパイラルになど、とにかく少しずつソフトウェアを開発していくのが、バグ発生のリスクが少ない印象があります。仕様変更にも耐えやすい。そうすると、受け入れテストが自動化されていると、容易にテストでき、要求とことなる状態になったことがすぐわかります。あるいは、要求との差
Can TDD Help Reduce Integration Time? | James Grenning’s Blog
James Grenning’s Blog Blogging about Agile Development, especially embedded. Follow me on twitter: jwgrenning Search Main menu A recent TDD for Embedded C attendee asks me “TDD does not help reduce the time I spend in the lab during system integration testing” (This is asked in the context of embedded development. But the answer is half applicable to any development where there is integration.) TD
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
いまさらだけど、家でもテスト駆動するようになった
前書き いまどきテスト駆動開発の話をするというのも、まるでこの時期（5月末）に桜の話でもするようで、少し気後れするところもある。BDDとか言っておけば、少しは気も紛れるだろうか。まぁ、いいや。季節外れもまた良し。 今年に入った頃からようやく、家でちょっとしたコードを書く時でも、テストファーストを取り入れるのが習慣になってきた。 その中で、いろいろ実感として頭に溜まっているものもあるような気がするので、今日はその辺のことをアウトプットしてみようと思う。 基礎知識 一応書いておくと、TDD = Test Driven Development = テスト駆動開発は、コーディングをする時は先にテストコードを書きましょうっていう手法。 自分はXP関連の書籍で軽く説明を読んだり、Webでそれっぽい記事を読んだりしたくらいの知識しかないので、正直あまり詳しくはない。だから自分がやってる方法が、正しくテス
新人に話したJUnitのための知識とTips : toda_k
最近新人のコードレビューをする機会が増えまして、自分の中の経験則を言語化する機会に恵まれています。なんとなーくわかっていた事柄を人に伝えようとするのは、いつの時代にも最良の学びの機会ですね。 さて新人各位に個別に伝えた「JUnit4利用に関する注意」を整理してみました。JUnitは自由度の高いフレームワークであり使い方は十人十色かと思いますので、もっと良い使い道をご存知のかたは是非はてブコメントなどで教えていただければと思います。ちなみにここで言う「テスト」とは実装の前に書く単体テストだけではなく、実装後に書かれるものや自動化された統合テストも含めています。 １．JUnitを使うために押さえるべき前提知識 テストメソッドの実行される順番は不定 EclipseのJUnit実行機能に親しんでいると意外と気付けないのですが、JUnitはテストクラス内のテストメソッド実行順を保証していません。それ
TDDをはじめる条件 #tddbc #tddconf - やさしいデスマーチ
色々と忙しすぎてブログが書けません。 JavaOneの話とか、JUnitの話とか色々書きたいんですが…もうしばらく我慢なのです。 で、TDDの前方依存と後方依存で意見が欲しいとのことなので自分なりの意見を。 技術的な前方依存 『TDDを始める前と終TDDを実際やるために必要な技術』 ・最低限対象言語でコードがかけるようになって ・最低限テスティングフレームワークを使えるようになって ・リファクタリングをしっかり学んで ・対象言語でのきれいなコード、設計とは何かを知って ・テストファーストを知って こうしておそらくスタートライン。 自分はこれは疑問です。 最後の「テストファーストを知って」という部分はTDDに関することですけど、それ以外ってTDDを始めるスタートラインではなく、ソフトウェア開発としてのスタートラインかと思います。 言い換えると 最低限対象言語でコードを書けないと、ソフトウェア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Setting up Test Driven Development (TDD) with IAR workbench for Embedded C
https://codeday.me/jp/qa/20190129/174250.html
恐るべきレガシーコードの救世主になるか？！ドロドロ依存なモジュールたちを『CMock』ですっ裸にする | Futurismo
ユースケースからテスト駆動開発へ
Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。
はてなブログ | 無料ブログを作成しよう