TDDはあんまり使わなくなったけど心の中にある - Mitsuyuki.Shiiba
今日は娘たちとコログ探しして楽しかった。 この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。 良い所がいっぱいある 見失わずに済む 僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。 余計なものを作らなくて済む 「必要なものはこれだよね？」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。 リファクタリングできる まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善
テストを使いサービス開発を駆動していくために取り組んでいること - クックパッド開発者ブログ
技術部の松尾(@Kazu_cocoa)です。 最近、 @moroや私を中心に、テストから開発を駆動するという方向で、とある活動を始めました。その活動の中では、 @t_wadaさん を 技術顧問 として巻き込んで活動を進めています。そんな取り組みを少しここにまとめます。 取り組みの前段階 先日、私はテストエンジニアというロールに焦点を当ててテストという言葉に対する2種類の話をいたしました。TDDのようにテストによって開発を駆動していく側面の話と、人の認知・感じ方に寄った仕様自体含めてテストしていく側面の話です。 クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました！ クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました！ その際、会の傍でt_wadaさんらと私たちが開発するWebアプリケーショ
クラウドワークス勉強会「レガシーコード改善の戦略と戦術」（後篇：戦術＆懇親会） - CrowdWorks Engineer Blog
こんにちは！開発の所(@ctokoro_me)です。 クラウドワークス勉強会「レガシーコード改善の戦略と戦術」前篇（戦略）に続き、後篇（戦術＆懇親会）をお送りします。 「レガシーコード改善の戦略と戦術」 講師：和田 卓人(@t_wada) タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。 その後様々な縁に導かれソフトウェアパターンやXP（eXtremeProgramming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。 テスト駆動開発によって「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」から解かれてからは、文章や講演、ハンズオンイベント等を通じてテスト駆動開発の啓蒙に努めている。 今日もグリーンバンド（テスト駆動開発者の証）を左手に着
クラウドワークス勉強会「レガシーコード改善の戦略と戦術」（前篇：戦略） - CrowdWorks Engineer Blog
こんにちは！年初からクラウドワークス開発に新たにジョインした所と申します。 先日、クラウドワークスではテスト駆動開発とRESTFulアーキテクチャのエバンジェリストとして有名な和田卓人さんをお招きして社内勉強会を開催いたしました。 和田さんは、数多くの会社にてレガシーコード改善のコンサルティングの経験をお持ちで、書籍も多数執筆されており界隈でも有名な方です。 また、弊社CTO大場の旧知の友人でもあります。 クラウドワークスのサービスは立ち上げから現在に至るまでRuby on Railsで開発を行っており、サービス拡大に伴いアプリケーションの規模も大きくなっています。 比較的テストが書きやすいフレームワークではあるものの、ビジネスの急激な成長を支えるために速度を優先した機能開発が行われていた時期もあり、レガシーコードが残っている部分があります。 将来に向けて技術的負債の返済をしていくことは、
Readme駆動開発を和訳してみた - 生涯未熟
rebuild.fmで話にあがっていた「Readme Driven Development」について、 原文がどんな内容なのか気になったので訳してみました。 英語力が低いのでGoogle翻訳等をフル活用していますので、 間違っているところや日本語的に怪しいところなどありましたら、ご指摘お願いいたします！ 最近TDD（テスト駆動開発）やBDD（ビヘイビア駆動開発）、エクストリームプログラミング、スクラム開発、スタンドアップミーティングなど、より良いソフトウェア開発のための様々な種類の方法論・開発手法の話題をよく耳にする。 だが、開発しているソフトウェアに対して、それらの方法論・開発手法がマッチしていない限り、全く意味は無いものになっているだろう。 別の言い方をすると、粗悪な設計書に基づいた完璧な実装のように価値がないということだ。 同じようなもので、ドキュメントの無いビューティフルな技術を用
TDD の Death and Rebirth まごころを君に - @ledsun blog
我が輩のTDD体験を語る 背景 ここ最近のTDDに関する話の噛み合なさっぷりよ・・・ TDDは死んだ。テスティングよ栄えよ。 by DHH 【翻訳】TDD is Fun 【TDDを再定義したほうがいいって話だったのさ】UncleBob, Martinfowler, DHHのツイートまとめ TDDという名の幻想... 大きな疑問 業務でxUnit使ったテストファーストやってる人はいるの？ TDDは死んでないと言うても、業務でxUnit使ったテストファーストやってる人はいるの？ じゃあ、自分はどうなのか？自分語りをする。 前提 ここで話すTDD xUnitを使ったテストファースト 今回はそれ以外を話さない XPの第一版にはそれ以外の要素は書いてなかった。 俺はそう刷り込まれた。 一番大事だと思う要素から話す。 「これからインスピレーションを得たもっといい方法があるよ」って話は喜んで聞きます。
TDDについての議論で感じること
「TDD is dead」以降、TDDの議論が再燃していて、その中で Rspec を見直す動きがあるらしい。 Twitterのタイムラインとかでつまみ読みしているだけなのだけど、違和感を覚えることが多い。 それはなぜか。しばらく違和感と正面から向き合ってわかったことがある。 それは、これまでの議論の中で、「TDD をなぜやっているのか」ということについてほとんど論じられることがないなと思うと同時に、テストの目的もほとんど論じられることがないからだ。 TDD は、「開発・設計技法だ」という人と「品質確認方法のひとつだ」という人がいる。そのどちらをとるかは人によると思うので、どっちであるべきかなどはここでは論じないが、大事なのはこれらの区別ができるかどうかだ。一緒くたに扱ってしまうとあまりよくない結果を呼ぶことになる。 「開発・設計技法」なのであれば、チームでTDDをやるべきかどうかは別にして
テスト駆動開発（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は彼の
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
効果の高いテストについて考える - gong023の日記
テストエンジニアという奇異な立場にいる。 普通にプロダクトメンバーの一員だが、プロダクト自体のコードはあまり書かず、品質という観点から良かれと思ったことをする。大体グーグルのテスト本に載っているSETをロールモデルとしている。 テストから見えてくる グーグルのソフトウェア開発 作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘出版社/メーカー: 日経BP社発売日: 2013/05/23メディア: 単行本この商品を含むブログ (8件) を見る SWTは、例えばエンジニアがテストを書きやすいようにライブラリを作ったり、テストがリリースのネックにならないように高速化したり、手動テストを支援するようなサポートツールを作ったりするのが役割となる。普通に単体テストも書く。（が、それはあまり理想ではなくて、本当はそのコードを書いた人が単体テストも書くべきだ。） しかし、現
Kazuho's Weblog: 良いソフトウェアに求められる３点セットとJSXの開発手法の改善とgit-pushdirについて
テスト駆動開発（TDD）の一般化とGitHubの登場によって、機能追加の際にコードとテストを同時に実装する（そして、両者を一括してmasterにmergeする）という開発手法が一般化してきました。 しかし、「良いプログラム」の要素を構成するのは、コードとテストのみではありません。動作するコードと、その品質を担保するためのテストがあったとしても、適切なドキュメントがなければ、ユーザーはそのプログラムをどうやって使ったら良いかわかりません。 つまり、ユーザーに使いやすいプログラムを継続的に開発／提供しようと思うと、 コード テスト ドキュメント の３点セットを提供する必要があるのです注1。 今日のJSXが抱えている最大の課題は、ドキュメントが不足しているという点にあります。その原因は、「機能追加」の際にコードとテストのみを実装してmasterにmergeすることを繰り返す一方で、ドキュメントは
TDDをめぐる、最近の議論についての私見。 - bluebird
はじめに DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。乗り遅れた感もあるのですが、前述のエントリに限らず、TDDについて最近考えていることをまとめたいと思います。 TDD＝テストファーストではない ケントベックの「テスト駆動開発入門」や、Uncle BobのTDD三原則の影響もあり、TDDでは、まずテストファーストするのだ、という印象をお持ちの方がいると感じてるのですが、いきなりテストファーストするというのは、教条主義なところがあり、現場に適用するのは敷居が高いのは確かです。 TDDを実践する上で大事なのは、テストによって開発が駆動されることです。すなわ
考えても良い書き方が浮かばないコードをそれなりに上手く書く方法 | mah365
元気に生きていれば上手く書けないコードの一つや二つ出てきます。そんな上手く書けないコードを、どう書くか。 分解、分解、分解 とりあえずコメントを書く とりあえず書きたい処理をコメントに書きます。 def awesome_method # あれをする # これをする # それをする end コメントに対応する処理を埋める コメントに対応する処理を埋めていきます。コードをシンプルに書くとかそんな余計なことは考えずに、コメントに対応した処理を実現するようにします。動けばいいです。 def awesome_method # あれをする # ...10行ぐらいのコード... # これをする # ...10行ぐらいのコード... # それをする # ...10行ぐらいのコード... end 動いたので綺麗にする 動いたあとは綺麗にしましょう。 def awesome_method # ...3行ぐらい
アクセルを踏むためのテストとブレーキを踏むためのテスト - yoshiori.github.io
Rebuild.fm#29 聴いてて少し語りたくなってるので書いてみる。 テスト考2014 – Hidden in Plain Sight から発してると認識してるんだけど新年早々テストについて盛り上がってますね！ で、個人的な意見を書くまえに、俺はテストどころかコンピュータサイエンスも学んだ事ない人間ですので色々見当違いな事言ってるかもしれないけど、エンジニアのスタートが組み込み系の QA エンジニアなので現場感覚はそれなりにあるつもりです。 で、早速なんだけど上記ブログから引用させてもらうと まぁ、なんにせよ、現在のウェブアプリ開発におけるテストなんて一歩間違えれば「ままごと」みたいなレベルだから、そんなに原理主義的になるのはダサいよねって話です。 id:kennejima に百パー同意で、ぶっちゃけちゃんと QA やった人間からすると境界値テストすらしてないしホワイトボックステストだ
テストについての個人の雑感 - tokuhirom's blog
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（後編）。CROSS 2014
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日都内で開催されました。「現場に聞く！テスト/CI/DevOps、実際のところどうなの」というセッションでは、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇しています。 セッションの前半では、テストの重要性やテストをどのくらい書くべきなのか、といった議論が行われましたが、後半ではどうすれば組織としてCIやテストに取り組めるのか。そして組織内での情報共有などについての意見が交わされました。 （本記事は「はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014」
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitbucket | Git solution for teams using Jira
