「継続的インテグレーション」について - cactusman日誌
id:Ewigkeitのブログで、CIについてはここのブログ読んでね、と言及されたんですが、対象記事はCIについてあまり書かれておらず、しかも、古い記事を調べてみてもいい内容がなかったので、ここで改めて「継続的インテグレーション」について説明します。 「継続的インテグレーション（以降、CI*1）」とはXPのベストプラクティスの一つです。 原典として、マーチン・ファウラーの論文があります。 ここでは頻繁にインテグレーション作業を行うと、少し難しく表現されていますが、ものすごく簡単に言いますと、デイリービルドやナイトリービルドのように1日に1回ビルドするのではなく、1日に何回もビルド*2を行う、ということです。 また、プロジェクトの後期に行われるモジュールの結合やシステムテストといったことも1日に何回も行います。 具体的な例として、 チェックアウト コンパイル Unitテスト パッケージング
WritingTestableCode - テストできるコードの書きかた
WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この
サービスインに間に合わなかった原因は何だったのか？
プロセスを改善するということ 開発プロジェクトの現場では、大なり小なり必ず問題が存在する。それらの問題は最終的に低品質、予算超過、納期遅延などプロジェクトの失敗につながることもある。この状況を打開しようとさまざまな手を打っている企業は多いが、その打ち手は必ずしも大きな成果を挙げているとはいえない。 よくある要因の1つに、問題が顕在化した際に安易に個人や組織・ツールを原因と特定し、対策を講じようとすることが挙げられる。個人を原因として対策を施した場合、問題は解決したとしても組織には何も蓄積されない。そればかりか、人格否定など別の問題を発生させることもある。また、ツールおよび組織についていえば、そもそもなすべきことを効率的に実行するために組織は編成され、ツールは選定されるべきだ。なすべきことをきちんと分析せずに、組織やツールに対症療法を施しても、成果が出ない場合が多い。 そこで、なすべきこと、
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
第5回 継続的テスト | gihyo.jp
継続的なテストの重要性について 松野です。こんにちは。 今回は継続的なテストという話題についてお話したいと思います。本稿では、少人数のチームによるWebサイト開発というケースにフォーカスして論じていきます。 本稿で取り上げる継続的テストとは、端的にいえば「自動でテストを定時実行させる」ということです。 make testするのをうっかり忘れたりしていませんか？ テストを動かすのを面倒がってテスト動かさずにコミットしていませんか？ そして、そのままデプロイしたりしていませんか？ 割れ窓理論というのがあります。これは「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなくすべて壊される」（引用：Wikipedia）という理論です。 これは、テストスィーツにも言えることです。1つのテストがこけていると、make testする気力が失せます。あるいはテ
[Think IT] 第1回：Javaの単体テストツールDBUnitって何？ (1/3)
DBunitでテストの自動化 第1回：Javaの単体テストツールDBUnitって何？ 著者：プロトシステム 広谷 嘉巳 公開日：2008/03/10（月） DBUnitって何？ 読者の皆さんはデータベースにアクセスするプログラムのテストはどのように行っていますか？ Javaの単体テストの場合、JUnitを利用している方が多いのではないでしょうか。では、DBUnitはご存知でしょうか。DBUnitとは、プログラムの単体テストツール、それもデータベースにアクセスするプログラムの単体テストツールです。 本連載では、このDBUnitを利用してテストを進めていく方法を解説していきます。分かりやすいよう実際にテストを行うテスト担当者や開発者の目線で書き進めていき、ポイントとなる点も解説していきます。 さて、第1回では「そもそもDBUntとはなんぞや」を明らかにしていきましょう。 近年のシステムの開発に
TestCaseその２ - Doge log
Eclipseからも起動したい。 既存のTestRunnerを使えないと辛い。(ant、maven） というニーズに妄想で対応。 以下危険コード。 RhinoTestCase package test; import java.io.File; import java.io.InputStream; import java.io.InputStreamReader; import java.io.Reader; import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; import org.mozilla.javascript.Context; import org.mozilla.javascript.Function; import org.mozill
JsUnit を使った JavaScript のユニットテスト - WebOS Goodies
アプリケーションを開発する上で、避けて通れないもの、それがテストです。とくにブラウザごとの非互換性が大きい Web アプリケーションでは、念入りなテストが必要です。でも、テストはあまり創造的な作業ではないし、やったからといってなにか機能が増えるわけでもない。できるだけ手間をかけずに済ませたいところですね。 そんなわけで、本日は JavaScript 用のテストフレームワークである JsUnit を利用したユニットテストの方法をご紹介しようと思います。 Ruby のユニットテストの記事でも書きましたが、ユニットテストによるテスト・ファースト開発は開発効率の面でも良い影響があります。まだ導入していない方は、ぜひこの機会に使ってみてください。 JsUnit について 今回利用する JsUnit は Java 用の JUnit を参考にして作られた JavaScript 用のユニットテストフレーム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
