ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
JavaScript tests on your Continous Integration server
A modern web page does a lot of things, hence the term web application has become more commonly used over the last year. A consequence of this is that we are crafting widgets and entire modules using JavaScript, or at least in some language that eventually ends up being “compiled” to JavaScript. Where there is code there should also be tests. And the tests need to go green every time the code is c
角谷HTML化計画 - デブサミ2009:パネルディスカッション：テストを行うこと、テストを続けること
Invalid Text■<%=sn number %> <%=flickr_left '3277186245' %>デブサミ2009:アート・オブ・アジャイル デベロップメント〜テストが駆動するビジネス価値〜 (あとで書く)2009/02/18追記 fkino先生最新監訳書籍、『アート・オブ・アジャイル デベロップメント』(TAOAD)のレビューは別途エントリを書くつもりなので、ここではデブサミでのセッションについて。 前半はTAOADを踏まえて、実体験も交えながら(って他人事みたいだけど一緒にやったプロジェクトの話)、XP的に「行儀のよい」テストに対する向きあい方。ここまではちゃんとテストトラック。 で、驚愕の展開の後半。TAOADを媒介に、前半のテストトラック的な内容からシームレスに「飛躍」、一転して話は開発プロセストラックに。ここでもTAOADを下敷にしながらも、fkinoじしんの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
