GitHub - thoughtbot/factory_bot: A library for setting up Ruby objects as test data.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
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
三年予測 | 「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。 | dodaエンジニア IT
「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
継続的Webサービス改善ガイド 記事一覧 | gihyo.jp
第5章ビジネス視点の改善～効果検証に基づく機能改善と、チームでの仕事の進め方 安宅啓 2014-02-21
「いまさら聞けないTDD/BDD超入門」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
いまさら聞けないTDD/BDD超入門（4）： 開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは 開発現場でTDD／BDDを導入するためのポイントを大きく三つに分けて解説。テストレベルや網羅性、サイクルタイムについても紹介します。（2014/10/17） いまさら聞けないTDD/BDD超入門（3）： TDD/BDDにおける「振る舞い」の意味するところとは何なのか BDD初心者が持ちがちな3大疑問点を提示して、さまざまな角度からそれを明らかにしつつ、振る舞いを表現する2つのテクニックを紹介する。（2014/4/30） いまさら聞けないTDD/BDD超入門（2）： TDD／BDDの思想とテスティングフレームワークの関係を整理しよう TDD／BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、
TDDを諦めることと、RSpecをやめること - 高柴ラボ
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは
開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは：いまさら聞けないTDD/BDD超入門（4）（1/3 ページ） 連載目次 前回の『TDD／BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD／BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ？」「網羅的なテストをどうやって書けばいいんだろうか？」「テストを先に書くだけくらいにしか違いがないのではないだろうか？」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD／BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き
RSpec をやめて Test::Unit に戻る - tmtms のメモ
最近の RSpec は、それまで obj.stub(hoge: value) と書けたものが、 allow(obj).to receive(:hoge).and_return value と書かないといけなくなったりとか、正気の沙汰とは思えないような変更をしたりするので、何年かぶりに Test::Unit を使ってみようとリハビリ中です。 RSpec は、テストケースを入れ子にできたり、テストケースや example がクラスやメソッドではなく、文字列で自由に書くことができたりしたのが良かったのですが、最近の Test::Unit ではそれもできるようになっています。 [ruby-list:48926] [ANN] test-unit 2.5.2 このリリースはとみたさんに使ってもらえるように改良したリリー スです。新しく追加した--locationはRSpecの--line_number
第1回 連載を始めるにあたって | gihyo.jp
ニコニコ動画：https://www.nicovideo.jp/watch/sm2195306 はじめまして、和田卓人（わだ たくと）といいます。 このたびgihyo.jpにて、テスト駆動開発（TDD）の連載をすることになりました。 筆者は『WEB+DB PRESS Vol.35』の特集1「実演！ テスト駆動開発」と、『WEB+DB PRESS Vol.37』の特集1「実演！ リファクタリング」を執筆させていただいた際に、同時に動画企画を行わせていただきました。おかげさまで「実演！ テスト駆動開発」と「実演！ リファクタリング」は、本誌および特設サイトの企画として、たいへん多くの方にご覧いただき、多数のご意見をいただきました。頂いたご意見の中には、以下のような意見がありました。 もう少し初心者にもわかりやすく もっと突っ込んだ内容をもう少し詳しく もう少し実践的に 特集をお読みくださった方
テスト駆動開発（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は彼の
「実演！リファクタリング」 WEB+DB PRESS Vol.37特集 特設ページ｜gihyo.jp
WEB+DB PRESS Vol.37の特集1「実演！リファクタリング」の特設ページです。リファクタリングの実演ムービーや誌面サポート情報などを掲載しています。 なお，本企画は「実演！テスト駆動開発」（WEB+DB PRESS Vol.35の特集1）と連続性を持っています。 更新履歴 2007年3月2日 訂正情報の追加 pom.xmlに，JVMのデフォルトエンコーディングがShift_JIS以外のOS（要するにWindows系以外のOS）をお使いの方向けの設定を追加しました。詳しくは5ページ目をご覧ください。 ダウンロード用サンプルコードの差し替え 上記補足情報に対応したpom.xmlに差し替えました。 著者からのメッセージ 実演ムービーをご覧いただくにあたっての，著者の和田卓人さんからのメッセージです。 Eclipseのリファクタリング機能 第3章を題材にした，Eclipseのリファク
mixiエンジニアがおくるソーシャルアプリ開発実践講座：第3回 自動テストと継続的インテグレーションを既存プロジェクトへ導入しよう｜gihyo.jp … 技術評論社
はじめに はじめまして。（株）ミクシィの加藤和良です。2008年度に入社し、2011年1月からはシステム本部 技術部に所属しています。技術部は、日記やコミュニティといった特定のサービスに紐づかない、mixi全体を裏から支える部署です。「支える」ための方法は、実際のサービスの一部として動作する共通基盤から、開発効率を上げるために社内で動作しているものまで、多岐にわたります。 mixiでは、ここ数年で自動テストの導入が急速に進みました。図1は、mixiのソースツリーにおけるコードと、そのテストコードの毎月1日のバイト数をグラフにしたものです。2008年の頭には少なかったテストが急速に増え、今年の5月にはコード量をも追い越しているのがわかります。 携帯電話向けmixiである「mixiモバイル」の開始が2004年、mixiニュースが2006年ですから、2008年当時のmixiも、それなりに大き
特集：PHPUnit3で始めるユニットテスト｜gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルサムライの次に読む技術書
Test Yourself - テストを書くと何がどう変わるか
いつでも聞けるTDD入門 #TDDBC_NAGOYA
