テスト駆動開発（TDD）はもう終わっているのか？ Part 2 | POSTD
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
JavaScript Test-Driven Development with Jasmine 2.0 and Karma
This document discusses JavaScript test-driven development using Jasmine 2.0 and Karma. It introduces test-driven development principles and benefits, then covers the Karma test runner, PhantomJS browser, and features of the Jasmine testing framework including describe blocks, expectations, matchers, spies, and custom matchers. It also provides an example of mapping earthquakes and testing color-c
ユニットテストを書こう！ - Qiita
ソフトウェアエンジニアにとって、ユニットテストは重要です。僕はなるべくユニットテストを書くようにしており、ソフトウェアエンジニアはもっとユニットテストを書くべきだ、と考えています。ここで言及している「ユニットテスト」は、単なる「テストコードによる自動化」全体を指すのではなく、「テストから見えてくるグーグルのソフトウェア開発」で登場した用語である「Sテスト」を指します。 「テストから見えてくるグーグルのソフトウェア開発」では、テストコードが対象とするプロダクションコード(製品コード)の規模、S、M、Lとサイズごとに分類しています。 「Sテスト」とは、テスト対象のクラスのみを対象にしたテストを行うことを目的としています。テスト対象以外のクラスの処理は、積極的にモックを多用することで、テスト対象のクラスの振る舞いを確認します。 Sテストは主に品質向上に寄与すると「テストから見えてくるグーグルのソ
Tdd is really dead ?
会社の新卒歓迎会LTで発表した内容です。 まだTDDはおろか自動テストすら研修前で、TDDに対して変な先入観を持って欲しくなかったので、基本的にはやんごとなき方々の言葉の引用をメインにし、僕自身の意見は少なめにしています。Read less
TDD/BDDにおける「振る舞い」の意味するところとは何なのか
TDD/BDDにおける「振る舞い」の意味するところとは何なのか：いまさら聞けないTDD/BDD超入門（3）（1/3 ページ） 前回の「TDD／BDDの思想とテスティングフレームワークの関係を整理しよう」では、TDD／BDDについて、その思想と、それをサポートするテスティングフレームワークに分けて解説しました。その中で、TDD／BDDについては実際の熟練者の言葉を借り、テスティングフレームワークについては概要を触れて、その系譜をたどりました。 BDDはその名前に「Behavior」とありますが、「振る舞いとしてのテストコードを書く」とはどういうことなのでしょうか？ 難しく考え過ぎる必要はありませんが、「それは振る舞いを書いていないよ」と指摘をする熟練者が何を考えているかを理解することはBDDを習熟していく中で重要な意味を持ってきます。 本記事では「振る舞い」という言葉がどのような意味で使われ
テストコードを書く文化を根付かせたい─和田卓人｜【Tech総研】
日本におけるテスト駆動開発（TDD）のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは── 父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。 ただ、私は初日から生意気にも「Excelで設計書を書き続けるために来たのではありません」と嘆願して、基盤
テスト自動化研究会 - 4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス
オープンソースのブラウザテストツール「Selenium WebDriver」の使い方と、テストスクリプトを効率よくメンテナンスする方法について、実際にプログラムを書きながら学べるチュートリアル形式教材です。 前半は、Selenium入門ドリルです。基礎から丁寧に解説されているので、Seleniumは初めての方でもテストが書けるようになります。 後半では、テストのメンテナンス効率をあげるための技法「ページオブジェクトデザインパターン」の習得を目指します。こちらも基礎から解説していくので、Seleniumが初めての方でも大丈夫です。 プログラミング言語Javaでテストスクリプトを作成するので、Javaで基本的なプログラムが書ける必要があります。 自習教材として利用する場合 前提知識・事前準備手順ドキュメントの手順に従い、必要な事前準備とインストールを完了させます。作成したEclipseプロジェ
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
「最強」のチームを「造る」技術基盤
「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る ＝ 栽培する・耕す 4 CI/CD TDD ATDD この３つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Test Yourself - テストを書くと何がどう変わるか
いつでも聞けるTDD入門 #TDDBC_NAGOYA
bitbucketの使い方