最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出
前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト BDD on Haskell チュートリアル その3-1 catch できない哀しみ BDD on Haskell チュートリアル その3-2 throw Exception を使わず基本は Either を使おう BDD on Haskell チュートリアル その3-3 : 仕様変更はテストから BDD on Haskell チュートリアル その4 : リファクタリングとパフォーマンスチューニング 今回はテストコ
前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト BDD on Haskell チュートリアル その3-1 catch できない哀しみ BDD on Haskell チュートリアル その3-2 throw Exception を使わず基本は Either を使おう BDD on Haskell チュートリアル その3-3 : 仕様変更はテストから 今回のテーマ 「テスト済みのモジュールのパフォーマンス改善」前回までで一通りの TDD / BDD によるアプローチで
前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト BDD on Haskell チュートリアル その3-1 catch できない哀しみ BDD on Haskell チュートリアル その3-2 throw Exception を使わず基本は Either を使おう 今回のテーマ - 「テスト済みのモジュールの仕様変更」前回書いたように，IO が絡まないはずの関数群に Exception を throw させるよりは Either <Error> <Success>
前回の続き．前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト BDD on Haskell チュートリアル その3-1 : catch できない哀しみ 「どちらか」を表現する Either 型Control.Exception の try catch finally はそもそも IO モナドで利用される事を想定している．つまり 外部からの入力や Haskell の実行結果を出力する境界で発生する予期しない事態に対応する為のものだ． なので，IO に本当は依存してな
前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト 前回までで，ほぼ TDD BDD の基本は書いたのだけど，今回は例外について． Haskell の例外処理Haskell も普通の言語よろしく，例外処理は throw try catch 使える．けれど IO が絡んでくる場合でないとあまり有用ではない印象． throw try catchHaskell の try catch throw finally は Control.Exception モジュールで定義され
新年のご挨拶あけましておめでとうございます． 2012年は Schemer, Haskeller にとって飛躍の年でありますよう心から願う所存であります． デザインについてはあと最終勧告まで2年を切った HTML 5 がそびえたつクソにならない事を切に祈り，ユーザビリティ，アクセシビリティ，ユースケース，UX をガン無視した「CSS3だけで出来たなんちゃらかんちゃら」「美麗なビジュアルエフェクトを実現する jQuery プラグイン」で衆目を集めてなんちゃってクリエイティブ気分を味わってる人たちが滅亡してくれる事を期待しています 前回までのエントリーBDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 BDD on Haskell チュートリアル その1 : HUnit で TDD を 今回は QuickCheck を使ってランダ
すこし日が空いてしまったけど，BDD on Haskell チュートリアルの続き． 前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 今回は HUnit を使って，基本的な TDD (BDD でなく) の進め方について． 例 商と，小数の余剰を返す関数 を定義してみる今回のチュートリアルで適当に「ある程度需要があって，あるとそれなりに便利なもの」として，Scheme の RSR6 で採択された div mod をやってみる． Haskell の mod についてHaskell の標準実装である mod rem は整数型しか受付けず，また返りも整数型なので，たとえば，Javascript や Ruby のように小数の余剰を返すことは無い． $ ghci Prelude> :t mod -- mod
@t_wada「TDDはスキルです。量は質に転化する」 TDD Advent Calendar2011の記事になります。 TDD Advent Calendar jp: 2011 : ATND 前：@irof テストと言うパートナー #TddAdventJp - 日々常々 次：@yuya_takeyama さんです。 はじめに これは僕の主観であって、間違いもあると思います。それは僕の勉強不足から生じるものです。 どちらかというと、これを読んだ方に「そこはちょっと認識が一般的じゃない」「そもそも違うよ」って突っ込んでもらうためのものです。 「TDDよくわからないので教えてください」っていう記事です。 TDDをはじめたい人、TDDに行き詰まっている人 TDDがどんなものかよくわからない人、とりあえずテストコードって書いているけど毎回つまずいて成長が実感出来ない人、現場に導入したいけど伝え方が
前回の記事で Haskell で BDD する基本的な構成は出来たので，これから実際に簡単なチュートリアルを書いてみる．あと HPC を Cabal に設定させてビルドテストからテストカバレッジレポートも生成させる要領もわかったので，そっちの準備等も書く その前に 前回の記事の追記公開したら，まさに「もっとスマートな方法ありますよ」という反応が．インターネットってすばらしい GHC 7.0.2 以降，Cabal 10.2 だと Test-Suite 指定が出来る自分の環境が GHC7.0.2 なのに cabal-install が 0.8.2 というあべこべな状態だったので，前回のような方法でしかビルド構成できなかったのだけど，元々，GHC 7.0.x 同梱の cabal-install 0.10.x 以降は exitcode-stdio でちゃんとテスト構成を指定する事ができる，とのこと
ひさしぶりの Haskell ネタ 2011/12/13 追記下の例で app.cabal の設定や Setup.hs の記述などの情報が古かったので，こちらも一読してください → BDD on Haskell チュートリアル その0 経緯Haskell でそれなりのプログラムを書いてみようとしたので，HUnit や QuickCheck を使って BDD でやろうとしたのだけど，How to write a Haskell program 以上の事を誰も書いてないし，HUnit や QuickCheck の実例を書いた日本語圏のブログ記事も，その単体モジュールのテストのみ書いていて，肝心の全体テストを通しで実行するなどのネタが書かれていない． じゃあ実際に公開してるリポジトリでも見てみるかと思い，patchtag を見ても今度は公開してる人の殆どがテスト書くとかしてなかった．Haskel
テスト駆動開発が嫌いだ。 ただし、ここでの「テスト駆動開発」は日本で今TDDと呼ばれてる多義的なものじゃなく、「テスト駆動開発入門」にかかれている「テスト駆動開発」。 もっと正確にいうと「テスト駆動開発入門」がミスリーディングをわざと誘ってて有害で嫌い。 テストは、プログラムが正しく動くことは検証できるけど、プログラムが正しいことは検証できない。そのようなテストに設計を依存してしまうと、正しく動くプログラムは作れるけど正しいプログラムは作れない。 設計も含めてテストによって駆動しましょうという「テスト駆動開発入門」のやり方では正しいプログラムが作れない。プログラムの正しさを別のやり方で担保しつつ、そちらを中心に開発を駆動して、あくまでも開発作業だけをテストで駆動するという考え方のほうが、正しいプログラムに近づける。 そして、TDDをいまがんばってる人たちも、それは当たり前にわかってると思う
0. node.js の Vows フレームワークがとてもかわいい JavaScript のTDD, BDDフレームワークはたくさんあるけど，テスト結果の見た目の良さと記述の楽さで Vows というフレームワークを使っている．RSpec からの影響を受けていて，Rack アプリケーションのテストと同じような感覚で書ける，というのが良い． たとえばこんな感じでテストコードを CoffeeScript で書く で --spec オプションをつけて実行するとこういう風に表示してくれる． assertion でテストが通らないと黄色く，内部エラーの場合は赤にラベルが表示される． しっかり全部通すと このように表示される．見た目が良いし，ラベリングを丁寧にやるとテストの内容がわかりやすい． 元々 node.js のテスト用なので，require exports など， pure JavaScript
あらすじ 前回のエントリでMacOS マシンにも最新の PHP と PHPUnit, Phing が入り，開発途中になって pear や pecl のライブラリをインストールできるようになったのだけど，このままだとまだ NetBeans でホイホイ開発できるようにはなってない．このエントリで残りの環境構築をやる /etc/php.ini をコピー 前回のビルドで，PHP は再インストールしたわけだけど，実は MacOS にはデフォルトの /etc/php.ini ファイルが無かったりする．(これは今回びっくりした) なので，pecl のライブラリなんかを呼び出せないままになっているのが確認できる．というわけで前回の PHP をビルドしたフォルダから php.ini-production なんかをコピーして編集する．(php.ini-development でも良いけど，別に PHP そのも
あらすじ PHP で開発するにあたって，「やっぱり複数人で開発するし，NetBeans とか IDE 使いたいよねー」的な話になったので，NetBeans を入れて，これまでリモートのサーバー上で Phing 使ってテストしてたのだけど，それをローカルマシンでやるにあたって，PHPUnit をインストールすることになった．バンドルされてる PHP も古いバージョンだし． しかし，SnowLeopard に標準でインストールされている PHP には --with-pear 付きでビルドされておらず，しかも，バンドルで付けられていたビルドオプションをコピペして，追加して ./configure しても，--with-jpeg-dir とかでコケるという愉快なトラブルでえらく時間かかった． というわけで，ビルドちゃんと出来るようになるまでの手順ログを書いておく 入れたい/使いたいモノ PHP 5
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く