5 Common Misconceptions About TDD & Unit Tests
Most developers seem to agree that testing is good, but developers frequently disagree about how to test. In this article, I’ll break down some common misconceptions and hopefully teach you a few things about how you can benefit the most from TDD (Test Driven Development) & unit tests. 1. TDD is too Time Consuming. The Business Team Would Never ApproveThis is a common excuse for not testing, and i
三年予測 | 「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。 | dodaエンジニア IT
「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
Tdd is really dead ?
会社の新卒歓迎会LTで発表した内容です。 まだTDDはおろか自動テストすら研修前で、TDDに対して変な先入観を持って欲しくなかったので、基本的にはやんごとなき方々の言葉の引用をメインにし、僕自身の意見は少なめにしています。
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
serverspecとdocker-apiでDockerfileをTDD
serverspecとdocker-apiでDockerfileをTDD いくつかDockerfileを書いてきた．今書いているDockerfileは短くてシンプルなものばかりだが，もっと長く複雑化した時に不安になりそうだ．不安を解消するにはテストしかない．さらにテスト駆動的にDockerイメージを開発できたら素敵だ．つまり， テストを書く Dockerイメージを作成して，テストの実行 -> RED Dockerfileの編集 Dockerイメージを作成して，テストの実行 -> GREEN テストを… の流れができるとよい． ということで，RSpecを使ってTDDでDockerfileを開発するというのをやってみた，tcnksm/docker-rspec．今回実現したのは以下． Docker Remote APIでDockerfile特有のコマンド(e.g, CMDやEXPOSE)のRSp
不具合にテストを書いて立ち向かう - t-wadaのブログ
テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか？ 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時
最近行ったTDDの講演や寄稿について - t-wada の日記（旧）
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
理想のJavaScript入門書 - L'eclat des jours(2011-12-08)
_ 理想のJavaScript入門書 アスキーの鈴木さんから、テスト駆動JavaScriptをいただいた。 これは、実に良い。おれが考える理想のJavaScript入門書に限りなく近い（というか、おれが書くより良いから上方向から近い）。 まず、これはTDDの本であり、JavaScriptの問題点は、それがRubyなどのスクリプト言語より、固いプログラミング言語（JavaとかCとか）に近い構文を持っているのが原因だと思うけど、どうしても変数とか関数名とか長く書きたくなるし（これは不思議な心理的な要求による）、言語が持つ予約語自体が長いし（functionだよ）、つまりいやでもタイプミスして死ぬ。 どうすれば良いかといえば、解決方法は2つしかない。プリプロセッサを用意して未定義変数とか利用していないかチェックするか、あるいはテストするかだ。前者よりも後者のほうがまあ有意義だ。というわけで、TD
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
私にとってのテスト
Patricia Toto's blog : Using Selenium IDE to automate testing using a real browser