これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
テストカバレッジ - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TestCoverage.html 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか？」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある。 – Brian Mari
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
Wikispaces
We are sorry, but the site you are looking for no longer exists Wikispaces was founded in 2005 and has since been used by educators, companies and individuals across the globe. Unfortunately, the time has come where we have had to make the difficult business decision to end the Wikispaces service. We first announced the site closure in January 2018, through a site-wide banner that appeared to all
テスト自動化のROIの理論と実践
Hi there! I just wanted to share a list of sites that helped me a lot during my studies: .................................................................................................................................... www.EssayWrite.best - Write an essay .................................................................................................................................... www.LitR
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～ Presentation Transcript DevelopersSummit 自動改札機の 運賃計算プログラムのデバッグ手法 ～1040のパターンをいかにテストするか～14-B-3 幡山 五郎#devsumiB オムロンソーシアルソリューションズ ソリューション事業本部 Developers Summit 2013 Action ! １．自動改札機について 1. 自動改札機について 2. 間違えない自動改札機 2 １．自動改札機について自動改札機導入前の改札風景 3 １．自動改札機について磁気からＩＣへ求められる技術が変わってきた（高機能化→高信頼化） 2013年 ＩＣ乗車券全国共通化（北海道～九州の10種類） 2007年 ＰＡＳＭＯ導入、Suica+PASMO
ソフトウェアテストの分類
静的テスト／動的テスト （ ※↓ ） 1.静的テスト、2.動的テスト モデルベーステスト ／ モデルベースではないテスト （ ※↓ ） モデルベーステスト モデルベースではないテスト 2.1. アドホックテスト、2.2.探索型テスト ホワイトボックス・テスト ／ ブラックボックス・テスト ／ グレーボックス・テスト （ ※↓ ） ホワイトボックス・テスト （ ※↓ ） 1.制御パステスト、2.データフロー・パステスト ブラックボックス・テスト （ ※↓ ） 入力値および出力値の項目を決定する方法 1.同値分割、2.境界値分析 テストケース（テストを行う入力値と出力値の項目とその組み合わせ）を決定する方法 ディシジョンテーブルを使った方法 1.単純なディシジョンテーブルの使用、 2. 原因結果グラフ、3. 実験計画法、4. 原因流れ図（グレーボックステストの一種） 状態遷移テスト ファズ・テ
ジョジョの奇妙なTDD
何かの間違いで、LT王になってしまったTokyuRuby会議05の発表資料。 人類共通言語のジョジョでTDDを伝える試み。 色々とアウトな感じなので、 お咎めを受けたら消します・・・。 7/30追記: 拡散の勢いがかなりのものだったので、カット版に差し替え。
第5回 BDDとATDD | gihyo.jp
はじめに 本連載では、「透明性」というキーワードで、アジャイル開発について説明しています。前回は、テスト駆動開発(TDD)の持つ、開発を促進する設計作業としての側面にスポットを当てて説明しました。今回は、それらの考えを展開させてみたいと思います。具体的には、振る舞い駆動開発(BDD)と受け入れテスト駆動開発(ATDD)という二つのトピックを、ご紹介します。 テストのレビュー 前回、テスト駆動開発におけるテストを、設計作業であるとする考え方をご紹介してきました。これは、個々のクラスのインターフェース(=振る舞い)を、テストにより明確にしてゆくというものです。結果的に、作られたテストは、実装との乖離を自動的に検出できる設計書となります。 仕様変更やリファクタリングに伴うソフトウェアの改変に際して、バグの混入を自動的に検知できるので、実装と設計の同期が取れるという大きなメリットがあります。 し
「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない」 - カレーなる辛口Javaな加齢日記
注：テスト本リストは加筆修正した上で，改めて独立した項目に作り直した． → http://d.hatena.ne.jp/JavaBlack/20150926/p1 http://www.publickey1.jp/blog/12/8585.html http://www.keyman.or.jp/at/dev/debug/30004610/ 数値の正確さはともかく，だいたいそんなもんでしょう． 「スキルがないからPHP使ってます」「Javaは使ってるけどオブジェクト指向って何ですか？」みたいな現場だと，テストするスキルも人手も足りない． そもそもテストを知らない．テスト＝手動テストだと思っている． デバッグといえばデバッガでするものだと思っている． 導入するメリットが理解できない． テストをする人に，プログラミングのスキルや経験がない．ひどい場合には素質が無い．*1 導入するスキルがない．
TDD Boot Camp 東京 1.6に参加してきた #tddbc - Diary of absj31
TDD Boot Camp 東京 1.6 #tddbc on Zusaar Togetter - 「TDD Boot Camp 東京 1.6 #tddbc」 関東地方久々のTDDBC 1.5 in Tokyoが告知即定員オーバー瞬殺且つ定員の3倍近い募集が殺到(定員36名:募集114名)し、改めて関東/東京の需要の高さを実感。 TDD Boot Camp in Tokyo #tddbc : ATND TDDBC in Tokyo 1.5 主催レポート #tddbc | Act as Professional - プロとしての行為 勉強会主催者はなかやん・そるじゃー・ゆーき(TwitterID:@pocketberserker) さん。開催に至るまでの経緯は下記ブログに記載されていますが、彼のおかげでこうしてイベントに参加＆貴重な体験をする事が出来ました。ありがとうございます！ TDD Bo
ＴＤＤ（テスト駆動開発）は怪しいな - Javaの日々
テストコードを書きながら開発することでバグの発生低下と生産性の増大が見込める ということだが、かなり怪しい。 １．テストコードの対象はメソッド・関数の単位であること。 それらのメソッドが複数使われるアルゴリズム全体の流れの検証はできない。 しかしこれが仕様を満たしているかどうかの最も大切なテストとなる。 この最も大切なテストについては完全に沈黙しているように見える。 ２．オブジェクトの状態を制御するようなメソッドの検証の困難性 単に入力と出力があるメソッドならばテストコードを書くことは可能だろう。 しかし複数のメソッドで制御されるオブジェクトを触るようなメソッドを 検証するようなテストコードは難しいだろう。 しかもそのようなメソッドは決して珍しいものではない。 ３．テストコードの複雑さについての対処法がない 複雑なメソッドのためのテストコードは複雑になるだろう。 その場合のテストコードが正
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Writing simple, readable unit tests
Great code is testable code
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
いにしえの開発環境
