「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
node.jsでこんなのもテストしたい!! という話 - Qiita
テストフレームワークは、busterJSが一番慣れてたんですが、 部署御推薦のmochaをいっちょやってみるかー、と思っているこのごろです。 そしてついでに、 「このへんは、node.jsの場合どうテストするのがかっこいいかしら!!」 と気になっていた部分について、いろいろ調べてみました。 mochaの細かい説明については、公式その他をみてください。 mochaっていうかほとんどshouldですよね。 普通のテスト(libraryやcontrollerのテスト) テストしたいmoduleをrequireして、 shouldもrequireして、テストを書く。これが基本ですね。 // テストしたいmoduleをrequire var hoge = require('../hoge'); // テスト用のライブラリをrequire (mochaの場合は、shouldがあればいいはず) var
javascriptでテスト駆動開発 Mocha+expect.js+testem【前編】 - yutaponのブログ
JavaScriptのテストをするツール達 テスト駆動するときに必要なツールが2つあります。 テストフレームワーク テストランナー テストフレームワーク いわゆるxUnit系のツールがこれにあたります。 JavaScriptでの有名ドコロは下記のスライドが参考になります。 JS開発におけるTDDと自動テストツール利用の勘所 私はまだ2つしか使ったことがありません。 Jasmine http://pivotal.github.io/jasmine/ Mocha Mocha - the fun, simple, flexible JavaScript test framework どちらもBDDライクな書き方で好きです。 特にMocha（モカと読みます）の方ですが、単体では使わず should.jsやexpect.jsなどのアサーションライブラリと組み合わせて使います。 これはmocha単体の
expressで作ったHelloWorldをsupertestでテストする
node.jsのためのWebアプリケーションフレームワークexpress。主にURLルーティングのテストには supertest が便利。 (1) expressでHelloWorld express の Getting started に従って、HelloWorldを表示するWebアプリを作ってみる。 $npm install express $vi app.js var express = require('express'), app = express(); app.get('/hello.txt', function (req, res) { res.send('Hello World'); }); app.listen(3000, '0.0.0.0'); $node app.js app#send を使うと、Content-Length を自動的に追加してくれる。 ブラウザから
PeepCodeに学ぶ node.js+express のblankプロジェクトを作る - Ken's Blog
本ブログは東京Node学園祭2012 アドベントカレンダーの2日目の記事です。 Smashing Node.jsを私も読んでいるのですが、それより前にPeepCodeのFull Stack Node.jsを見て、node.js+expressでアプリケーションを作る時にいつも同じことをやるので、復習がてらに、blankプロジェクトを作ってみました。このブログではその内容を紹介します。 前提 node.jsは既にインストール済みであることを前提とします。また、私の環境は Mac OS X です。 expressプロジェクトの作成と必要なmoduleのインストール ここはいつも通りです。 express blank create : blank create : blank/package.json create : blank/app.js create : blank/public cre
require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー
先日書いた自分用アプリケーションのひな形 http://d.hatena.ne.jp/naoya/20130503/1367581629 http://d.hatena.ne.jp/naoya/20130504/1367640512 これに、JavaScript のテスト環境も追加したい。 結論からいくと、フレームワークには mocha + expect、ランナーは testem を使うことにした。ついでにテストダブルライブラリとして Sinon.js も有効にした。 ちなみに今回の文脈は End to End のテストではなくてユニットテスト周りのおはなしです。 mocha + expect JavaScript のこの辺のテスト周りは今もいろいろなツールの整備が進んでいて、今回採用した以外にも Jasmin や QUnit そのほか色んな物がある。昨今の状況に関しては 先日の HTML
フロントエンドJavaScriptにおける設計とテスト
今日話さないこと JavaScriptの基礎知識、jQueryの導入 気持ちいいUIやUXがうんちゃら CanvasやWebGLを使ったリッチでイケてるゲームの作り方
テストフレームワーク 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の機能なの
Haskellで書いたCGIをPerlでテストする - Pixel Pedals of Tomakomai
以下は、aとbに渡された数字を足し算するだけの簡単な(?)CGIです。 #!/usr/bin/env runghc {- sum.cgi -} import Network.CGI import Control.Monad cgiOutput (Just n) = do setHeader "Content-Type" "text/plain" output $ show n ++ "\n" cgiOutput Nothing = do setHeader "Content-Type" "text/plain" output "" cgiMain = do a <- getInput "a" b <- getInput "b" cgiOutput $ foldl (liftM2 (+)) (Just 0) (map (liftM read) [a, b]) main = runCGI $
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
第27回 Test::Most：Test::Moreでは物足りなくなってきたら | gihyo.jp
Test Anything Protocol Perlは非常にテストを重視している言語です。連載第14回ではPerl本体のテスト数がどのように推移してきたかを、また連載第24回ではCPANモジュールの品質保証に大きな役割を果たしてきたCPANTSについて簡単に紹介しましたが、Perlとテストのつながりはそれだけではありません。CPANにはTestを名前に含むディストリビューションが500以上もあがっていますし（これは全ディストリビューション数の約2.5％にあたります）、Perlで標準的に使われているテスト形式はTest Anything Protocol (TAP)という名前を得て多くの言語に移植され、2008年からはIETFの標準化を目指した活動も始まっています――というと何やらすごいプロトコルのように聞こえるかもしれませんが、Test Anything Protocolというのは要
PlaggerにTest::Perl::Criticのテストが追加されました。が - ヒルズで働く@robarioの技ログ
いつの間にやらTest::Perl::Criticのテストが追加されていますが、コード品質のテストは開発者用テストなのでエンドユーザには必要ないのでは？と思っています。自分の場合以下のようなコードによって、明示的にmake test TEST_CRITIC=1（またはTEST_ALL=1）とした場合のみ実行されるようにしています。 t/01perlcritic.t #!/usr/bin/env perl # # $Revision$ # $Source$ # $Date$ # use strict; use warnings; use version; our $VERSION = version->new(qw$Revision: 0 $); use English qw(-no_match_vars); use FindBin qw($Bin); use Test::More; if
.tファイルを t/hoge/*.t に置きたいとき - Practice of Programming
今日はYAPC::Asia 2008 でしたね。僕は最近の体調の悪さ具合を考えて、午前中は自分の体調と相談してました。 いけそうだなーと思ったので、午後から参加。 YAPCでテストの話題があったから、書いている...わけではないけど。 ExtUtils::MakeMaker を使ってる場合ですが、Tutorialには、 t/ の下にフラットにファイルを置かないといけないと書いてある。 t/ Tests for your modules go here. Each test filename ends with a .t. So t/foo.t/ 'make test' will run these tests. The directory is flat, you cannot, for example, have t/foo/bar.t run by 'make test'. でも、ちょ
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - teppeis/testem-requirejs-mocha-sample: Sample project for Testem, RequireJS and Mocha
Testing with Node.js