ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日（月） http://www.jasst.jp/symposium/jasst20niigata.html
組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日（月） http://www.jasst.jp/symposium/jasst20niigata.html
Docker の Remote API + serverspec で CI - naoyaのはてなダイアリー
昨日 http://d.hatena.ne.jp/naoya/20130620/1371729625 で書いたように Docker を使えば、欲しい VM を "任意の状態" で簡単にかつ" "瞬時に" コピーして作り出すことができる。 「任意の状態」というのは、例えば「OS は CentOS で、Ruby と Chef が入っている」みたいな VM のこと 「瞬時に」というのは本当に瞬時。VM の起動時間を待ったり、Ruby や Chef を入れる時間を待つ必要はない serverspec でテストをする場合、真っ新な VM を用意してそれにプロビジョニングを行って、その後に破棄するみたいなことを良くする。このとき「真っ新なVM」を立ち上げるのに、Vagrant などが使えるが、Vagrant だとテストの度に VM を一から作り直す･･･つまり vagrant up しなければいけない
テスト駆動開発とは何か、それを気に入っているのは何故か、あなたも使うべきなのは何故か | POSTD
ペースが速い現代のソフトウェア開発環境では、テスト駆動開発（TDD）という言葉をよく聞きます。その利点だけでなく欠点についてもソフトウェア開発コミュニティでよく議論されています。TDDについて、”自己嫌悪に陥って屈辱を味わっている者に対する非現実的で効果のない道徳教育のようなものだ”と言う人もいれば [1] 、”リファクタリングを使って迅速な設計を支援するただのツールだ”と言う人もいます [2] 。 「ダメなプログラマは全てに答えを持つが、優れたテスタは全てに疑問を持つ」 Gil Zilberfeld しかし、TDDは新たな手法というわけではありません。広く知られている最も古い文献は1957年に出版されたD.D. McCracken著の『Digital Computer Programming: The First General Introduction in Book Form, St
JavaScriptのテスト環境の参考URLメモ(2015-03時点) - msakamoto-sfのはてなブログ
2015-03-30 JavaScriptのテスト環境の参考URLメモ(2015-03時点) JavaScript TDD JavaScriptのテスト環境、テストライブラリってどうなってるのか、参考URLをまとめてみました。 結論：ライブラリが数種類あり、それぞれがどこのレイヤーをカバーするのか異なる。そのため、組み合わせはもとより出力形式、CI環境との連携、なにをどこまでテストするのか、開発者のスキル、アプリケーションのライフサイクルなど多数のパラメータのバランシングが必要となる。ライフサイクルの短い使い捨てなら、バランシングのためのコストも無視して「えいやっ」で決めても良いが、そもそもテスト環境の整備が必要なプロジェクトであれば、ライフサイクルもそれなりの規模が想定される。技術者の自己満足や、流行り廃りに焦って拙速な判断を下さないよう厳重な注意が必要とされるだろう。数年後、流行り廃り
クラウドワークス勉強会「レガシーコード改善の戦略と戦術」（後篇：戦術＆懇親会） - CrowdWorks Engineer Blog
こんにちは！開発の所(@ctokoro_me)です。 クラウドワークス勉強会「レガシーコード改善の戦略と戦術」前篇（戦略）に続き、後篇（戦術＆懇親会）をお送りします。 「レガシーコード改善の戦略と戦術」 講師：和田 卓人(@t_wada) タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。 その後様々な縁に導かれソフトウェアパターンやXP（eXtremeProgramming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。 テスト駆動開発によって「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」から解かれてからは、文章や講演、ハンズオンイベント等を通じてテスト駆動開発の啓蒙に努めている。 今日もグリーンバンド（テスト駆動開発者の証）を左手に着
テスト駆動開発（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は彼の
AppTest | Remote TestKit
ブラックボックステスト技法の中の、網羅型の技法について解説します。 前回はブラックボックステストの導 […]
Kiwi＋CocoaPodsで始めるiOSアプリの振る舞いテスト入門
Kiwi＋CocoaPodsで始めるiOSアプリの振る舞いテスト入門：iOSアプリ開発でもCI／継続的デリバリしようぜ（2）（1/4 ページ） 現代の開発現場において欠かせないCI／継続的デリバリを、iOSアプリ開発に適用するためのツールやノウハウを解説する連載。今回は、iOSアプリの機能の振る舞いをテストするテスティングフレームワークの特長とインストールの仕方、主な使い方を解説します。 前回の「iOSアプリ開発でCI／継続的デリバリ環境を始めるための4種の神器」では、CI／継続的デリバリ環境を構築するために必要なツール・サービスを紹介しました。 今回はiOSアプリのためのテスティングフレームワークの1つである「Kiwi（キウィ）」を使った振る舞いテストの書き方について解説します。 振る舞いをテストするテスティングフレームワーク「Kiwi」とは KiwiはiOSアプリケーションの機能の振る
テスト駆動型開発についての議論 - ワザノバ | wazanova
http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約7時間前 Test Double社がブログで、TDD (テスト駆動型開発) を教える場合のアプローチを提案しています。 TDDについて、同じ用語やツールを使っていても、「モックオブジェクトがありすぎて、ひどい。」「モックオブジェクトがあふれていて素晴らしい!」という異なる見解に至るケースがでてしまっているのは、理想的なゴールに至る道筋を統一したかたちで教えきれてないからだと指摘しています。 TDDの一番の効果はコードのデザインの改善であり、コードのクオリティの担保は、うまくいけば二次的な効果、まかり間違えば幻想
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
なぜJavaScriptでテストコードを書くのか？
はじめに 第1回目の本稿は、実際にテストコードを書く前に、基本的な考え方である「なぜテストコードを書くのか？」を解説します。 対象読者 JavaScriptの基本をある程度理解している方 テストコードをこれから書こうと考えている方 頻繁な変化への対応 まずは、開発現場で多く行われている基本的な考え方を振り返り、テストコードがなぜ必要なのかを考えて行きたいと思います。 これまでのテストの考え方 まずは、一般的なウォータフォールモデルを例に考えてみましょう。通常ウォータフォールモデルでは、設計→実装→テストという順番で、作ったものを最後にテストします。最後にテストを行うというのは、言い換えると「品質を最後に担保する」と言えます。 また、最後にテストする場合は、通常テスト仕様書などを作成した上で必要なテストパターンを洗い出し、手動でテストを実施します。 変化への対応が求められている スタートアッ
JS開発におけるTDDと自動テストツール利用の勘所
1. JS開発における TDDと自動テスト ツール利用の勘所 2012.12.06 株式会社マピオン 中村 浩士 12年12月5日水曜日 2. 自己紹介 中村 浩士 ( @kozy4324 ) 株式会社マピオン所属 主にWebアプリのフロントエンド開発 JavaScript, ActionScript 12年12月5日水曜日
本当のJavaScriptを知っているか！具体的にコードで学べる「テスト駆動 JavaScript」 | Act as Professional
本書は裏表紙に「中級技術者向け」と明記されている。JavaScriptの言語仕様に関して、入門したことない人や、関数型の言語に見地のない人は、パーフェクトJavaScriptやサイ本あたりで、JavaScriptの言語仕様を身につけてから、取り扱うことを推奨する。それぐらい価値のある内容に本書は仕上がっている。 そして、 正統派なTDD(テスト駆動開発)について理解したい JavaScript自身の言語的な特徴を押さえておきたい テストできるJavaScriptのコードを多く閲覧したい 実際のプロダクトに活用できるアプローチを数多く知りたい と、考えているJavaScriptを日頃から書いている人、携わっている人に、必ず読んでもらいたい1冊である。 全体を通じて、テストできるコードの特徴は何か、単体テストとテスト駆動環境の利点を享受できる優れた単体テストはどのようなものかをサンプルとともに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
terranillius.com
いつでも聞けるTDD入門 #TDDBC_NAGOYA
Yutaka Yamashiro
TDD のこころ @ OSH2014
bitbucketの使い方
