例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です
『テスト駆動開発』を読んで - まめめも
テスト駆動開発posted with amazlet at 17.10.12Kent Beck オーム社 売り上げランキング: 563 Amazon.co.jpで詳細を見る オーム社さまから電子書籍を贈本いただきました。ありがとうございます。 本書はテスト駆動開発（TDD）の原典で、たいへん有名な本です。が、自分は食わず嫌いで読んだことがありませんでした。 というか、TDD 自体もちゃんと理解したことがありませんでした。なんだろう、なんか怖かった。 そんな自分が今回この本をいまさら読んでみたら、なるほどこれは確かにいい本でした。なんというか、語りたくなる感じ。ということでご紹介。 紹介 テストとプログラムを交互に書いていく開発方法 TDD を、例題を用いて実演していく本です。 TDD というと「プログラムより先にテストを書く」というところだけ強調されますが、正直それではよくわからないのでし
レガシーコード改善ガイド・知識編 - Strategic Choice
書籍「レガシーコード改善ガイド（Working Effectively with Legacy Code）」の「第1部 変更のメカニズム」より、レガシーコード改善作業の前提となる知識をまとめます。目次レガシーコードとは変更：ソフトウエア一般 ソフトウェア変更の課題ソフトウェア変更のリスクソフトウェア変更の方法回帰テストによるソフトウェアの保護回帰テストの問題点単体テストによるソフトウェアの保護単体テストの境界線変更：レガシーコード特有 レガシーコード変更の課題レガシーコード変更の心構えレガシーコード変更の方法関連エントリレガシーコード改善ガイド・知識編（本エントリ）レガシーコード改善ガイド・戦術編レガシーコード改善ガイド・戦略編出典レガシーコード改善ガイド (Object Oriented SELECTION)作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
テスト駆動開発（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の効果の研究をまとめた研究 - やっとむでぽん
TDDに関連する論文をいろいろ探し回っていたのですが、今年(2013年)に書かれた、既存のTDD研究をまとめて全体像を描こうとしている研究を見つけ、しかも無料で公開されているので、紹介したいと思います。 以下のように書いてあるので、学会(?)発表用のものであって、雑誌に載ったわけではないのかな(アカデミックな話はよくわからない。査読があるかどうかが重要なんだっけ)。 This is the author's version of the work. The definite version was published in Proceedings of the 6th International Conference Software Quality Days (SWQD 2014), Vienna, Austria, January 14-16, 2014 "Effects of Tes
階層を増やしすぎるとテストが多くなりがちという問題 - はこべにっき ♨
テスト書きすぎ問題 - hitode909の日記 いい話。だいたい同意見で、テストはなるべく書こうとしたい。後からコードに変更を加える人が安心できるように、テストには書いてるコードがどう有るべきかという情報が全部網羅されていてほしい。コードがあるべき状態ではなくなって動かなくなったときは、必ずテストが落ちて欲しい。 とはいえ、テスト書きすぎてしまって良くなかったなあと思うことはある。アプリケーションの設計の階層が無駄に深くなっていて、各階層ごとに似たようなテストをなんども書く事態に陥ったりするような場合だ。 例えば、何かブログみたいなWebアプリを作っていて、エントリー投稿する機能を実現する機能が以下のクラスに含まれていたとする。 Blog::Controller::Entry ディスパッチャから呼ばれるエントリーポイント Blog::Handler::Entry HTTPリクエストからE
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
JUnit API探訪：@Before/@After, @BeforeClass/@AfterClass アノテーション - Diary of absj31
JUnit API探訪：アノテーション一覧 - Shinya’s Daily Report @Before アノテーション / @After アノテーション Before (JUnit API) After (JUnit API) JUnit4をやってみよう @BeforeClass,@Before,@AfterClass,@Afterそれぞれの違いを検証する。 JUnit(JUnit4)の概要〜利用方法【ユニットテスト - テスト】 ＠みっちーわーるど JUnit4 - TRANCE ARTS 技術情報Wiki メソッドの前後に、都度実行する。 @BeforeClass アノテーション / @AfterClass アノテーション BeforeClass (JUnit API) AfterClass (JUnit API) JUnit4をやってみよう @BeforeClass,@Befor
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
TDD Boot Camp 札幌 2.0
The document describes a Test Driven Development (TDD) Boot Camp event that was held in multiple iterations from 2011 to present. It provides details on the schedule and topics covered during the multi-day training workshops, which introduce participants to TDD techniques using Java and Ruby programming languages. The goal of the boot camp is to help developers learn how to use TDD as part of thei
自動化テストで気をつけること - give IT a try
先日、会社のメンバーからテストの自動化に苦労しているという話を聞きました。 そういえば、一言で「テストの自動化」といっても結構奥が深いので、自動化テスト初心者が注意すべき点や重要なポイントをちょっと考えてみました。 自動化テストの注意点 どのような処理でもプログラムとして自動化できるプログラミングスキルを実装者が持っていること。 結局、手作業でやっていることのほとんどをプログラムとして実装する必要があるからです。 いつでも、どこでも、誰が実行しても同じテスト結果が返ってくるようにテストを作成すること。 たとえば、テストの成功・失敗がシステム日時や外部ファイルやデータベース等に格納された不安定なデータに依存しているとテストがすぐに壊れます。 壊れたテストを放置しないこと。 少なくともソース管理システムにコミットしたファイルはすべてパスするようにしましょう。 壊れたテストを放置すると、誰も自動
SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行
軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。本体のソースコードは約6万7200行（67.2KSLOC、Kilo Source Lines of Code：空行やコメントを除いた行数）なのに対し、テストコードはなんと4567万8300行（45678.3KSLOC）だと紹介されているのです！ これはテストコードが本体の約679倍もの大きさだということになります。 100％のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang
TDDの勉強会に参加 - Float on the flow
テスト駆動開発（TDD）の勉強会に参加してきました。 詳しい内容は以下をご覧下さい。 http://kanazawa-process.g.hatena.ne.jp/katzchang/20090517/1242513168 http://d.hatena.ne.jp/katzchang/20090517/p1 テキストには「テスト駆動開発入門」を使っています。 テスト駆動開発入門posted with amazlet at 09.05.17ケント ベック ピアソンエデュケーション 売り上げランキング: 194071 Amazon.co.jp で詳細を見る 以下、感想と、今回進んだところ（9章）までのソースコードです。 感想 実は勉強会形式のイベントに参加するのは初だったのですが、 いきなり発表者のご指名をいただいたり。 基本的に写経（テキストを読んで、書いてあるコードを入力する）を すれば
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JUnit4をやってみよう
bitbucketの使い方
TDDBC横浜3rd