Dockerと継続的インテグレーション2014/02/12 Docker Meetup in Tokyo #1 での発表内容です。 デモコード: https://github.com/ydnjp/docker-continuous-integration-workflow
テストのめどい話
最初にめどい言い訳をせねばならぬ俺は江島氏ともきょん氏とも面識はないですが、お二人ともが俺のことを知ってることを俺も知ってる程度には狭い業界であり。どちらかに肩入れしたいわけではないです。喧嘩したいわけでもないです。普段あまりここでは言及しないですが俺は今の仕事としてはテストを書いたりテストを実施したりする係をしてノリクチをしのいでおり、いわばテストは本業ですので、テストに言及することは今現在の同僚に対して意図しない受け取られ方をする可能性があるので困るので、それもあって普段はここではあまりテストの話はしないわけだが、だからと言って沈黙を破ってテストの話をするのが同僚に対して含みがあるというわけでもないです。とはいえ俺は大学等で真面目にソフトウエア工学の講義を受講したことがなく、経験と勘と昔取った杵柄だけで食ってるので、そういう意味では若干の後ろめたい気持ちもある。で、テストって何なん俺が
テストを書く文化を育てる戦略と戦術
at DevLOVE現場甲子園2013 2013/11/09 (土) http://http://devlove.doorkeeper.jp/events/5464
最近行ったTDDの講演や寄稿について - t-wada の日記（旧）
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
Frontrend Vol. 6：Android端末の動作検証の課題を解決「STF」
サイバーエージェントでは現在数多くのAndroid対応のウェブサービスやアプリを提供していますが、問題となるのはそれぞれのAndroid端末を個別に検証しなければならないこと。 この課題を解決するべく立ち上がった、STF（仮）という開発中のプロジェクトの概念を紹介し、一部の機能を説明します。
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
JSのCIで椅子を投げられないため方法
状況はかなり改善した 非同期、setTimeout, Ajax系はSinonJSで簡単に Swarm系のツールでDOMのテストも容易に 環境構築も非常に楽になった PhantomJSはバイナリもあるし、ビルドも簡単 Swarm系のツールならブラウザでURLへアクセスすればすぐテスト開始
JUnitの知識を棚卸し #JJUG - 日々常々
Java Advent Calendar 2011の16日目です。 前：JSFUnitでテストしよう！ | Kokuzawaの日記 次：JavaEE使ってウェブアプリケーションつくろうよ - 水まんじゅう 書いてること JUnit の話です。使い始めからちょっとだけ踏み込んだ辺りですかね。ちょっとだけなので普通に使ってる方には不要な内容かと思います。私の今持ってる知識を書き殴ってみた感じになりましたが、微妙な理解と残念な文章力の相乗効果でグダグダになってます。お察しください。 内容は Assertion->カスタムAssertion、Matcher->カスタムMatcher、Rule->カスタムRule です。 Assertion JUnitは assert があってこそです。まず org.junit.Assert にある馴染み深い assert を並べてみます。 assertEquals
テストコードのリファクタリング - 千里霧中
ユニットテストの再利用や継続的利用を行おうとすると、テストコードにも保守性等に優れた良い設計が求められるようになります。そこで出番が増えてくるのがテストコードのリファクタリングです。 ただ現状、テストコードのリファクタリングはいくつか課題を抱えています。今回はその課題の１つである「リファクタリング前後でテストコードの振る舞いが変わっていないかチェックするテスト」（以下リファクタリングの回帰テスト）の実現方法についてまとめます。 テストの回帰テスト まずリファクタリングの回帰テストを真っ当に考えていきます。テストコードをテスト対象としてみると、一般的に以下の特徴が見えてきます。 SetupメソッドやMockオブジェクト等を通して、テスティングフレームワークから間接入力を受けます。 Assertionメソッド等を通して、テスティングフレームワークに対して間接出力を行っています。またMockオブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
噂のRuby&Githubなプロジェクトにスキな継続的インテグレーションサービス「Travis CI」を試してみたらすごくよかった