at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464Read less
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464Read less
「コードカバレッジ100％を強制します」 エムティーアイ上席執行役員CTOの古賀和幸氏は3年ほど前、こう宣言した。コードカバレッジとは、ソースコードに対してテストが実施された割合を示す数字である。 コンテンツ配信事業を手掛けるMTIは、ヘルスケア分野のサービスを提供するシステムの開発にあたり、「テスト駆動開発（TDD）」という手法を採用している。古賀氏が冒頭の宣言をしたのはTDDの導入と同時であった。 TDDはまず先に、テストのためのコードを書き、その後に実際のソースコードを書く。あらかじめ作っておいたテストコードですぐにソースコードをテストできる。つまり、プログラム開発のプロセスに単体テストを組み込んだ開発手法と言える。ソースコードの実装段階でバグを発見できるため、結合テストや本番リリース後に発生する不具合を減らすことができる。 古賀氏の要請は、テストコードでソースコードを100％テスト
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
テスト自動化研究会主催のシステムテスト自動化カンファレンス2013にスタッフとして参加＆モバイル枠をいただいてお話してきました。 スマートフォンアプリの テスト自動化をはじめよう from Koji Hasegawa システムテスト自動化カンファレンス2013ツイートまとめ - Togetterまとめ 毒食わば皿まで 古来より「毒食わば皿まで」という言葉がありまして、これはつまり「スライドを使いまわした*1ならブログエントリも使い回せばいいじゃない」という意味なのですが、さすがに心苦しいので以下オリジナルの補足をします。 尚、スライド自体もiOSに関する記述を追記したり*2、構成を見なおしたりしています。 テストレベルについての補足 途中で言った「『ユニットテストの話はするな』という圧力」はもちろん冗談なのですが、テストレベルに関して説明不足を感じたので補足します。 スライドでは「ユニ
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
最近になってitをちゃんと使ってユニットテストを書くようになってきたのですが、まだまだTipsが足りないと感じます。個人的に実践している書き方をいくつか並べてみます。 追記：最初、シェバングと書いていましたが、オプションを渡せる数が決まっていたりOSによっては動かなかったりとあまり便利でないことがわかりました。。it.xmlを書いた方がいいかも。 ちょっとしたテスト → シェルスクリプト化する itは高機能なのですが、いかんせん最初の障壁が高いと思います。とにかく気軽に書きたいなら、シェルスクリプトを作って単独ファイルで実行できるようにするといいです。 #!/bin/sh it --colors *Test.it_Framework_Te
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
真面目にテスト駆動開発を学びはじめて一ヶ月が経ちました。 今まではネットで調べて得た程度の知識しかありませんでしたが、この一ヶ月の間に二冊の本を読むことで、自分のソフトウェア開発に対する考え方が大きく変わりました。 一冊目は「テスト駆動開発入門」です。詳細は以前の記事を見ていただくとしますが、この本を読んでようやくTDDというものがどんなものであるか体感することができました。 テスト駆動開発入門 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート出版社/メーカー: ピアソンエデュケーション発売日: 2003/09メディア: 単行本購入: 45人 クリック: 1,058回この商品を含むブログ (161件) を見る とはいえ、それはあくまで理想の世界であり現実はそんなに上手くいかないもの。だから「TDDとかやった方がいいかもしれないけど、とりあえず今のシステムは動いてるし
新しいソフトウェア開発技法へチャレンジできるか？ ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング（XP）という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、
明日は、TDD Bootcamp名古屋です。 というわけで、自分のoUnit + omakeでTDDな環境を晒してみます。もっとクールな方法があったら教えてください><。 ちなみに、構築したサンプルはGitHub - mzp/ounit-example-1: OUnit exampleに置いてあります。 ディレクトリ構造 ディレクトリ構造はこんな感じで、本番コード(./src)とテストコード(./test)が別ディレクトリに分かれています。 . |-- OMakefile |-- OMakeroot |-- src | |-- OMakefile | |-- fact.ml | `-- main.ml `-- test |-- OMakefile `-- fact_test.ml ルートのOMakefile ルートのOMakefileではサブディレクトリを認識させます。ついでにocamlf
今更感はあるが、最近テスト駆動開発支援Emacs Lispのtest-case-mode.elが発表された。 http://nschum.de/src/emacs/test-case-mode/ M-x auto-install-batch test-case-mode でインストール。 こんな感じ。 テスト成功のグリーン、失敗のレッドなどの信号をモードラインに表示させる バッファが変更されたら信号も対応して変わる テストを実行して、失敗したら、その行へM-x next-it, CxxTest, CppUnit, Python(PyUnit), Ruby (test/unit)に対応 テストコードを自動判別して、テストコードならばtest-unit-modeを有効にする 設定 以下の.emacsに
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
C++ のテストフレームワークをいくつか試してみたのでメモ。 CppUnit - C++ Port of JUnit CxxTest googletest - Google C++ Testing Framework Boost.Test CppUnitはテストの記述が若干面倒な気が。表示はシンプルで悪くない。 CxxTestはインストール方法が他と違って少し悩んだが、記述量が少なくて取っつきやすかった。 googletestは記述量が少なめで、赤と緑のカラー表示コンソールで、マクロの種類も豊富。ASSERT マクロと EXPECT マクロの対応も分かりやすい。但し、出たばかりで日本語での情報が少ない。 Boost.Testは普段Boostに慣れ親しんでいるなら良いかも。マクロの種類は多め。 とりあえず、goog
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
