テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました！ - Cookpad Staff blog
こんにちは、技術部の松尾(@Kazu_cocoa)です。 1ヶ月ほど前に開催しました、エンジニアトークナイト 〜異業種から挑戦したサービス開発〜 に引き続き、先日、10/21にクックパッドエンジニアのトークナイト〜クックパッドテストエンジニアのあり方〜を開催しました。 この会は、主にクックパッドにて働くエンジニアに焦点を当てながら、クックパッドにおける働き方やその周辺業界の流れを共有する、ということが主な目的になります。人事部の@emizusiやその他のメンバの尽力もあって、食事付きで開催されました。 今回は@t_wadaさんをゲストに、弊社エンジニアの@moro、@yoshioriとともに、特に今私が専門としていますテストエンジニアの、さらにはクックパッドにおける働き方に焦点を当てて話をしました。Twitterのハッシュタグは#cooketnです。 会は以下のスライドを進めながら、 比較
大規模 Web サービスの ブラウザテスト自動化・高速化
https://atnd.org/events/66159 で実施したプレゼン資料
悩んでるポイントはみんな同じ！？「Rubyistのためのテストコード相談会」の質疑応答まとめ - give IT a try
はじめに 先週の土曜日（2015年5月16日）に西脇.rb＆神戸.rbで「Rubyistのためのテストコード相談会 ～テストの書き方に悩んでいませんか？～」という勉強会を開催しました。 この勉強会は「テストコードに関する疑問や悩みをみんなで持ち寄り、みんなで解決すること」を目的にした勉強会です。 勉強会中はいろいろと興味深い議論が出たので、今回のエントリではその内容を簡単にまとめてみます。 勉強会で挙がった質疑応答 よく使うフレームワークは？ RSpecが大多数、Minitestが若干名。 gemを開発するときはMinitest、RailsはRSpec、というように開発内容によってフレームワークを使い分ける、という人もいた。 Minitestってどうなの？ 導入が簡単。assertメソッドだけ知っていればなんとかなる。 Railsにも対応している。Capybaraも使える。 RSpecのs
アジャイルテストのテスト設計の話 - Test Automation
Incremental test design 昨年度追加されたISTQBのFoundation Level Extension Syllabus Agile TesterのAgile Testing Practicesの項にはテスト設計に関する興味深い記述がある [1]。 Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones. アジャイルテストのテスト設計の特徴として ユーザーストーリーをテストベースとして用いる事 シンプルなテストケースの追加から始まり、より複雑なものへと変化して行く事 Increme
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組
はじめに これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。 id:a-suenamiがテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。（言いすぎだ 概要 言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを
Rubyのテスティングフレームワークの歴史（2014年版） - 2014-11-06 - ククログ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU
TDDを諦めることと、RSpecをやめること - 高柴ラボ
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
InfratasterでNginxのルーティングのテスト書いてる: InfratasterでNginxのルーティングのテスト書いてる, , Infratasterは、ServerspecみたいにRubyのRSpecの記法でテストを書いて、（例えば）HTTPリクエスト
[Infrataster] InfratasterでNginxのルーティングのテスト書いてるサーバーのテストはServerspecで書いているんだけど、Nginxの設定ファイルで書いているウェブサーバーのルーティングのテストをどうしようかと思っていました。自分で、簡単なツールでも書くべきかなあと。 /path/to/app でアプリケーションにプロクシーする 但しcookieがない場合は静的ファイルをサーブする /path/to/static/file で静的ファイルをNginxが直接サーブする /path/to/health/check でヘルスチェック用のレスポンスを返す、但しHTTPヘッダーを見て普通のブラウザーアクセスではForbiddenにする バーチャルドメインごとに微妙にパスとかが違う みたいなルーティングのテストは、外側からのテストなのでちょっとServerspecのスコー
RSpec初心者向けの資料まとめ[Ruby][Everyday Rails書評]
最近、RSpecやCapybaraでRailsのテストを書くたびに、ちょっとした書き方がわからずググったり、冗長なテストを書くことに結構悩んでいました。ということで、思い切ってRSpec再入門として、『Everyday Rails - RSpecによるRailsテスト入門』を読みました！ Rails/Rubyはどんどんバージョンアップするので、紙媒体の書籍だと情報が古くなってしまっている場合があります。この書籍は著者や訳者さんが、しっかりとアップデートを続けてくれているので、最新の入門チュートリアルとしてRSpecの実践的な使い方を習得できる書籍です。 またこの本を読むにあたってRSpecのドキュメントやWebサイトを読みなおしたので、合わせてRSpec初学者向けのマトメを作りました！ 🎉 RSpec 3初心者向けの資料まとめRSpec 3初心者向けの資料まとめ[Ruby] ちなみにその
![RSpec初心者向けの資料まとめ[Ruby][Everyday Rails書評]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
テストコードを書く文化を根付かせたい─和田卓人｜【Tech総研】
日本におけるテスト駆動開発（TDD）のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは── 父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。 ただ、私は初日から生意気にも「Excelで設計書を書き続けるために来たのではありません」と嘆願して、基盤
「DevOps時代のテスト自動化カンファレンス」に行ってきた！
こんにちは。 inomata@QAです。 最近、また自動テストがにぎわってる感じなので、情報収集のために、「@IT編集部主催:DevOps時代のテスト自動化カンファレンス 冬の陣」というのに行ってきました。 時代はDevOps。求められているのは柔軟性と速さ！そこで品質を保つにはテストを自動化するしかない！ という内容でした。 今から数年前の自動テストといえば、テストを繰り返すことで大幅なコスト削減！ というような触れ込みでしたが、時代は変わり「スピーディーかつ安定した品質のために」と変わったようです。 では各セッションのレポートです。 ・基調講演 リクルートSUUMO流DevOpsの捕らえ方と実践（株式会社リクルート住まいカンパニー） これは自動テストというより、DevOpsに対する取り組みの話でした。 こちらではDevOpsをOpsDevと捉えてプロセスを組んでいるとのこと。 OpsD
RailsのRESTful APIをテストで理解する - ワザノバ | wazanova
http://www.commandercoriander.net/blog/2014/01/04/test-driving-a-json-api-in-rails1 comment | 0 pointsPivotal LabsのEno ComptonがRailsでJSON APIをテスト形式で理解できるように紹介してくれてます。「Railsアプリをてがけると、いずれ、シングルページアプリ、モバイルクライアントのためにRESTful APIが必要になるだろうから練習用に。」ということで、コードはGithubで公開されています。 GET /movies POST /movies GET /movies/:id PUT /movies/:id DELETE /movies/:id 上記のrouteをサポートするために、Railsアプリ + RSpec + FactoryGirlを用意したら、
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
serverspec インフラ層のテスト項目を考える | Ore no homepage
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Introduction | テスト自動化パターン言語プロジェクト
アジャイルで欠落するテストの能力
レガシーコード改善の戦略と戦術
