DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 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 disco
C++用のテストツールは，5,6種類あるのですが，今回はCxxTestについて説明します。 CxxTestは，約10個のcppファイルと，約20個のhファイル，2個のPythonスクリプトで構成された，シンプルなテスト用フレームワークです。 特徴としては，ヘッダーファイルにテストケースを書き，そこからcxxtestgen.plというPythonスクリプトを使ってテスト用cppファイルを生成し，このcppファイルをビルドして実行することでテストを行います。 ■インストール方法 CxxTestの公式サイトでは，CxxTestのソースコードとrpmパッケージしか配布されていません。 Debian/Ubuntu系LinuxでCxxTestを使うには，ソースコードを手動でインストールするか，rpmをdebに変換してインストールします。 今回は，手間を省くために後者の方法を使います。 まずは，ali
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
ブラウザの画面テストを自動化するツール、Selenium。 大変便利なツールなのですが、Selenium RC、Selenium IDE、WebDriverなど色々な名前が出てきて、「なぜこんなややこしいことになっているんだろうか」と思ったことはありませんか? その理由を知るには、Seleniumの歴史について知る必要があります。 今回は、Seleniumの誕生から2013年5月現在に至るまでの歴史を振り返りながら、それぞれのツールがどのような位置付けのものなのか、見ていくことにしましょう。 ※ 歴史はいいからとりあえずSeleniumを使ってみたい、という方は、Selenium公式サイトからSelenium IDEをダウンロードすれば使えます。 Selenium Core Seleniumの原型は、米ThoughtWorks社で働いていたJason Huggins氏によって2004年に作
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。 liftを開発した人へのインタビューなんだけど、ちょっとひ
なんちゃって個人情報は「Generator of the Year」にて【便利賞】を受賞いたしました！！ 投票して下さったみなさま、本当にありがとうございました。 今後もどんどん使ってやって下さい。 プログラム等に使えるかもしれない個人情報のテスト用データを作成できます。特に説明が必要なものでもないので、とりあえずやってみていただければわかると思います。 念の為書いておきますが、生成した偽個人情報により発生したいかなる損害も当方は一切関知しません。たまたま名前が実在の人物と同姓同名になってしまうかもしれませんし、特に電話番号や携帯については実際に使われている番号と重なることがありますから、扱いには十分注意して下さい。 何かご要望とかありましたらお気軽にブログまでコメント下さい。 HTML シンプルなHTMLのテーブルで出力します。 XML ルートを<records>、各レコードを<reco
Webアプリケーションが実運用に耐えうるかどうかテストするためには， 大量のテストデータが必要になる。 規模にもよるが，場合によっては１テーブルあたり，数十万〜数百万レコードを要求されるだろう。 システムの負荷テストを実施する際には， （１）： 「システムの内部に保有する負荷」つまり「DBの重さ」をまず作り出し， SQL実行性能を現実の運用状態に合わせてチューニングする。 （２）： その後で，「システムの外部で発生する負荷」つまり同時アクセスをかける。これがサーバーの重さとなる。 そして各機能ページのパフォーマンスを測定する。 後者は，jmeterなどの便利なツールが存在する。 が，前者の「データ生成」に関しては，方法がそれほど確立していないように思える。 下記は，そういった大量のデータをうまく作るためのメモ。 (１) Excelでデータを作るべし (２) できれば Excelは 2007
この記事は賞味期限切れです。（更新から1年が経過しています） JavaScriptユニットテスト一年生の私が、Nettuts+ のチュートリアルで知ったテストツール 「testem」のお陰で大変捗ったので是非お勧めしたく、ここで紹介してみます。 testem ってなに testem via GitHub : airportyh/testem Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests. 要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応して
状況はかなり改善した 非同期、setTimeout, Ajax系はSinonJSで簡単に Swarm系のツールでDOMのテストも容易に 環境構築も非常に楽になった PhantomJSはバイナリもあるし、ビルドも簡単 Swarm系のツールならブラウザでURLへアクセスすればすぐテスト開始
「コードレビューの視点 003」では、「マルチスレッドプログラミングに注意する」と題して、次のことが必要だと述べました。 マルチスレッドプログラミングに関する基礎知識をすべてのソフトウェアエンジニアがきちんと習得していること 書かれたコードは、マルチスレッドプログラミングに関する豊富な知識と経験を持つ人がきちんとレビューをする 書かれたコードは、自動テストが実行できるようになっていて、様々なプラットフォーム（単一コアから複数コア、あるいは、マルチプロセッサー）で長時間ランニングテストを行う。さらに、同時にシステムに別の負荷（CPU、HDなどへの負荷）をかけたランニングテストも行う そして、テストが止まっている場合には最優先デバッグすることも重要だと述べました。しかし、重要ことを書き忘れていました。デバッグは、テストが止まったままの状態でデバッガーをプロセスにアッタッチして行うということです
以下のエントリは、自分内ブレインストーミングの結果を書き起こしただけのモノなので、数年後どころか数ヶ月後でも意見が変わっているかもしれない。と言う前提で。 三つ、考えられる。 「未来の自分」が楽になる 自動テストコードは、その状態でのそのソフトウェアの挙動、仕様のスナップショットを撮る、と言う側面があり、それはドキュメントを各行為にも通じるが、「今書いている」自分以外の誰かがそのソフトウェアを変更したり、メンテナンスしたり、理解する際に役に立つ。人間はモノを忘れていく以上、「今書いている」自分以外、とは、当然未来の自分も含まれる。 実際、経験的にも、変更したらまずは rake spec を走らせて、エンバグしていないことを確認できるのは気持ちがすごく楽……。そのサービスを変えつづけていくつもりなら、是非テストを書こう。必ずいいことがある。 で、以下二つは、コードをgithubなどのソーシャ
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
2004年6月、記者はこの欄で、ソフトウエアのテストに関するある記事を執筆した。タイトルは「なぜ『テスト』は軽視されるのか？」である。この記事では、IT業界で“テスト軽視”の風潮が広がっている現実を語り、その改善を訴えた。「その通りだ」「今その対策を打っている」――。読者の皆様から、さまざまなご意見をいただいたことを覚えている。 それから6年半近くが経った今、この状況はどうなったのか。記者は日経SYSTEMS 2010年12月号で「バグをなくそう 悪条件に負けないテストの秘訣」と題して、テストに関する特集を担当した。ここで多くの開発現場を取材した結果、今ではテスト軽視の風潮はほとんど見られなくなったと感じている。現場にはテストの計画書がしっかりあって、品質目標も明確になってきた。テストの技法や管理に関する教育も、かなり進んでいるようだ。 どんどん難しくなる「テスト」 ところが、テスト軽視の
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
JNDIをJ2EEサーバ無しでかつテスト用ライブラリも無しでテストする場合、InitialContextに自前でbindしてlookupします。 @BeforeClassだったり、setUpメソッドで以下のようにbindすると良いでしょう。 この例では、T2でCDIの単体テストを行う時に利用しています。 System.out.println("CdiTestCase#setUp"); System.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.apache.naming.java.javaURLContextFactory"); System.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.weld.resources.ManagerObjectFactory"); ic = new I
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
