タグ

テストに関するmonochromeganeのブックマーク (20)

  • テスト(コード)レビューの方針 書きなぐり版 - うさぎ組

    牛尾さんのブログをはてブったら、「じゃぁ、その手を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト(単体テスト)の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな?」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか?もしあったら記事にはります。」 僕のコメント「書いていません!」 僕のコメント「書きました!」 僕の主張 記事は僕の実験結果(経過報告)であり、

    テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
  • 自動テストの誤解とアンチパターン in 楽天 Tech Talk

    2014/02/12の楽天Tech Talkに登壇させてもらったときの発表スライドです。 2013年に発表したいくつかの内容をまとめました。 基的に、ソフトウェアテストの絶望を聞きたい人向けです。Read less

    自動テストの誤解とアンチパターン in 楽天 Tech Talk
  • TDD のこころ @ OSH2014

    This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur

    TDD のこころ @ OSH2014
  • Post by @shyouhei

    俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけでってるので、そういう意味では若干の後ろめたい気持ちもある。 俺が現職に転職してきて一番びっくりしたのはなんといって

    Post by @shyouhei
  • テスト考2014 - Hidden in Plain Sight

    年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも

    テスト考2014 - Hidden in Plain Sight
  • プログラムに証明が付く日 | RANDMAX

    この記事は「Theorem Prover Advent Calendar 2013」6日目の記事です。 http://qiita.com/advent-calendar/2013/theorem_prover 神田「野らぼー」にて、地下の薄暗い店内で… 「そう言えばこないだ隣で起こってたポインタオーバーラン、対応大変そうだったですけどちゃんと家に帰れてたんでしょうかね、新婚なのに…」 「ヌルポとかポインタオーバーランとか、どうして無くならないんだろうね。その時はみんな手を抜いてるつもりなんて毛頭なくて、一生懸命考えて大丈夫だと思ってるはずなんだけどね。レビューもして、それでも起こった後でみんなでソース見てみると、なんで気づかなかったんだよ!ってことになる。」 「人間って、そういうの苦手なんでしょうねきっと。ほら、『何かほかにありませんか』って聞かれても出てこないじゃないですか。静的な解析っ

    プログラムに証明が付く日 | RANDMAX
  • Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記

    テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ

    Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
  • 必ずスパムと判定されるメールと、ウィルスの作り方 - プログラマでありたい

    メール文中に下記の文字列をいれると、対応しているスパムフィルターはそのメールをスパムとして判定されます。このコードは、GTUBE(Generic Test for Unsolicited Bulk Email)と呼ばれ、テスト用のコードです。 XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X GTUBE - Wikipedia SpamAssassin: The GTUBE 同様にウィルスにもEICARテストファイル(EICAR Standard Anti-Virus Test File)というテスト用のファイルを作ることが出来ます。空のファイルに下記の文字列を貼りつけると、あら不思議ウィルスファイルが作れます。(正確に言うとウィルスと認識されるファイルです。) X5O!P%@AP[4\PZX54(P

    必ずスパムと判定されるメールと、ウィルスの作り方 - プログラマでありたい
  • 「自動受け入れテスト」を考えてみる - 日々常々

    きっかけは XP祭り関西2013 の @StoneGuitar777 さんのLTからです。 LTスライド: XP祭り2013-LT-Codeer @ITの記事: 特集:受け入れ検査の自動化手法の考察:Windowsアプリの受け入れテストを自動化しよう (1/5) - @IT 「継続的デリバリー」に貼付けた付箋を抜き出してみる 【大阪】継続的デリバリー読書会(8回目) - connpassの範囲でもありました。 受け入れ=ビジネス的な受け入れ基準=ユーザーの価値 ユニットテストとの色分け ユニットテスト: 作り手の意図 受け入れテスト: 顧客の意図 うまくやらないとコストが高すぎる 適切に作成して保守すれば自動のほうがはるかに安上がりになる ユニットテストやコンポーネントテストではどれほど包括的にやっても検出出来ない問題がある 手動テストはアプリケーションの複雑さに関わらずきわめて高くつく

    「自動受け入れテスト」を考えてみる - 日々常々
  • 時計オブジェクト(ドメインクロック)を導入してテスト容易性と意図性を高める

    現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。 <?php ... class OrderService { ... public function order(Order $order) { $currentHour = (integer) (new \DateTime())->format('H'); if ($currentHour >= 10 && $currentHour < 21) { ... } else { throw new OrderException('ご注文は午前10時から午後9時まで!'); } } ... 実際の現在の時刻に依存せずにif文の条件をテストする1つの方法は、DataTimeオブジェクトの生成部分をメソッドとして抽出し、そのメソッド

  • JenkinsとSelenium WebDriverでUI層のテストも自動化&永続化する - プログラマでありたい

    思い立ったようにJenkins特集をしておりますが、今回はJenkinsとSelenium WebDriverでUI層のテストの自動化をする話です。Seleniumは面倒臭い画面のテストを自動実行してくれるツールで、出てきてからもう7〜8年がたちます。Web系の開発に携わっている人であれば、一度は試したことがあるのではないでしょうか?そして、必ず挫折したことがあると思います。 その理由としては、せっかく作ったSeleniumのテストケースが腐ってくるからです。一般的にはUI層の変更は、ロジック層に比べて変化が激しいです。だからこそテスト自動化して保証することに意味があるのですが、そのテストケースを維持するのは大変です。そこで、Jenkinsの登場です。Jenkinsでサーバサイドで継続的に実行することにより、Seleniumのテストケースが成功を保てるようにします。また、複数のブラウザ・バ

    JenkinsとSelenium WebDriverでUI層のテストも自動化&永続化する - プログラマでありたい
  • Capybara-Webkit+Cucumber+Sinon.JSでJavaScriptのテストはここまで変わる

    Capybara-Webkit+Cucumber+Sinon.JSでJavaScriptのテストはここまで変わる:フレームワークで実践! JavaScriptテスト入門(5)(1/3 ページ) しっかりとJavaScriptをテストするために、今注目のJavaScript用のテストフレームワークをいくつか紹介し、その概要から実践的な使い方まで解説する連載。今回は、RubyでWebKitをヘッドレス化するフレームワーク、受け入れテストの記述が日語でできるツール、スタブやモック、スパイが使えるライブラリを組み合わせたテスト方法などを紹介。 Capybara-WebkitとCucumberとSinon.JSを利用したJavaScriptのテスト 連載の最終回となる今回は、これまでの連載のようなJavaScriptのロジックを単体テストするのではなく、Webブラウザ上の操作と、それによって動作

    Capybara-Webkit+Cucumber+Sinon.JSでJavaScriptのテストはここまで変わる
  • Androidでレガシーコードを書き続けないためのたった1つの方法 - ブログなんだよもん

    答え:テストできるように作る 周りでAndroid開発してる話を聞くのですが、どうもテストがしづらかったり、修正が大変だったりする模様。ここを直してあそこがバグるみたいな。 屋で参考になりそうなを探すも、入門系かリファレンス系が殆どで、「どういう設計にするべきか?」とか「Android Test」とかAndroid向けフレームワークの話がさっぱり無い。そんな状況なので、入門書片手にアプリを書き始めた人は、ViewとLogicを始め、色々なものが適切に分けられてないコードを作り、テストの無いレガシーコードが量産されていくのかな、と。 そういう分けで最初の結論になります。 ちょうど、ちょっとしたAndroidアプリを書いてみようと思ってたので、ここら辺を参考に実際のアプリに先立っていくつかのフレームワークを組み合わせたAndroid-Development-Suiteを作成。 いわゆるサン

    Androidでレガシーコードを書き続けないためのたった1つの方法 - ブログなんだよもん
  • Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記

    このエントリでは,Ruby on Rails (以下 Rails)の ActiveRecord モデルテストについて,1) どこの何をテストすればよいか,2) どのようにテストを書けばよいか,のガイドラインを示します.このガイドラインは Rails 公式のものではなく,id:passingloop が使っている私的なものです.疑問・質問・批判・間違いの指摘はページ下部のコメント欄までお願いします. はじめに Rails は TDD/BDD サポートが充実した Web アプリケーション開発フレームワークです.Rails で使える Test::Unit や RSpec などといったテスティングフレームワークの使い方に関する解説も豊富にあります.しかし,「どこをどうテストすればよいのか」についての解説は,「使い方」の解説と比較して少ないように思います.もっとも,テスト一般についてどう書くかはアプ

    Rails の ActiveRecord モデルテストの書き方ガイドライン - passingloopの日記
  • RSpecでRailsのテストをしてみるテスト。 | Ginpen.com

    めもめも。 この記事はRubyRailsもよくわかっていない人が自分のためのメモとしてだらだら書きました。リファレンスがよくわからなかったので、動かして試してみた感じです。 RSpecは(Railsに限らず)Rubyで動くテストフレームワーク。Railsに最初から入ってるTest::Unitよりも色々と良いらしい……けどそっちも使った事がないので比較はできません。 RubyじゃなくてRailsから利用する視点から俺用にまとめます。 環境 $ ruby -v ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux] $ rails -v Rails 3.2.1

    RSpecでRailsのテストをしてみるテスト。 | Ginpen.com
  • メモ 【Zendframework】Controllerのテスト

    クイックスタートのアプリが完成したので、Zend Framework: Documentation: Zend_Test_PHPUnit(日語) - Zend Framework Manualを参考に、Zendframeworkでのテスト方法を実施していきます。 ※前提として、PHPUnitがインストールされていること テスト用のコントローラとテストコントローラの作成 まずZend_toolを使用してコントローラを作成します。 zf.bat create controller User Userコントローラ、UserTestコントローラ、ビューにindex.phtmlが作成されていれば問題無しです。 setupメソッドの修正 setupメソッドは、テストする環境設定用のメソッドです。Zend_toolで作成した場合、下記のように記述されています。 public function setU

  • RSpec を使い始める人が読むべき N 個のドキュメント

    こんにちは、ほりいです。Asset Pipeline に感銘を受けている今日この頃です。 今日は社内で RSpec をこれから勉強したいんだけど検索してもよくわからない!と質問を受けたので、読むべきエントリをまとめてみました。 # 現状ぐぐると RSpec.info がまず出てくるけどもう更新されてないっぽいので優しくないんですよね…… h2. これは読んでおこう! h3. スはスペックのス * “スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)”:http://jp.rubyist.net/magazine/?0021-Rspec * “スはスペックのス 【第 2 回】 RSpec on Rails (コントローラとビュー編)”:http://jp.rubyist.net/magazine/?0023-Rspec 内容は若干古いのですが、

    RSpec を使い始める人が読むべき N 個のドキュメント
  • TDD | みつおですけどなにか。

  • TDD(テスト駆動開発)を学ぶための動機になる話 | Act as Professional

    TDDがアジャイル開発では前提 ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテスト リファクタリング テスト駆動開発(TDD) 継続的インテグレーション これら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニ

    TDD(テスト駆動開発)を学ぶための動機になる話 | Act as Professional
  • テスト初心者Androiderのためのソフトウェアテスト入門

    3. 自己紹介 • 渡辺 悟史(わたなべさとし) • 仕事AndroidSNSアプリ開発 • 過去には組み込みWebブラウザ開発 • 得意 : C言語/Android • 興味: モバイル関連/Web関連/UX関連 • twitter: @sassy_watson

    テスト初心者Androiderのためのソフトウェアテスト入門
  • 1