かっこ悪くて面倒でもテストコードを書こう - 今川館
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
TDDをはじめる条件 #tddbc #tddconf - やさしいデスマーチ
色々と忙しすぎてブログが書けません。 JavaOneの話とか、JUnitの話とか色々書きたいんですが…もうしばらく我慢なのです。 で、TDDの前方依存と後方依存で意見が欲しいとのことなので自分なりの意見を。 技術的な前方依存 『TDDを始める前と終TDDを実際やるために必要な技術』 ・最低限対象言語でコードがかけるようになって ・最低限テスティングフレームワークを使えるようになって ・リファクタリングをしっかり学んで ・対象言語でのきれいなコード、設計とは何かを知って ・テストファーストを知って こうしておそらくスタートライン。 自分はこれは疑問です。 最後の「テストファーストを知って」という部分はTDDに関することですけど、それ以外ってTDDを始めるスタートラインではなく、ソフトウェア開発としてのスタートラインかと思います。 言い換えると 最低限対象言語でコードを書けないと、ソフトウェア
RSpecでRailsのテストをしてみるテスト。 | Ginpen.com
めもめも。 この記事はRubyもRailsもよくわかっていない人が自分のためのメモとしてだらだら書きました。リファレンスがよくわからなかったので、動かして試してみた感じです。 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
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 直
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
クライアントのテストはzombie.jsでいいんじゃないか - mizchi log
zombie.jsとは jsdomというnode製のDOMシミュレータがあります。これを使えば、ブラウザを使わずにDOMイベントを発行することができます。 zombie.jsはセッション管理とブラウザのアクションを管理するjsdomのラッパーです。 個人的には、Ajaxのテストは無理せずJavaScriptでやれとおもってるので、その点zombieは素直に動いてくれます。 利点 AjaxでDOMを書き換えたりするイベントもテストできる (qt-webkitと比較して) 無茶苦茶早い コンパイルが楽(というかQTは定期的に互換崩れてバイナリ壊れてる… 論よりコード サンプルをアップロードしてあります mizchi/zombie-tester-example https://github.com/mizchi/zombie-tester-example インストール等はReadme見てもらうと
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
いまどきの Ruby 書くときのテスト環境 - Stats of the Rivers
romaji というライブラリを書いた。 - 寿司じゃないブログ という記事を書いたのだが、テスト環境について反応があったのでもうちょい詳しく書く。 RSpec テスティングツールのデファクトスタンダード。 http://rspec.info/ に行くか、The RSpec Book を読もう。 Guard ソースコードが編集されているかを監視して、変更があった場合に自動でテストを走らせてくれる。 guard/guard · GitHub guard と guard-rspec を gem install して、以下のようなファイルを Guardfile という名前でプロジェクトのルートディレクトリに置き、 guard コマンドを走らせると、watch で指定したファイルの変更の監視してくれる。 guard 'rspec', :version => 2, :all_after_pass =
sinatraでテストの入門の入門(その1) - tomiの日記
「sinatraすげー」って今さら思い、sinatraで何か作ってみようかねーと思い、当然テストのことが気になりました。 そもそも「テスト出来るの？実はrailsと比べて大変じゃないの？？？」って感じのアホな不安でした。(1週間前までsinatraのことと言えば名前しかしらなかったので。。)テストについてはちゃんと公式ページで解説されています。rspecも使えます。capybaraも使えます。他のテストフレームワークも使えるようです。 参考ページは Testing Sinatra with Rack::Test です。ここの内容を理解していきます。 サンプルコード テスト対象のコード。いつものhello world。 require 'sinatra' get '/' do "Hello World #{params[:name]}".strip end テストコード require '.
るびま
『るびま』は、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 直
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
自覚 - naoyaの寿司ブログ
きれいなコードを書こうぜ、といってるのに対して製品の善し悪しに綺麗なコードがいいかどうかなんて関係ない、みたいな話とか 仕様書とかぜんぜん読まないから仕様書なんて全く必要ない、さっさとコード書けとかコードだけで語れ、とか TDD されてないからリファクタリングできないんだ、だからカバレッジ100%にするんだ、ぜんぶテスト書け、とか エンジニアは技術から出発して需要を考えない、だから問題から入れ、技術なんて関係ない、とか 企画屋は技術のことがわかってないから、夢物語りばっかり語るんだ、エンジニアがサービス作るべき、とか そういう、何かを反面教師に反対の考え方を支持するみたいなのは注目浴びやすいけど、視座をもうすこし中立にして考えると、だいたいおかしい。かくいうぼくもそんな風に煽ってる時期がありました、若さって怖いです ─ 中庸って知ってるか。伝統や、むかしから習慣として良しとされてきているこ
TDDのはじめかた #TddAdventJp - 千里霧中
本エントリはTDD Advent Calendar jp: 2011の12/8の担当分の記事で、id:t-wadaさんの「右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記」に続くものです。 はじめに TDDはシンプルな原則に則った手法ですが、とっつきの悪さもしばしば持たれがちです。また一連のTDD Advent Calendarで起こった議論や会話の中でも、TDDの始め方はどうすれば良いかという話が散見されましたので、自分の担当枠では「TDDのはじめかた」についてまとめたいと思います。なお紹介するのはあくまで数ある入門方法のうちの１つです。たぶん他にも色々な良い入門方法があると思います。 全体像 紹介する入門方法は以下のようなステップバイステップの構造となります。 いつでも軽快に使えるユニットテスト環境を構築する 必要と感じたらすぐテストを活用する テスト並行を
DailyJS: Testing with Mocha
Mocha (GitHub: visionmedia / mocha, npm: mocha, License: MIT) by TJ Holowaychuk is a new test library that does just about everything a JavaScript developer needs, and yet remains customisable enough to support both behaviour-driven and test-driven development styles. Mocha presents itself as an unassuming and lightweight library, but it actually goes far beyond the test frameworks I’m familiar wi
QUnitの基本的な使い方 - but hopeful
[追記] 2013/9/1 三年前の記事が未だに読まれているようなので、一応書いておきますが、あれから色々変わってもっと良いものも出ています。 QUnit でも別に問題はないですが、今から QUnit を使うよりは http://visionmedia.github.io/mocha/:title=mocha] とかの方が個人的にはお勧めです。とにかく、今は色々あるのでもっと別の選択肢調べて見ることを個人的にはおすすめします。別に QUnit は使わないほうが良いとは言いません。 JavaScriptのテスティングフレームワークはいろいろありますが、自分は今主にQUnitを使っているので、少し使い方をまとめて見たいと思います。 [追記]今回作成したソースを上げました。ninja.js QUnit とは QUnitはもともと、jQueryをテストするために開発されたJavaScript Un
TDD Boot Camp(TDDBC) - 主なユニットテストフレームワーク
主なユニットテストフレームワークと、 関連するプラグインなどを紹介します。 また、 それが使われたことが分かっている TDDBC も記載しました。 (SCMS などの言語に依存しないツールであっても、 使われた言語のところに載せてあります。)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gihyojp - ニコニコ
