タグ

testに関するramtigaのブックマーク (11)

  • Rails でテストをどう書くべきか備忘録

    今朝聞いた今週の rebuild.fm のポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。 Rebuild: 43: Kent is More Professional (Kenn Ejima) 以下 rebuild.fm 話題から参考にしたいメモ ・テスト書くのは良いが、テスト原理主義、100%カバー、全部テストファーストにこだわるのは疑問。 ・内部構造、実装に対するテストは書かない。 ・モックは一番外側のAPI、インターフェースに対してだけ使う。(※) ・モックのためのモックとかは避ける。 ・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。 ・テストとコードを同時に変更すると、トラブルに気付きにくくなる

    Rails でテストをどう書くべきか備忘録
  • Test::Unitでテストを書く - Qiita

    テストの書き方 基 今までのTest::Unitと変わらないので,classで書く.ただ,昔のTest::Unitとは違い,TestCase毎に呼ばれるstartupやshutdownなどが増えている. require 'test/unit' class TestSample < Test::Unit::TestCase class << self # テスト群の実行前に呼ばれる.変な初期化トリックがいらなくなる def startup p :_startup end # テスト群の実行後に呼ばれる def shutdown p :_shutdown end end # 毎回テスト実行前に呼ばれる def setup p :setup end # テストがpassedになっている場合に,テスト実行後に呼ばれる.テスト後の状態確認とかに使える def cleanup p :cleanup

    Test::Unitでテストを書く - Qiita
  • go言語のテスティングフレームワークについて - さにあらず

    画像周りの動作が意味不明かつ使い辛いので移転しました。 go言語のテスティングフレームワークについて — さにあらず

    go言語のテスティングフレームワークについて - さにあらず
  • テスト書きすぎ問題 - hitode909の日記

    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

    テスト書きすぎ問題 - hitode909の日記
  • Travis CI 入門:GitHub + Travis CI で継続的インテグレーション « をぶろぐ

    1. Travis CI とはTravis CI はオープンソースコミュニティのためにホストされた CI(継続的インテグレーション)サービスです。 継続的インテグレーションってなんだ? 継続的インテグレーション、CI(英: continuous integration)とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。エクストリーム・プログラミング (XP) のプラクティスの一つで、狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。特に、近年の開発においては、継続的インテグレーションをサポートするソフトウェアを使用することがある。 引用: 継続的インテグレーション - Wikipedia Travis CI は GitHub と連携しており、CI したいリポジトリーを接続しておくと、Travis CI がコミットを

  • 噂のRuby&Githubなプロジェクトにスキな継続的インテグレーションサービス「Travis CI」を試してみたらすごくよかった

  • Ruby用単体テストフレームワークtest-unitでのデータ駆動テストの紹介 - 2013-01-23 - ククログ

    test-unitRuby用のxUnit系の単体テストフレームワークです。2.3.1からデータ駆動テスト機能が追加されていたのですが、2.5.3まではリファレンスに記述がなく、知る人ぞ知る機能でした。 2013-01-23にリリースされた2.5.4ではデータ駆動テスト機能についてのドキュメントが追加されています。 データ駆動テスト自体の説明はUxUを用いたデータ駆動テストの記述を参照してください。 Cucumberのscenario outlinesに似ていると言えばピンと来る人もいるのではないでしょうか。 Cucumberのscenario outlinesも前述のククログ記事の通り、テストのデータとロジックを分離しているのでデータ駆動テストの一種と言えます。 今回は、データ駆動テストを導入した例を見ながらtest-unitでのデータ駆動テスト機能の使い方を紹介します。なお、以降の説明

    Ruby用単体テストフレームワークtest-unitでのデータ駆動テストの紹介 - 2013-01-23 - ククログ
  • 単体テストの書き方の話 - ✘╹◡╹✘

    皆さんAとBどちら派ですか / unit_test_spec.rb — Gist bit.ly/ODGJSo— 人さん (@r7kamura) 9月 19, 2012 普段はAで書いてるけどBもよさそう— Issei Narutaさん (@mirakui) 9月 19, 2012 普段A派です。— ryo katsumaさん (@ryo_katsuma) 9月 19, 2012 @r7kamura Aです— SHIBATA Hiroshiさん (@hsbt) 9月 19, 2012 @r7kamura 内緒です— SHIBATA Hiroshiさん (@hsbt) 9月 19, 2012 B の方が読みやすいし書きやすいけどメンテダルそうなイメージ— ɐɯıɥsǝʞɐʇ ɐʎnzɐʞさん (@mitukiii) 9月 19, 2012 情弱なのでA知らなかった— トデス子さん

  • Sinon.JS を使った JavaScript のテスト - mixi engineer blog

    初めましてこんにちは。ソーシャルクライアント開発の tanabe と申します。 今回は?Sinon.JS を使った JavaScript のテスト方法を紹介したいと思います。 Sinon.JS って何? Sinon.JS はノルウェーのエンジニア Christian Johansen さんが書かれた、JavaScript 用のライブラリです。スタブやモック、フェイクオブジェクトの提供に特化していて、QUnit などのテスト用のフレームワークや実行環境に依存しない所が特徴です。Christian Johansen さんは?Test-Driven JavaScript Development の著者でもあり、こちらは近々翻訳版 が登場するようです。 では早速、Sinon.JS を使ったテスト手法をご紹介していきたいと思います。稿ではテストフレームワークは QUnit を採用しています。 時間

    Sinon.JS を使った JavaScript のテスト - mixi engineer blog
  • SQLiteを使ったテストのtips

    DB周りのモジュールを開発している場合、テストDBSQLiteを使う事が良くあります。 その際、普通であれば以下のようなテストコードを書くと思います use Test::More tests => 1; use DBI; do { # SQLiteで使うファイルを指定 my $dbh = DBI->connect('dbi:SQLite:./test.db','',''); $dbh->do(q{CREATE TABLE foo (id INT, name TEXT)}); $dbh->do(q{INSERT INTO foo (id, name) VALUES (10,'nekokak')}); my $sth = $dbh->prepare('SELECT * FROM foo'); $sth->execute; my $row = $sth->fetchrow_hashref();

  • 天使やカイザーと呼ばれて: Ruby on Railsのテスト環境が気持ちいい

    Javaな世界に10年以上どっぷりと浸かってきたが,Ruby on Rails(RoR)をやっていると「良く考えられているなぁ」と感心してしまう箇所が随所に見られる。とかくScaffoldやActiveRecordに関するコーディングに目が行ってしまいがちだが,僕個人的にはテストに関する環境が最も「おぉ」と感じている。 言うなれば,「JUnit + DbUnit + Cactus」な環境が標準で整備されている,ということだ。 JUnitについては,もちろんTest::Unitがそれに相当する。Test::Unit::TestCaseクラスを継承し,”test_“で始まる名前のメソッドを定義していくというのは,xUnitの流儀とほぼ一致している。JUnitで単体テストを行ったことがある開発者は,違和感なくTest::Unitでテストケースクラスを書いていけることだろう。 Web+DBアプリケ

  • 1