TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
本編開始は 19:05 からです こちらのイベントのYoutubeLive配信のアーカイブです https://tddbc.connpass.com/event/183044/ チャプター 0:00:00 準備開始 0:19:05 講演開始 0:41:55 ライブコーディング開始 0:57:20 プログラミング開始 1:02:00 最初の RED ？ 1:19:00 fake it 1:26:50 最初のリファクタリングおわり 1:36:40 質問タイム 1:51:20 5の倍数に着手 1:53:40 前半のデモのまとめ 1:55:20 質問タイム2回目 1:56:45 リリースから3年後の世界（テストをメンテナンスしやすくする） 2:14:20 テストの構造化とリファクタリングの説明
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
Mistaeks I Hav Made: Diamond Kata - TDD with only Property-Based Tests
Good judgement is the result of experience ... Experience is the result of bad judgement. — Fred Brooks The Diamond Kata is a simple exercise that Seb Rose described in a recent blog post. Seb describes the Diamond Kata as: Given a letter, print a diamond starting with ‘A’ with the supplied letter at the widest point. For example: print-diamond ‘C’ prints A B B C C B B A Seb used the exercise to i
xUTP Magazine - ぺけま
xUTP Magazine について 『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。 最新号 0004号 巻頭言 xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 TDD Live 番外編(TDD序破Q) 編集後記 バックナンバー 0003号 xUnitester Hotlinks: 第一回 和田卓人さん(下) goos 読書会への誘い 来年(2012年)のTDDBC予報 0002号 xUnitester Hotlinks: 第一回 和田卓人さん(上) xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 mockitoでサ
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
テスト駆動開発って何だろう | DevelopersIO
はじめに モバイルアプリサービス部の中安です。 このたび、テスト駆動開発(Test Driven Development = TDD)の社内読書会を数ヶ月に渡って参加させていただきました。 原題: Test-Driven Development By Example 著: ケント・ベック 訳: 和田卓人 こういうものに参加するのも初めてなので「なんとかついていく」という感じでしたが、 最終的には無知識だった初めの印象から変わった部分も多く、有意義だったなぁという感想に至りました。 すでに社内読書会については素晴らしいまとめがありますので、 詳しくご覧になりたい方は下記のリンクをご覧くださいませ。 『テスト駆動開発』読書勉強会 では、自分はここに何を書いていくかというと、 「テスト駆動開発って何だろう」から始まった自分が読書会を通じてわかったこと 弊社に直接お越しいただき話をしていただいた、
あれから 10 年。まさーるさん(石井勝さん)を偲ぶ。 - t-wadaのブログ
今日（2015-04-25）は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。 まさーるさんは、一言でいえば 1990 年代後半から 2000 年代前半の日本におけるオブジェクト指向プログラミング、自動テストとテスト駆動開発、そしてアジャイルソフトウェア開発の啓蒙において大きな役割を果たされた方だ。もしも 10 年前の福知山線に乗っていなければ、いまでも日本を代表するプログラマの一人だったのではないかと思う。 まさーるさんの残した足跡は、様々なところに見いだすことができる。 Java プログラマであれば、 Quick JUnit という Eclipse プラグインを使ったことがある方が多いのではないかと思う。 Quick JUnit はテストコードとテスト対象コードの間をショートカットで行き来できる便利なプラグ
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
xUTP Magazine - xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」
書いた人：@yujiorama(id:yujiorama) 目次 目的 はじめに テストの匂い テストコードの匂い Obscure Test Conditional Test Logic Hard-to-Test Code Test Code Duplication Test Logic in Production 振る舞いの匂い Assertion Roulette Erratic Test Fragile Test Frequent Debugging Manual Intervention Slow Tests プロジェクトの匂い Buggy Tests Developers Not Writing Tests High Test Maintenance Cost Production Bugs さいごに 目的 この連載記事の目的は次のような感じです。 xUTP読書会で得られた知見を
週刊ソフトウェアテスト 2014-48 #swtest_jp - うさぎ組
前書き ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！ kyon_mmの意見 POSTDさんが【翻訳】「ほとんどのユニットテストが役に立たない理由」を読んで | POSTDを公開してくださいましたが、翻訳対象の記事を書いた人はJames O Coplienの「ほとんどのユニットテストが無駄になる理由」を勘違いしているということ、元記事自体また、元記事でのJames O Coplienからのコメントでも明らかです。この記事を読んでたくさんの人がCoplienの意見を誤解してしまったの
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
「いまさら聞けない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／BDDを実現するための3つのポイント――テストレベル／網羅性とは
開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは：いまさら聞けないTDD/BDD超入門（4）（1/3 ページ） 連載目次 前回の『TDD／BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD／BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ？」「網羅的なテストをどうやって書けばいいんだろうか？」「テストを先に書くだけくらいにしか違いがないのではないだろうか？」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD／BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き
JavaScript Test-Driven Development with Jasmine 2.0 and Karma
JavaScript Test-Driven Development with Jasmine 2.0 and Karma
恐怖のFragile Tests問題
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation10.1K views•63 slides
■ - hitode909の日記
今日テストなくてめちゃくちゃに壊れてるアプリケーションのテストを一から書いてて、わりと書けてよかった。午前中セットアップに手間取ってて、午後からテスト書き始めて、小さいアプリケーションだったのでC0 90%くらいまでいけた。3年間くらいテストないせいでびくびくみんな触っててめちゃくちゃに壊れててよくなかった。テストえいって書けば書けるんだから、隙を見て書いていきたい。ずっとテストのあるWebアプリケーション眺めてるのでだんだんコツが分かって気がする。まず最初にCIに載せて、カバレッジ測れるようにする。面倒だけど、これやっておくと後で役立つ。普通にテスト書くと、実行環境までは定められないけど、CIがあれば、そこをベースに議論できる。最初は、アプリケーションのルートのモジュールをuse_okするだけ、くらいでまず通して、カバレッジも取れるようにする。たとえば、MyAppっていうアプリケーション
Uncle Bobのリトル・モッカー | POSTD
interface Authorizer { public Boolean authorize(String username, String password); } public class DummyAuthorizer implements Authorizer { public Boolean authorize(String username, String password) { return null; } } こっちは「ダミー」です。 ダミーはどういった場合に使うのですか？ 実際に使用されるかどうかに関係なく、プログラムを進める時です。 例えば？ テストですね。実際に使われることはありませんが、何かしらの引数を渡す必要があります。 例を見せていただけますか？ はい。 public class System { public System(Authorizer author
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
adultoruby
Pytest へようこそ！
JJUG 2014 fall 「私がTDD出来ないのはどう考えてもお前らが悪い！」
