タグ

thinkingとsoftware-testに関するjune29のブックマーク (6)

  • 優れたテストの重要性 - IT戦記

    JavaScript の進化 ここ 1, 2 年で JavaScript という言語は何倍も高速化されました。 それは何故でしょうか。 その要因を少し考えてみました。 SunSpider の出現 その一番の要因は、 JavaScript のパフォーマンステスト SunSpider ではないでしょうか。 SunSpider によって、シンプルで分かり易い JavaScript エンジンの指標が誰にでも分かる数字として提供されたのです。 これと似たような事例として、 acid2 test 、 acid3 test があります。 このテストも、レンダリングエンジンの正しさを分かり易い数字や絵として提供しました。 その結果、今日のウェブブラウザのレンダリングエンジンは目覚ましい進化を遂げたのです。 まとめ 進化の裏にはテストあり。 テストはソフトウェアの最良のマーケティング手段かも。 面白くて分か

    優れたテストの重要性 - IT戦記
    june29
    june29 2018/11/04
    「良さ」を定義してから「良いもの」を作る,ってのもひとつの方法
  • クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか? - @kyanny's blog

    TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは当に難しいのか?」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を

    クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか? - @kyanny's blog
  • インフラテストへのTDD的アプローチとか

    2015/0710 19:00〜 Infrastructure as Code Casual 札幌 #0 インフラテストに対する自分の考え方や悩みを共有するためのポエムです。

    インフラテストへのTDD的アプローチとか
  • Testing Casual Talks 2 で発表してきた - HsbtDiary(2015-05-25)

    ■ Testing Casual Talks 2 で発表してきた @ikasam_a さんからあんちぽくん経由で登壇依頼が来たのでちょっと前に構築した ngx_mruby のテスト基盤の話をしてきました。 Testing Casual ということで今回の話はテストのことしか話せなく、そもそもの問題意識であるとか、ngx_mruby の魅力の部分を端折ってしまったので補足します。 nginx.conf のテストをするために ngx_mruby を入れたわけではなく、そもそも rails や sinatra のようなアプリケーション・サーバーでやっていることを nginx のレイヤでやることが最初の目的 ngx_mruby でやるロジックは、非常にテスト向き(コンテキストの再現がやりやすい)ということに気がついたので、テストをする方法を考えて実現した 実現してみたら、だいぶいける感がしてきたの

    Testing Casual Talks 2 で発表してきた - HsbtDiary(2015-05-25)
    june29
    june29 2015/05/26
    ロックの話だ!よさ〜
  • テストでは何をテストすべきか — recompile.net

    2012年08月21日 ソフトウェア開発でのテストとは何かを単純に言うと、成果物が期待通りであるかを検証する作業といえる。こう動作してほしいという期待を入力に、成果物がその通りに動作するかを検証するのがテストである。 となると、成果物とは何で、期待とは何かが問題になるのだけれど、これが一筋縄ではない。というのも、システムは十分に複雑なので、ある部分を複数の部分に分けることもできるし、その部分をより大きな部分のパーツにすぎないとみなすこともできるからだ。 だからといって、一番大きな単位でもって期待通りにあるかどうかを検証すれば済む話かというとそういうわけでもない。というのも、大きな単位には大きな単位なりの期待が、小さな単位には小さな単位なりの期待というものが存在するからだ。 システム開発は、ひとつのものさしではかることができない。システムをつかって業務を遂行できるかという検証と、その部品であ

    テストでは何をテストすべきか — recompile.net
  • デバッグしやすいHTMLのテストの書き方 - 2012-01-18 - ククログ

    注意: 長いです。 一言まとめ: withinとtest-unit-capybaraを使ってHTMLのテストを書くと問題を見つけやすくなる。あわせて読みたい: デバッグしやすいassert_equalの書き方 HTMLに対するテストに限らず、開発を進めていく中でテストが失敗する状況になることは日常的にあることです。HTMLの場合は、入力フォームのラベルを変更したり、項目を追加したら既存のテストが失敗するようになるでしょう。そのとき、どのようにテストを書いていれば原因を素早く見つけられるのかを説明します。ポイントは「注目しているノードを明示すること」です。 HTMLテストのライブラリ さて、Rubyで処理結果のHTMLをテストするときにはどんなライブラリを使っていますか?The Ruby ToolboxにあるBrowser testingカテゴリを見てみると、Capybaraが最も使われてい

    デバッグしやすいHTMLのテストの書き方 - 2012-01-18 - ククログ
    june29
    june29 2012/04/13
    「問題があるだろう範囲が広すぎて問題を発見することが困難になる」
  • 1