キーボードを、持ち歩く。 久しぶりに、スマホ用のキーボードを使ってブログを書いている。 いくつかキーが壊れてしまっているので買い替えないといけないのだが、壊れるくらいには使い込んでいたんだなと思った。 当時は、今のようにPCを普段から持ち歩くことが少なかったので、出先でもブログ…
キーボードを、持ち歩く。 久しぶりに、スマホ用のキーボードを使ってブログを書いている。 いくつかキーが壊れてしまっているので買い替えないといけないのだが、壊れるくらいには使い込んでいたんだなと思った。 当時は、今のようにPCを普段から持ち歩くことが少なかったので、出先でもブログ…
2014/03/25 (火) にあったDevLOVE関西「レガシーコードと対峙する方法を考える」の発表資料です。 http://devlove-kansai.doorkeeper.jp/events/9463Read less
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
はじめに:なぜ Google C++ Testing Frameworkを使うのか¶ Google C++ Testing Framework を上手に活用すれば,より良い C++ のテストを書くことができます. Linux,Windows,そして Mac,あなたが C++ のコードを書いているこれらの環境に関係なく Google Test を利用できます. では,優れたテストを書くにはどうすればよいのでしょうか?Google C++ Testing Framework は,どのように役立つのでしょうか?我々は次のように考えています: テストには, 独立性 と 再現性 が必要です.別のテストの結果に依存して成功したり失敗したりするテスト,をデバッグするのは非常に面倒な作業です.Google C++ Testing Framework は,各テストを異なるオブジェクト上で実行することによって
romaji というライブラリを書いた。 - 寿司じゃないブログ という記事を書いたのだが、テスト環境について反応があったのでもうちょい詳しく書く。 RSpec テスティングツールのデファクトスタンダード。 http://rspec.info/ に行くか、The RSpec Book を読もう。 Guard ソースコードが編集されているかを監視して、変更があった場合に自動でテストを走らせてくれる。 guard/guard · GitHub guard と guard-rspec を gem install して、以下のようなファイルを Guardfile という名前でプロジェクトのルートディレクトリに置き、 guard コマンドを走らせると、watch で指定したファイルの変更の監視してくれる。 guard 'rspec', :version => 2, :all_after_pass =
WEB+DB PRESS vol.61の「Rails3テスト最前線」という記事がかなり良かったので、注釈を交えて紹介したいと思います。 何が良かったのか? 自分はRails2系でTest::Unitを実践していました。AutoTestとYAMLによるデータ投入でおおむね満足していましたが、次のポイントが気になっていました。 YAMLによるデータ投入は重複が多いのでコピペでデータを作成していた。 Test::Unitはログイン処理など共通の処理をくくり出すのが難しかった。 Viewのテストの方法が分からなかった。 しかしこの記事で気になる点がスパッと解消されました。私と同じような人はこの雑誌の記事が役に立つと思います。 ちなみに私はMacのSnow Leopard上でRuby1.9.2を使ってこの記事の内容を試しました。1.8.7を使う前提で書かれている箇所もあるので注意してください。(後で
単体テストを“神速”化するQuick JUnitとMockito:ユカイ、ツーカイ、カイハツ環境!(16) Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション(CI)によるテストの自動化や、テスト駆動開発(TDD)の普及などにより、ユニットテスト(単体テスト)のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
1.V字開発プロセスモデルによる分類 1.1.要件定義 VDM 形式手法(Formal Methods)により仕様の自動検証などを行う。 1.2.システム設計 モデル検査 Spin モデル検査により状態遷移図の状態で自動検証を行う。 LTSA モデル検査により状態遷移図の状態で自動検証を行う。 NuSMV モデル検査により状態遷移図の状態で自動検証を行う。 モデル駆動 ZIPC(商用:キャッツ株式会社) 状態遷移図による検証が可能 MDA モデルを実際に動かして動作検証する。Executable Umlなどを使用して仕様を記述。 IAR visualSTATE(商用:IAR SYSTEMS) ステートマシンを設計、検証、実装できるツール。20ステートまでの無料の評価版あり 1.3.詳細設計 Enterprise Architect(商用:SPARX SYSTEMS) テストツールではないが
Introduction to Test Driven Development (TDD) Test-driven development (TDD), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring. One view is that the goal of TDD is specification and not validation . In other words, it’s one way to think through your requirements o
少し前になるけれど、先日WACATE SNSというテストコミュニティつながりのテスト設計のワークショップ勉強会で、テスト設計に関する課題を出題・解説をさせていただいた。開催者の方や参加者の方にはお礼申し上げます。 テーマにはリファクタリングのための単体テスト設計を選ばせて頂いた。課題も解答も即興で作ったテキストデータなので、今回は復習も兼ねて補足したものを以下に転載したいと思う。 (諸事情により非表示化しています)
家庭用ゲーム機の劇的な進化がゲーム開発をより困難にしている? 1983年に任天堂の「ファミリーコンピュータ」が登場し、社会現象を巻き起こしてから約26年。家庭用ゲーム機は飛躍的に進化を遂げ、現在の最新機であるソニーの「プレイステーション 3」(以下、PS3)、マイクロソフトの「Xbox 360」などでは、CGを駆使してまるで実写のようなリアルな映像が楽しめるゲームタイトルが次々と生み出されている。 こうした家庭用ゲーム機の進化に伴い、ゲームソフトの開発を手掛けるメーカーにとっては「より高品質なゲームタイトルを、より短納期に開発する」ことが求められるようになった。そのため、その開発プロジェクトも従来とは比べものにならないくらい規模が大きくなった。これが「開発工数とプログラムコード行数の増大によるバグの大量発生」など、さまざまな問題を引き起こしており、ゲーム業界全体の重大な課題となっている。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く