タグ

TestとJavaに関するtakaesuのブックマーク (6)

  • ユニットテスト改善ガイド | DevelopersIO

    先日、日Javaユーザグループ(JJUG)主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション(以下、CI)の導入は必要不可欠と考えられています。とはいえ、どんな組織(チーム)でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか?。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失

    ユニットテスト改善ガイド | DevelopersIO
    takaesu
    takaesu 2013/11/13
    テストの改善
  • JavaプロジェクトでGroovyを導入すべき5つの理由 - うさぎ組

    前段 TDDBootCamp in Tokyo 1.5にJavaグループの一員として参加させていただきました。 そこでGroovyをやりたいというホットなエンジニアと出会いまして、GroovyでTDDをさせていただきました。 いきなりGroovyでプロダクトを書く事はなかなかないと思っているので、Javaのプロダクトコードに対して、Groovyのテストコードを書く。という方法で演習しました。 そこで、皆様がGroovyへ多少なりとも注目してくださいましたので、このエントリーを書いてみようと思いました。 JavaプロジェクトでGroovyテストコードを導入すべき5つの理由 以下であげる5つのポイントは「Groovyを知らないJavaプログラマーがすぐに始められるGroovyの強力な機能」をとりあげました。 もちろんここにあげた以外にもたくさんのGroovyの強力な機能はありますが、それらの威

    JavaプロジェクトでGroovyを導入すべき5つの理由 - うさぎ組
  • はじめてのDependency Injection - _development,

    Android Advent Calendar 2012 に参加しています。 エントリはDependency InjectionによるAndroidアプリケーションの実装とテストの一方法について述べています。 文中に出てくるコードは全てgithubから取得できます。 Dependency Injectionとは簡単にいうと、あるオブジェクトが依存しているオブジェクト(以下、Dependency)を別の誰かが注入(以下、Injection)してあげることでオブジェクトの関係を疎結合にする方法です。 Dependencyを誰かがInjectionしてくれると、なにがいいのか? まず、逆に誰もInjectionしてくれない場合を考えてみます。 Dependency Injection 前 誰もInjectionしてくれない場合は自分でDependencyを設定するしかありません。 たとえば、天

    はじめてのDependency Injection - _development,
  • xUTP Magazine - ぺけま

    xUTP Magazine について 『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。 最新号 0004号 巻頭言 xUTP Topics: 第三回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 TDD Live 番外編(TDD序破Q) 編集後記 バックナンバー 0003号 xUnitester Hotlinks: 第一回 和田卓人さん(下) goos 読書会への誘い 来年(2012年)のTDDBC予報 0002号 xUnitester Hotlinks: 第一回 和田卓人さん(上) xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」 mockitoでサ

  • [TDD] スタート地点で止まらない為のTDD TIPS - 2012-01-10 - ぽにくすじゃないだいありー

    10:50 | 皆さんは設計という名の「下手の考え休むに似たり」をして時間を無駄にしてしまったり、作りたいモノがあるんだけどどうやったらそれを作れるのかのイメージを組み立てられずに結局は何も作らずに無為に時間が過ぎたような事ありませんか?僕はあります。最近になってTDDはそんな人がスタートを切るための有効な技法なのではないかと気づきました。ここでは最近そういった状況を打破する為に試した事をTIPSとしてまとめてみます。TDDがどういう物かは知っているというのが前提です。TDDを知らない人はTDD BootCampとか参加してみるといいかもしれません。もしかしたら今回のTIPSはTDD的には邪道かもしれません。TDDについて詳しい人の突っ込みお待ちしております。 今回の記事に直結するTDD原則のおさらい1. TDDはクォリティテストの為の技法じゃないです。製品のクォリティを維持する為のテスト

  • SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して

    ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは? - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。このは、7月に行わ

    SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
  • 1