Unity Test Tools がリリースされました | Unity Japan Official Blog
UnityTestToolsの日本語マニュアルは下記URLで閲覧できます。 Unity Test Tools Documentation 以降の内容はUnity Test Tools Releasedを翻訳したものです。 過去にブログでもご紹介しましたが、Unity QA ではこの 2 年間、社内用の各種ツール、フレームワーク、テストリグの開発と拡張を続けてきました。その結果として生まれた各種ツールは、Unity 社内で高く評価されるまでになりました。今回はその成果をユーザーの皆さまと共有するべく、Unity Test Tools バージョン 1 をアセットストアよりリリースいたします。こちらよりダウンロードが可能です： 今回リリースする Unity Test Tools が、ゲーム開発に携わる皆さまの高いコード品質を実現する一助となれば幸いです。 Unit Test (ユニットテスト)
Rails でテストをどう書くべきか備忘録
今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100％カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。（※） ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
テスト駆動開発へようこそ
7. 本日のスケジュール 11:00∼12:15 TDD, ユニットテストに関する講演 12:15∼12:30 ペアプロとお題の説明 12:30∼13:30 ペア作成、昼食、自己紹介など 13:30∼15:00 演習（前半） 15:00∼15:30 レビュー① 15:30∼17:00 演習（前半） 17:00∼17:30 レビュー② 17:30∼17:50 振り返り ※休憩やお手洗いはご自由にお取りください 8. TDD Boot Camp(TDDBC) とは、テスト 駆動開発(Test Driven Development)につ いて、座学だけでなく、実習形式で手を 動かして体得することを目的とするイベ ントです。 http://devtesting.jp/tddbc/
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
不具合にテストを書いて立ち向かう - t-wadaのブログ
テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか？ 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ
8. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 3か月前の@remore 9. ＿＿＿_ ／⌒ ⌒＼ ／（ ●） （●）＼ ／::::::⌒（__人__）⌒::::: ＼ 簡単だお！ | |r┬-| | ＼ `ー'´ ／ 後に現実を知ることになります
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
敢えてテストを書かないということ - くりにっき
元々は TDD Advent Calendar jp: 2012 : ATND で人数が足らなかった時の予備として用意していたのですが、めでたく人数が埋まったため単発で上げてみます。 僕は自他共に認めるTDDマニアですが*1、敢えてテストを書かないことの重要性について説きたいと思います。 id:shuji_w6e さんの 軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ と近いですが、shuji_w6eさんのがテストを軽くするのに対しこっちはそもそもテストを書かないようにするということです。 テストを書かなくてもいい（書く必要のない）ケース 寿命の短いプログラム TDDというのは最初にテストを書くコストというのがどうしても発生するため、寿命の短いプログラムだとTDDの恩恵を受けづらいです。 自分の経験上、半年以上メンテする必要があるプログラムだと保守フェーズ
JS開発におけるTDDと自動テストツール利用の勘所
1. JS開発における TDDと自動テスト ツール利用の勘所 2012.12.06 株式会社マピオン 中村 浩士 12年12月5日水曜日 2. 自己紹介 中村 浩士 ( @kozy4324 ) 株式会社マピオン所属 主にWebアプリのフロントエンド開発 JavaScript, ActionScript 12年12月5日水曜日
Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記
このエントリでは，Ruby on Rails （以下 Rails）の ActiveRecord モデルテストについて，1) どこの何をテストすればよいか，2) どのようにテストを書けばよいか，のガイドラインを示します．このガイドラインは Rails 公式のものではなく，id:passingloop が使っている私的なものです．疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします． はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです．Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります．しかし，「どこをどうテストすればよいのか」についての解説は，「使い方」の解説と比較して少ないように思います．もっとも，テスト一般についてどう書くかはアプ
テスト駆動開発Boot Camp(TDDBC)札幌2.1で講師をしてきました - 5.1さらうどん
event, Python | 08:42 | また、id:shuji_w6eさんにTAをしていただきたいなぁ、というお話を頂けたので、PythonチームのTAをしてきました。TDD Boot Camp 札幌 2.1 : ATND 今回は各言語毎にWebフレームワークを使ってシステムをTDDで構築していくというテーマでした。うちのチームは、DjangoというWebフレームワークを、Django標準のテストフレームワークではなく、noseというPython用UnitTestモジュールを使ってテストし開発するという手法を採用しました。 Installation and quick start ― nose v1.1.3 documentationjbalogh/django-nose - GitHubDjangoについては、最新版の1.3含め、ある程度の機能を使い慣れており、内部の実装にも明る
Rails テストに関する便利だけど見過ごされがちな 2 つの rake タスク - passingloopの日記
Rails テストで便利であるにもかかわらず知名度の低い、かわいそうな 2 つのタスク: rake test:recent タスク rake test:uncommitted タスク を紹介します。この記事は執筆時点の Rails 3.1.0.rc5 を対象としています。 Rails 謹製のテストタスク: rake test:* RSpec 使っていますか? もはや「デファクトスタンダードとなりつつある *1」 RSpec ですが、残念なことに私は使っていません。でも。そんな Test::Unit 遣いのために、Rails は便利な rake タスクを用意しています。たとえば、 rake test rake test:units rake test:functionals rake test:integration の各タスクは RailsによるアジャイルWebアプリケーション開発 第3版
社内向けにTDDの講習会を行いました - anfangsのログ
勤め先でTDDの講習会を行ったので、その内容について書きます。 この記事がTDD導入を検討している方の力になれば幸いです。 経緯 私はとあるSIerに務めており、部内ではテストの工数を削減することが課題となっています。 以前からTDDを同僚や先輩に宣伝していたこと、また、理解ある上司に恵まれたこともあって、 テストコードの書き方を講習する時間をもらえました。 そこで、TDDBCの要領で楽しみながらTDDを学んでもらうことにしました。 一人ではつらいので、TDDBCの参加経験がある先輩と二人で講習を行いました。 参加者について 若手開発者 3名 中堅開発者 2名 業務にオブジェクト指向の考え方を取り入れたのは2,3年ほど前?らしい。（要出典） 普段はC#、VisualStudio、VSSを使っている。 講習の目的 二人で話しあい、講習の目的を以下のように決めました。 テストコードの書きかたを
Expresso - TDD Framework For Node
Expresso 0.9.0 Expresso is a JavaScript TDD framework written for nodejs. Expresso is extremely fast, and is packed with features such as additional assertion methods, code coverage reporting, CI support, and more. Featureslight-weightintuitive async supportintuitive test runner executabletest coverage support and reporting via node-jscoverageuses and extends the core assert moduleassert.eql() ali
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルサムライの次に読む技術書
GitHub - hsbt/minitest-power_assert: Power Assert for Minitest
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
