You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
**テスト駆動開発(TDD)で基礎を身につけましょう。**GoはTDDを学習するのに適した言語です。なぜなら、学習するのが簡単な言語であり、テストが組み込まれているからです。
こんにちは。ＮＴＴテクノクロスの際田です。普段は社内の開発プロセス効率化、テスト自動化周りの支援に携わっています。 最近、ラムダノート株式会社の『実践プロパティベーステスト -PropErとErlang/Elixirではじめよう-』という本を読んで、プロパティベーステストという手法を知りました。 せっかく読んだしやってみよう、と思ったのですが、この本の例はErlang/Elixirという通好み(?)な言語なので、お仕事でも使えそうな言語でできないかと考えました。調べたところ、fast-checkというJavaScript/TypeScriptのライブラリがあるようなので、こちらを使ってプロパティベーステストをやってみたいと思います。 プロパティベーステストとは プロパティベーステストとは、自動テストの手法の一つで、「システムのあるべき挙動を満たす条件」をプロパティと呼び、その条件を満たすで
はじめに こんにちは、ホワイトプラスのコアシステム開発Gのエンジニアのyamauchiです。 今回、新たにHTTPテストを実装したため、実装時に発覚した問題とその解決法を共有したいと思います。 HTTPテストとは HTTPテストとは、擬似的なHTTPリクエストを生成し対象のエンドポイントに投げ、返却されたレスポンスが期待したものかチェックするテストです。 背景 現在、コアシスが担当しているシステムでは、手動でテストを行う余地が残されており、リファクタリングを積極的に進める現状では、安全性や効率性をより高めたいという背景がありました。 そのためリグレッションテストの自動化を進め、手動で確認する割合を減らしたいと考えています。 ただし、無闇にテストの数を増やすのではなく、テストピラミッドのルールに従って効率的かつ効果的なテストを作成していく方針です。 実装方法 弊社のシステムでは
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechBlogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
TDD界隈の議論で、「仕様のテスト」「実装のテスト」という話を聞くことがあります。 TDDのよくわからない言葉をどうやって説明するか悩んでいるという話 #SWTestAdvent — うさぎ組 明日からTDDをやってみよう！ - 部屋とアジャイルと私（仮称） 今日のTDD界隈で「仕様のテスト」「実装のテスト」という言い回しを一番よくしているのは私だと思うのですが、勉強会の場などでは話をすることはあるものの、こういう形で残してこなかったので、自分の考えをまとめたいと思います。 公開されているインターフェースの仕様を満たせるなら、
「プレビュー至上主義」 プログラマが「テストファースト」を唱えるなら、デザイナが主張すべきは何? それが「プレビュー至上主義」。書くより先に見る、書きながら見る、しかもほぼ最終成果物に近い形で。 河村 奨 (かわむらつとむ) これはGitHubも合わせてどうぞ。 iPhoneや大きめの画面でも見られるよう調整しました。(2014/1/19) 好きなことはなしていいらしい。なにはなそう? レスポンシブ、インブラウザデザイン、脱Photoshopの波など、ここ数年、色々ありました。それをふまえて... ライブプレビュー 少なくとも、ライブリロード ロジックレステンプレート (たぶん時間ないので、よかったら後で〜) WEBデザイン業界 今年
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
渡辺です。 最近はユニットテストの導入方法などに関するエントリーが多かったので、今回は実用的な小ネタとして、メソッドにおけるパラメータの正当性検査とユニットテストについて紹介したいと思います。 パラメータの正当性検査 はじめにパラメータの正当性検査について復習しましょう。Javaプログラマであれば読んでないことが許されないEffective Java（第2版P.175、ただし絶版）には次のように記述されています。 ほとんどのメソッドとコンストラクタは、パラメータとして渡される値に関して何らかの制約を持っています。たとえば、インデックス値が負であってはいけないとか、オブジェクト参照がnullであってはいけないというのが普通です。このような制約は明確に文書化すべきであり、メソッド本体の初めに検査することで制約を強制すべきです。これは、エラーが発生したらできるだけ速やかにエラーを検出するようにす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
