タグ

TDDに関するtksthdnrのブックマーク (49)

  • テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組

    はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか?」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま

    テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
  • XCTestCase /<br/>XCTestExpectation /<br/> measureBlock()

    Although iOS 8 and Swift has garnered the lion’s share of attention of the WWDC 2014 announcements, the additions and improvements to testing in Xcode 6 may end up making some of the most profound impact in the long-term. This week, we’ll take a look at XCTest, the testing framework built into Xcode, as well as the exciting new additions in Xcode 6: XCTestExpectation and performance tests. Most Xc

    XCTestCase /<br/>XCTestExpectation /<br/> measureBlock()
  • Web APIを利用するiOSアプリのテスト技法 - cockscomblog?

    もう先週ですが、表題のタイトルで「Consumer Service Engineer MeetUp Vol.1 ~iOS編~」という会でお話しさせていただきました。 このようなタイトルの発表にした理由についてですが、はてなとしてお話しするということで、ちょっと硬派な方に振ってみました。結果としては良いバランスだったのではないでしょうか。 発表資料を掲載します。 また以下に発表の概略を書いておきました。ご参考ください。 前提 このMeet Upの主旨が「コンシューマ向けのWEBサービス(アプリ)の企画・開発・運営をしている会社によるエンジニア向けの講演、パネルディスカッション、懇親会を含めたMeetUpです!」となっていましたので、それではWebサービスとアプリを繋ぐWeb APIについて、それを利用するiOSアプリについて考えます。Web APIというのは古くて新しい話題で、いまや専らJS

    Web APIを利用するiOSアプリのテスト技法 - cockscomblog?
  • iOSエンジニアといいかんじなテストの話 - laiso

    Consumer Service Engineer MeetUp Vol.1 ~iOS編~ - dots. に行った。 最近あんまりザ・iOSアプリ開発らしいことしていなかったので情熱的な各社の話を聞けておもしろかったし、意識の高まりを取り戻せてよかった。 時間なかったので感想書く余裕ないかと思っていたんだけど、http://ainame.hateblo.jp/entry/2014/04/25/014605 の感想なんかを読んでたら触発された。 人力テスト 自動テスト vs 人力テストの構図というよりは、デベロッパーテスト、品質管理とユーザーテストやユーザビリティテストの違いで理解していた。 テストの目的と観点、誰が何をテストするのかという部分に注目するとスッキリすると思う。 講演した各企業の担当の人はユーザビリティテストに積極的だが、デベロッパーテストはうまくいってないという話を確かにし

    iOSエンジニアといいかんじなテストの話 - laiso
  • なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog

    ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、質的にJavaScript

    なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
  • RSpec Performance Turning

    社内のRSpec勉強会で使った資料です http://sue445.hatenablog.com/entry/2013/07/30/235502

    RSpec Performance Turning
  • RSpec: Overview

    Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel

    RSpec: Overview
  • RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明

    🖥 VULTRおすすめ 「VULTR」はVPSサーバのサービスです。日にリージョンがあり、最安は512MBで2.5ドル/月($0.004/時間)で借りることができます。4GBメモリでも月20ドルです。 最近はVULTRのヘビーユーザーになので、「ここ」から会員登録してもらえるとサービス開発が捗ります!

    RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明
  • DRY原則とテストの可読性 - ✘╹◡╹✘

    DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い

    DRY原則とテストの可読性 - ✘╹◡╹✘
  • RSpec の入門とその一歩先へ - t-wada の日記(旧)

    和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま

  • Guardを使ってファイル更新時にブラウザをオートリロード - ひげろぐ

    ファイルを変更したらブラウザを自動でリロード、という開発効率うpの技がGuardを使うと簡単にできるよという話。 とりあえずFirefox派としてguard-mozreplを使ってみましょう。 Firefox側での下準備 MozReplを入れて ツール -> MozRepl -> Start しときましょう。 guard-mozreplの導入 まずGemを入れる。もちろんBundlerを使ってもよろしい。 Guardの動作に必要なGemもついでに入れる。 gem install guard-mozrepl rb-fsevent growl 上記はMacの場合で、LinuxWindowsの場合は必要なGemが異なる。 詳細はGuardのREADMEに書いてあるのでそちらを参照のこと。 Guardfileの作成 次にプロジェクトのディレクトリで次のコマンドを実行。 guard init mo

  • RSpecによるユニットテストの書き方 — recompile.net

    2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる(かもしれない)。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと

    RSpecによるユニットテストの書き方 — recompile.net
  • ノーフレームワークのレガシーPHPがCIに乗るまで

    ついに仕事で触っている PHP のコードがほんの一部のテストとは言え CI に乗った。 正直これは感動ものだ。 今回はここに至るまでの長大な物語をダイジェストでお届けしようと思う。 有史以前PHP 3 で作られた 1 URI : 1 スクリプト + 共通関数 時代 当然のように PHPHTMLSQL 混在まともなテスト環境がなかったので似た環境をどうにか作るパスとか絶対で埋め込みまくりなのでとりあえず共通のパス情報の変数に差し替えまくりテスト環境用のコードと番環境用のコードが違うオール目視 つらかった。 みなさんの予想通りバージョン管理なんてものは存在しなかった。 素朴なPHPを徐々にclassにclass になれば phpdoc を書きやすくなるいきなり実行しないようにすればテストしやすくなる これは後から気づいたんだけど、結局フロントはロクに自動テストできてない一時期 p

  • Jasmine + Sinon.js を使って Backbone.js アプリケーションをテストするチュートリアルを読みました | CreativeStyle

    Jasmine + Sinon.js を使って Backbone.js アプリケーションをテストするチュートリアルを読みました JavaScriptのためのBDDテストフレームワーク「Jasmine」と、簡単にスタブやモックオブジェクトを導入する「Sinon.js」を使って、JavaScriptのためのMVCフレームワークである「Backbone.js」で書かれたアプリケーションをテストするチュートリアル記事を読みました。 全3部構成。英語。 Testing Backbone applications with Jasmine and Sinon – Part 1 – Tinned Fruit Testing Backbone applications with Jasmine and Sinon – Part 2. Models and Collections – Tinned Frui

    Jasmine + Sinon.js を使って Backbone.js アプリケーションをテストするチュートリアルを読みました | CreativeStyle
  • Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

    『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

  • PHPでBDD(Behavior Driven Development)する方法

    みなさんこんにちは。@ryuzeeです。 RubyであればRSpecやCucumberとか使って、むしろBDDしているケースの方が多いようですが、PHPでやっている事例はあまり聞きません。 とりあえずPHPでもBDDできることは確認できたので、その方法をご紹介します。 ※実戦投入にはもうちょっと検証は必要かもしれません。 BDDとは?BDDとはビヘイビア駆動開発(Behavior Driven Development)でテスト駆動開発から派生したものです。 テスト駆動開発とドメイン駆動設計を統合したようなイメージになります。 対象における「振る舞い」や「制約条件」の検証のために、自然言語的な記述でテストコードを記述します。 スペックファーストで仕様を作ってから実装するという流れになります(コードを書く前に振る舞いを決める)。 ということで、以下ではPHPでBDDを行う方法について解説してい

    PHPでBDD(Behavior Driven Development)する方法
  • Node.jsのテスティングフレームワーク「Mocha」(前編) : ryu22eBlog跡地

    2011年12月19日 Node.jsのテスティングフレームワーク「Mocha」(前編) Mochaのチュートリアルに沿ってMocha(読み:もか)を使ってみました。 長いので前編・後編の二部構成にします。 使用するMochaのバージョンは0.3.6です。 はじめにこのエントリーのために書いたサンプルコードは以下に置いておきます。 https://github.com/ryu22e/mocha-example FeaturesGoogle翻訳と辞書を頼りに翻訳しました。もっと適切な訳があればご指摘お願いします。 browser support(ブラウザサポート) simple async support(シンプルな非同期サポート) proper exit status for CI support etc(CIサポート等のための適切な終了ステータス) auto-detects and di

    Node.jsのテスティングフレームワーク「Mocha」(前編) : ryu22eBlog跡地
  • テストフレームワーク mocha - hokaccha memo

    JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース)3日目のhokacchaです。Node.jsのテストフレームワーク、mochaについて書きます。 mochaはTJが新しく作り始めているテストフレームワークです。ドキュメントを見ればできることは大体書いてありますので、ドキュメントを元にどういうことができるのかを解説していきます。現時点でのバージョンは0.2.0です。 http://visionmedia.github.com/mocha/ shouldについて まずmochaでどういうことができるかの前にshouldについて解説しておきます。mochaのドキュメントには特に説明もなくshouldが使われていて、shouldでどういうことができるかわかってないと、ドキュメントを読んだときにmochaの機能なのかshouldの機能なの

    テストフレームワーク mocha - hokaccha memo
  • mocha と Jenkins で Node.js の CI 環境を構築する - hakobera's blog

    最近、mocha をつかってテストを書くのが楽しくなってきました。でも、テストの数が増えてくるとローカルでの実行だけでなく、CI 環境が欲しくなりますよね。github にあげられるようなプロジェクトだったら、Travis CI も良いですが、実際に仕事で使うとなると、既存の Jenkins と組み合わせてやる必要ができてきたので、実際にやってみました。 基的な手順は以下の通りです。 mocha でテスト結果を TAP 形式でファイルに出力する 出力したファイルを Jenkins の TAP Plugin に読み込ませる 簡単ですね。 実際にやってみた というわけで、以下のような最小構成で試してみます。 myapp |- lib | |- calc.js | |- test | |- calc.test.js | |- package.jsonここには書いていませんが、実際は git

    mocha と Jenkins で Node.js の CI 環境を構築する - hakobera's blog
  • node.js+QUnit+QUnit-TAP+ant+JenkinsでJavaScriptのCI

    2004 01 02 03 04 05 06 07 08 09 2004年9月:1エントリ 10 2004年10月:1エントリ 11 2004年11月:1エントリ 12 2004年12月:1エントリ 2005 01 02 03 04 2005年4月:13エントリ 05 2005年5月:18エントリ 06 2005年6月:28エントリ 07 2005年7月:42エントリ 08 2005年8月:39エントリ 09 2005年9月:41エントリ 10 2005年10月:22エントリ 11 2005年11月:20エントリ 12 2005年12月:35エントリ 2006 01 2006年1月:12エントリ 02 2006年2月:6エントリ 03 2006年3月:10エントリ 04 2006年4月:17エントリ 05 2006年5月:9エントリ 06 2006年6月:12エントリ 07 2006年7