外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker DeckOct 31, 2018 at AWS Dev Day Tokyo 2018 #AWSDevDay #AWSTDD
【Vue.js】いつから「フロントエンド開発でTDDができない」と錯覚していた？ - Qiita
Vue.jsのコンポーネント開発をTDDでやってみる ※ TDD (test-driven development): テスト駆動開発 ※ テスト駆動開発は文化です。チームの「状況」「納期」「スキルレベル」、その他いろんな要因が絡んできた結果、そのチームが導入するかどうか決めたらいいと思います。 ※ 例えがいいかはわかりませんが、私は「早起き」と「テスト」は同じようなものだと思っています。「早起き」は健康にいいよねって誰でも言うと思うけど、実際に万人がやっているかどうかは別じゃないですか。それと同じで「テストすること」も絶対いいことだと私は思っていますが、やるかどうかはチームの置かれている状況によって決まります。この記事は、その「テストを導入するかどうか」という意思決定の一助にでもなれればいいなと思います。 はじめに こんにちは。ぼくです。 今回はVue.jsでTODOアプリを作ってみよう
『再演 ~ 組織にテストを書く文化を根付かせる戦略と戦術 ＋α』メモ #t_wada - nashcft's blog
また過去に参加した勉強会のメモ。今回のは3/11ともはや半年以上前... まあもう諦めても良かったのだけど、9月頭 (これも1ヶ月近く前...) にあったprivate methodの件だったり職場で最近あったお話だったりがこの講演で扱われた話題に関連している気がするなあと感じたので、折角だしと思って掘り出してまとめることにした。 connpass.com togetter.com 組織にテストを書く文化を根付かせる戦略と戦術 from Takuto Wada www.slideshare.net 転送サーバおけるテストの自動化 · GitHub メモは最後に貼るとして、講演の内容の内2点について、この記事を書いている時点までにあったことも含めて思っていることをまとめる。これらを書いていて、半年以上前の講演で、それもスライドに残されていることではなくその場で話されていたようなことやそれにつ
和田(t_wada)さんに技術相談をしました - CureApp開発者ブログ
2016 - 11 - 07 和田(t_wada)さんに技術相談をしました 二週間ほど前にはなりますが、 日本のTDD( テスト駆動開発 )の先駆者である和田さん(t_wada)をお招きして、 技術相談会を行いました。 日頃、開発時に感じていた悩みを聞いていただき、 和田さんにビシバシと解決していただきました。 そこで今回は特に印象に残った、 不安定なテストとの付き合い方 フレームワーク 選定基準 品質保証のやり方 について書こうと思います。 不安定なテストとの付き合い方 私たちは、普段から不安定なテストに悩まされていました。 不安定なテストとは、 ローカルでは通るけどCIでは落ちる 遅くて タイムアウト になるときがある など、コードでなく環境によって結果が左右されるテストのことです。 この不安定なテストによって、開発に新しく関わった人に毎回同じような説明をしたり、説明をし忘れて不要な対
テストを書くか書かないかの判断の話
writing_unit_test.md ユニットテストでテストを書くか書かないかの判断の話 お題 メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか テストとは まず、基本の考えとしてなぜテストをするのか？というのがあります。 テストとは、エラーをみつけるつもりでプログラムを実行する過程である。(via ソフトウェアテストの技法 [Glenford J. Myers]) という言葉のとおり、最小の手間でプログラムのエラーを見つけ出そうとする試みがテストです。裏を返せば、エラーが見つかる可能性が低いのにすべてのことを試すのはテストではありません。 判断するときの論点 いくつかこれを判断するときの論点があります (Boolean に限らず、「そのテストは必要か？」と考えるときの観点ともいえ
VOYAGE GROUP エンジニアブログ : QUnit+PhantomJS+JenkinsでJavaScriptの品質を改善！
2014年09月24日14:15 カテゴリprogrammingtesting QUnit+PhantomJS+JenkinsでJavaScriptの品質を改善！ はじめまして！cosmiRelationshipSuiteの開発者であるマルィシェフ・ドミトリーと申します。 世の中で、Webベースシステムが増えており、管理画面の開発を担当している、エンジニアの視野から抜けがちであるJavaScriptのテストについてお話します。最近の数年、TDD概念が非常に流行っており、Model(ビジネスロジック)をテストするJUnitやPHPUnitの利用は当たり前のようなことになりました。それと同じく、JS(要するに、Front側のロジック)のテストがをしっかりできる環境として、QUnit+PhantomJS+Jenkinsの組み合わせを紹介したいと思います。 初めに この度、localhostで開発
効果的なテストの文化を創る
自動テストの場合、シナリオ、実行、検証はすべてプログラムによってドキュメント化され自動化されます。唯一の手動のセットアップはシナリオ実行のボタンをクリックするだけです。記憶に頼る必要もありませんし、賞味期限の切れたドキュメントを頼って、シナリオを追いかけ、手動で実行する必要はないのです。 ほとんどの開発者が自動テストの価値を認めながら、その利点を享受するのに失敗しています。私は幸いなことに、利点を享受するための正しい方法を見つけることができました。 責任 テストに責任を持つことがなかったら、テストを自動化する時間はなかったでしょう。これはとても単純なことです。自分が開発を支援したシステムのサポートを担うことで、私はソフトウエアがきちんと動作することを保証するということに大きな関心を抱きました。午前5時に電話で起こされて問題を解決するのはごめんです。私は問題がその日のうちに解決するようにこつ
クラウドワークス勉強会「レガシーコード改善の戦略と戦術」（後篇：戦術＆懇親会） - CrowdWorks Engineer Blog
こんにちは！開発の所(@ctokoro_me)です。 クラウドワークス勉強会「レガシーコード改善の戦略と戦術」前篇（戦略）に続き、後篇（戦術＆懇親会）をお送りします。 「レガシーコード改善の戦略と戦術」 講師：和田 卓人(@t_wada) タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。 その後様々な縁に導かれソフトウェアパターンやXP（eXtremeProgramming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。 テスト駆動開発によって「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」から解かれてからは、文章や講演、ハンズオンイベント等を通じてテスト駆動開発の啓蒙に努めている。 今日もグリーンバンド（テスト駆動開発者の証）を左手に着
クラウドワークス勉強会「レガシーコード改善の戦略と戦術」（前篇：戦略） - CrowdWorks Engineer Blog
こんにちは！年初からクラウドワークス開発に新たにジョインした所と申します。 先日、クラウドワークスではテスト駆動開発とRESTFulアーキテクチャのエバンジェリストとして有名な和田卓人さんをお招きして社内勉強会を開催いたしました。 和田さんは、数多くの会社にてレガシーコード改善のコンサルティングの経験をお持ちで、書籍も多数執筆されており界隈でも有名な方です。 また、弊社CTO大場の旧知の友人でもあります。 クラウドワークスのサービスは立ち上げから現在に至るまでRuby on Railsで開発を行っており、サービス拡大に伴いアプリケーションの規模も大きくなっています。 比較的テストが書きやすいフレームワークではあるものの、ビジネスの急激な成長を支えるために速度を優先した機能開発が行われていた時期もあり、レガシーコードが残っている部分があります。 将来に向けて技術的負債の返済をしていくことは、
型付けを活用してテストを減らす：静的型を使ったTDD Part 1 | POSTD
私はテスト駆動開発（TDD）について、Kent Beckの著書『 Test-Driven Development By Example 』（邦訳『テスト駆動開発入門』）で学びました。これは大変優れた入門書で、TDDにますます関心を持つようになった私は、さらにSteve FreemanとNat Pryceの著書『 Growing Object-Oriented Software, Guided by Tests 』（邦訳『実践テスト駆動開発：テストに導かれてオブジェクト指向ソフトウェアを育てる』）を読みました。この本も私のお気に入りです。 ただし、両書には弱い部分もあります。現代の静的型システムがテストを補ったり、場合によっては置き換えたりできるかもしれないことには、全く触れていないのです。このような本を読んだだけでは、”typing”（型付け）と聞いてもキーボードの”タイピング”のほうを考
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
「最強」のチームを「造る」技術基盤
「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る ＝ 栽培する・耕す 4 CI/CD TDD ATDD この３つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト駆動開発の過去・現在・未来 / History of TDD - XPJUG 2018 Keynote
組織にテストを書く文化を根付かせる戦略と戦術 / Strategy and Tactics of Building Automated Testing Culture into Organization