TDD is dead. Long live testing. (DHH)
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
体育の日って高速に唱えるとテストの日に聴こえる - ✘╹◡╹✘
テスト書きすぎ問題 - hitode909の日記 階層が増えるとテストが増える - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 最近書いているWebアプリは、HTTPリクエストを送ってレスポンスと状態をテストする、というテストだけ書くようにしてる。リクエストするとブログエントリを返す、というサービスだとこういう風なテストを書いてる。(HTMLを返すようにすると話が広がって説明が面倒なのでJSONを返すAPIで説明する) describe "Entry resource" do let(:params) do {} end let(:env) do { "HTTP_AUTHORIZATION" => "Bearer: #{access_token.token}" } end let(:access_token) do AccessToken.make(user
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので読み返してみました。 Testing like the TSA by David of 37signals（TSAはTSAロックのTSAですね。RailsConf行く時に買った） 予想通り、DHHはなんでもかんでもテストを書くということに対してはだいぶ批判的なスタンス。 曰く、テストを書くということの裏側には、テストを書く時間、テストをアップデートする時間、テストコードを読んで理解する時間といったコストが発生しているので、テストを書くことによって得られるメリット（回避できる問題）とのバランスをよく考える必要がある、と。 議論を呼ぶことは承知のうえでDHHが提案する「Railsアプリのテストにおいて、やってはいけない7つのこと」は以下の通り。 100%の
Rails4で書いたアプリをMiniTest::Specでテストする - yo_waka's blog
Rails4からはActiveSupport::TestCaseがTest::UnitからMiniTest::Unit::TestCaseのサブクラスに変わっている。 MiniTestはSpecなDSLをサポートしているので、RSpecを入れずともBDDスタイルでテストが書けるようになる。 ということで、いろいろtest_helper.rbをゴニョってたらminitest-rails-specというズバリなGemを見つけたので（＞＜）これを使う。 minitest-spec-railsでやってくれることは、ざっくりいうと、RailsのActiveSupport::TestCaseにMinitest::Spec::DSLをextendして、ControllerとかHelperクラスをテスト対象クラスに追加して、beforeとかafterとかのDSLを使えるようにしてくれるだけというシンプルな
なんとなくRSpec使ってるやつダサい - 方向
先日、第5回若手Webエンジニア交流会でLTしてきました。 ビール飲んでピザつまみながらLTきいたりLTしたりするのカジュアルでいいですね。 というわけで、スライド公開します。 Testing Frameworkについてで、 「なんとなく、とりあえず、RSpec」みたいなのはダサいよねというお話 スライド http://yayugu.github.io/rktn_presen/wakate_web_engineers_koryukai_5th.html スライドの原稿 テストとかの話 矢口裕也 (@yayugu) 「みんなー テスト書いてる？」 みたいなの飽きたよね 今日は TDDとBDDとAgileとかの開発スタイル と テスト哲学の話を しません Testing Framework の話をします Testing Framework 大きく分けて2つ xUnit xSpec xUnit
目指せ、テストカバレッジ100%
Social Media & Content Marketing - An Optimized Approach #OptimizeBookTopRank Marketing Agency
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
GitHub - FactoryBoy/factory_boy: A test fixtures replacement for Python
factory_boy factory_boy is a fixtures replacement based on thoughtbot's factory_bot. As a fixtures replacement tool, it aims to replace static, hard to maintain fixtures with easy-to-use factories for complex objects. Instead of building an exhaustive test setup with every possible combination of corner cases, factory_boy allows you to use objects customized for the current test, while only declar
テスタブルJavaScript
最重要テーマは「テストに適したコードの作成と保守」。本書は複数のアプローチで、テストに適したコードに迫ります。まず複雑さについて考察し、続いて複雑さや結合を軽減できるようなアーキテクチャを検討します。これを基盤として、機能レベルとアプリケーションレベルでのテストについての解説に進みます。カバレッジやデバッグについて十分な知識を得て、最後に自動化に関する解説で本書は締めくくられます。最後まで読めば、テストに適したJavaScriptの本質と実践について漏れのない理解を得られるでしょう。著者がYahoo!やGoogleで培ったテストや品質管理についてのノウハウをJavaScriptに適用したWeb開発者必携の一冊。 まえがき 1章 テストに適した JavaScript 1.1 今までの手法 1.1.1 アジャイル開発 1.1.2 テスト駆動型開発 1.1.3 ビヘイビア駆動型開発 1.1.4
Better Specs. Testing Guidelines for Developers.
What is Better Specs Better Specs is a collection of best practices developers learned while testing apps that you can use to improve your coding skills, or simply for inspiration. Better Specs came to life at Lelylan (open source IoT cloud platform) and checking out its test suite may be of inspiration. Better Specs focus on Rails testing, but our goal is to create testing guidelines covering mos
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Trying to mock datetime.date.today(), but not working