本編開始は 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 テストの構造化とリファクタリングの説明
第17回リファクタリングをどこまでするか、いつやめるか 和田卓人 2007-12-25
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
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
はじめに モバイルアプリサービス部の中安です。 このたび、テスト駆動開発(Test Driven Development = TDD)の社内読書会を数ヶ月に渡って参加させていただきました。 原題: Test-Driven Development By Example 著: ケント・ベック 訳: 和田卓人 こういうものに参加するのも初めてなので「なんとかついていく」という感じでしたが、 最終的には無知識だった初めの印象から変わった部分も多く、有意義だったなぁという感想に至りました。 すでに社内読書会については素晴らしいまとめがありますので、 詳しくご覧になりたい方は下記のリンクをご覧くださいませ。 『テスト駆動開発』読書勉強会 では、自分はここに何を書いていくかというと、 「テスト駆動開発って何だろう」から始まった自分が読書会を通じてわかったこと 弊社に直接お越しいただき話をしていただいた、
今日（2015-04-25）は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。 まさーるさんは、一言でいえば 1990 年代後半から 2000 年代前半の日本におけるオブジェクト指向プログラミング、自動テストとテスト駆動開発、そしてアジャイルソフトウェア開発の啓蒙において大きな役割を果たされた方だ。もしも 10 年前の福知山線に乗っていなければ、いまでも日本を代表するプログラマの一人だったのではないかと思う。 まさーるさんの残した足跡は、様々なところに見いだすことができる。 Java プログラマであれば、 Quick JUnit という Eclipse プラグインを使ったことがある方が多いのではないかと思う。 Quick JUnit はテストコードとテスト対象コードの間をショートカットで行き来できる便利なプラグ
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
xUnit Test Patterns(以下 xUTP) では、ソフトウェア開発全体におけるテストの在り方や考え方について説明されています。 今回は、開発を進めていく中でよく遭遇するアンチパターンである、「テストの匂い」についてご紹介します。 xUTP 読書会 Wiki で該当するページは次のとおりです。 Part 1 Chapter2. Test Smells Part 2 Chapter15. Code Smells Part 2 Chapter16. Behavior Smells Part 2 Chapter17. Project Smells 「匂い」とは、問題が発生する兆候のことです(Part1 Chapter 2 Test Smells - What's a Test Smells？)。 "リファクタリング"では、「コードの不吉な匂い」としてプロダクションコードで見つかる問題
前書き ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！ kyon_mmの意見 POSTDさんが【翻訳】「ほとんどのユニットテストが役に立たない理由」を読んで | POSTDを公開してくださいましたが、翻訳対象の記事を書いた人はJames O Coplienの「ほとんどのユニットテストが無駄になる理由」を勘違いしているということ、元記事自体また、元記事でのJames O Coplienからのコメントでも明らかです。この記事を読んでたくさんの人がCoplienの意見を誤解してしまったの
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
いまさら聞けない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超入門（4）（1/3 ページ） 連載目次 前回の『TDD／BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD／BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ？」「網羅的なテストをどうやって書けばいいんだろうか？」「テストを先に書くだけくらいにしか違いがないのではないだろうか？」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD／BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き
JavaScript Test-Driven Development with Jasmine 2.0 and Karma AI-enhanced description This document discusses JavaScript test-driven development using Jasmine 2.0 and Karma. It introduces test-driven development principles and benefits, then covers the Karma test runner, PhantomJS browser, and features of the Jasmine testing framework including describe blocks, expectations, matchers, spies, and c
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation10.1K views•63 slides
今日テストなくてめちゃくちゃに壊れてるアプリケーションのテストを一から書いてて、わりと書けてよかった。午前中セットアップに手間取ってて、午後からテスト書き始めて、小さいアプリケーションだったのでC0 90%くらいまでいけた。3年間くらいテストないせいでびくびくみんな触っててめちゃくちゃに壊れててよくなかった。テストえいって書けば書けるんだから、隙を見て書いていきたい。ずっとテストのあるWebアプリケーション眺めてるのでだんだんコツが分かって気がする。まず最初にCIに載せて、カバレッジ測れるようにする。面倒だけど、これやっておくと後で役立つ。普通にテスト書くと、実行環境までは定められないけど、CIがあれば、そこをベースに議論できる。最初は、アプリケーションのルートのモジュールをuse_okするだけ、くらいでまず通して、カバレッジも取れるようにする。たとえば、MyAppっていうアプリケーション
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ページを開く
