SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行
軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。本体のソースコードは約6万7200行（67.2KSLOC、Kilo Source Lines of Code：空行やコメントを除いた行数）なのに対し、テストコードはなんと4567万8300行（45678.3KSLOC）だと紹介されているのです！ これはテストコードが本体の約679倍もの大きさだということになります。 100％のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang
InfoQ: より良いユニットテストためのガイドライン
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
「レガシーコード改善ガイド」のススメ 第4回：既存のコードに極力手を加えずにテストで保護する
既存のコードをテストで保護する 前回の記事では「スプラウトクラス」（Sprout Class）という手法を紹介しました。これは、レガシーコードに機能を追加する際に、既存のコードにはほとんど手を加えず、新機能を実現するために新しいクラスを作るという手法でした。この手法の基本にあるのは、既存のコードにテストを書くことはあきらめるとしても、せめて新しく書いたコードだけはテストで保護しよう、という考え方です。 こうした手法は時間が少ない状況で新しい機能を追加する際に有効です。しかしこれを使い続ける限り、いつまで経っても既存のコードは改善しません。 そこで、既存のコードをテストで保護する手法が必要になります。『レガシーコード改善ガイド』では、こうした手法が数多く紹介されています。今回の記事では、その中のもっとも基本的な手法の1つを紹介しましょう。 テストが困難な既存コードの例 ここでは、あるスーパー
デバッグという基礎素養 - みねこあ
経験の浅いプログラマーがデバッグにてこずってるのって、 これと似ていて、 むやみやたらにクリックするのだけど、 自分の知ってるパターンに収束させることができない、みたいな。 これについては、経験を積めば、 自分の知ってるパターンが増えてきて、 バグだ、と思ったときには既に自分の知ってるパターンだから直せる、とか、 ちょっと試行錯誤すればパターンに落とし込めるとか、 そうなるんじゃないかな、と。 経験の浅いプログラマーがデバッグできない理由 については、コンパイラの吐くエラーが実は直接的が原因を示していない、とか、そういうレベルの話では実感だな、って思います。 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ？、どこかでみたぞ、これ」となる。そういう「良くあるパターン」
GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
JUnitとEclipseを使って学ぶ、“テスト”の常識
JUnitとEclipseを使って学ぶ、“テスト”の常識：Webアプリの常識をJSPとStrutsで身につける（10）（1/4 ページ） 本連載は、JSP／サーブレット＋StrutsのWebアプリケーション開発を通じて、Java言語以外（PHPやASP.NET、Ruby on Railsなど）の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です いまさら聞けない、“テスト”の考え方やポイント 今回は、「テストの常識」と題し、Webアプリのテスト方法を説明したうえで、実際にJUnitを使用してWebアプリのテストを行ってみましょう。 そもそも、テストとは何のために行うのでしょうか？ ただ何となくテスト項目を作成して実施するのでは、作成したWebアプリの品質が低かったり、開発コストが高くなったりと後々、後悔することになります。まず「テストをなぜ行うのか」「何を
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「レガシーコード改善ガイド」のススメ 第3回：既存のコードに極力手を加えずに機能を追加する