クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました！ - Cookpad Staff blog
こんにちは、技術部の松尾(Kazu_cocoa)です。 クックパッドで働くエンジニアに焦点を当てたトークナイトシリーズ、第3段を先日、11月26日に開きました。今回も前回に続きテストエンジニアに焦点を当てました。今回はゲストとして @m_seki さん、 @miwa719 さんのお二方にお越し頂きました。お二方には栃木から足を運んでいただきました。今回も、弊社人事部の@emizusi等が素晴らしいサポートをしてくれました。 前回・今回と、テストという言葉を以下のように大きく分類した上で話題をまとめていきました。前回はCheckingの色を強くするためにTDD/BDDの一つの側面を取り上げました。今回はTestingの色、さらにはよくある技法の話ではなく人に寄った開発風景の話を取り上げました。 テスト |---> Checking ---> 前回 | \---> Testing ---->
クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜 感想 - いもろぐ
2015/11/26 に行われた クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜 - connpass に運良く(倍率3倍)参加できて、とても内容が良かったので共有します。 当日の資料が公開されましたのでリンクしておきます。 speakerdeck.com 感想 JaSST、Ques、TestingCasualに参加したことがあるのですが、品質とかテスト関係のイベントとしては今回はだいぶ新鮮というか、新しいアプローチというか、一言でいうと来て良かった。抽選に当たって良かった。vol.1ではBDDとかTDDとか、Checking(正しく動くことを確認する)視点での話がされたようで、なんで私は落選したのだろうかと。そこ(も)聞きたかったよと。 今回の発表で下記のワードが出たかどうか分かんないけど、私的なキーワードとしては 探索的テスト大事 (多分このワード
クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜 (2015/11/26 19:00〜)
概要 前回に続き、今回もテストエンジニアにスポットライトをあてます。ゲストには、m_sekiさん、miwa719さんにお越しいただきます。 「Checking vs Testing」において二つの概念が紹介されました。既知の問題を確認するCheckingと、未知の問題を探求するTestingです。 前回はTDD/BDDという開発技術寄りな話を交えながら、主にCheckingに関してお話ししました。 今回はもう一方の「Testing」に焦点を当てます。 あれ？おかしいな、に気づくことがTesting のはじまりです。それは、製品からはもちろんのこと、製品の作り方、作るチームなど、みなさんの身の回りで見つかるでしょう。 今夜は登壇者が日ごろ感じるTestingのかけらについて、みなさんとお話ししたいです。 (探索的テストの技法、といったことは言及しない予定です) 登壇者 松尾 和昭(クックパッ
Not Angularな環境でProtractorを使ってES2015(ES6), ES7なE2Eテストコードを書いてみた - Qiita
追記 注意 サンプルコードなので省いていますがコードではawaitとしてPromiseのコールバックを隠ぺいしています。 実際にはPromiseがresolveではなくrejectを返すこともあるので、実際のコードではtry-catchを使ってちゃんとエラーを捕捉しましょう。
クラウドワークス勉強会「レガシーコード改善の戦略と戦術」（後篇：戦術＆懇親会） - CrowdWorks Engineer Blog
こんにちは！開発の所(@ctokoro_me)です。 クラウドワークス勉強会「レガシーコード改善の戦略と戦術」前篇（戦略）に続き、後篇（戦術＆懇親会）をお送りします。 「レガシーコード改善の戦略と戦術」 講師：和田 卓人(@t_wada) タワーズ・クエスト株式会社 取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。 その後様々な縁に導かれソフトウェアパターンやXP（eXtremeProgramming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。 テスト駆動開発によって「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」から解かれてからは、文章や講演、ハンズオンイベント等を通じてテスト駆動開発の啓蒙に努めている。 今日もグリーンバンド（テスト駆動開発者の証）を左手に着
ricollab Web Tech Blog » Blog Archive » Mock と Stub について
初めまして、リコーの沖田です。この度私もこの blog を書くことになりました。以後よろしくお願いいたします。 みなさんテストは好きですか？私も含めて私の同僚は皆テストが大好きなので、しばしばテストの議論で白熱しすぎてしまいます。今日はそのテストの中から Mock（モック） と Stub（スタブ） について書いてみたいと思います。 Test Double まずテストにおける Mock と Stub についてですが、これらは Test Double という概念の一部です。Double とは代役という意味で、テスト対象となるシステムが依存する外部のコンポーネントの代わりに、それらしく振舞ってくれるコンポーネントを代役として利用しようということです。 例えば Web アプリの Controller の単体テストがしたい場合に、Model の実装が完了するまでテストができないっていうのでは大変です
WhatIsTesting
テストとテスティング XPの出現以来、それ抜きの開発は考えられないほど、テスティングフレームワークは必須のものとなりました。 「テスティングフレームワーク」 しかし、この呼び方になにやらうさんくさいものを感じる人もいるでしょう。 なぜ、「テスト」ではないのか？ ここでは、テスティングという言葉の感覚を伝えたいと思います。 なお、アジャイル開発における「言葉」についてはAgileNaKotoBaを参照してください。 テストとはなんでしょうか？ 私たちが日常的に利用する「テスト」という言葉は、品質保証テストのように、既に存在する仕様に基づいて実装された完成品が、基準を満たしているかを検査するという意味で使います。 同じように学校の期末テストは、既に学習した内容が学生の身についているかを判定します。 ここにあるのは、静的な基準であり、テストは既に完成した製品や知識に対して動かしがたい事実の判定を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストメソッドを日本語で書くことについて