テスタブルコードの書き方 - 基本戦略編 - ブログなんだよもん
今のチームにテストコードの導入を本格的にしようと思ってるので、思考の整理がてらメモ。内容は初学者向け。 テストの必要性をとくのは比較的簡単である程度できた。既存のレガシーコードはとりあえず忘れることに（特定メンバーでプロジェクト的に実施）。 というわけで、新規コードはみんなテスト書いてね！ と、これだけでテストを書いてくれるでしょうか？ 答えは否でした。 原因として自分の書きたいコードをどうテストすれば良いかわからないというものです。 新規コードなのでテストをしやすいように設計をすれば良いだけです。TDDはそれを支援してくれる有効な手法です。 しかし、テストが無い環境に慣れた人間はそもそもテスタブルコードを見慣れてません。なので、自分の書きたい実装をどう書けばテストが書きやすくなるかが分からないのでテストコードが非常に複雑になったり、立ち止まったりしてしまいます。 なので、テスタブルコード
GoogleのCIとテスト自動化の取り組み [GTAC 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=nyOHJ4GR4iU [Slide] http://goo.gl/76Ggf Google Test Automation Conference 2013のキーノートスピーチで、GoogleのAri Shamashが同社のCIツール & 自動化されたテストプロセスを紹介しています。 [最初の前置きが13分。GoogleのCIの紹介の内容ではないので割愛。お話としては面白いのでVideo見てみてください。] エンジニア1,5000+人が5,000プロジェクトにアサインされている １億行のコード。50%が毎月更新。 1日当たり5,500+件がサブミッションされ、１億件以上のテストケースが実行されている。 Googleのクラウドテストシステムは多機能。ビルド作成、特定のターゲットをテストでき、テストカバレッジ計算、依
「自動受け入れテスト」を考えてみる - 日々常々
きっかけは XP祭り関西2013 の @StoneGuitar777 さんのLTからです。 LTスライド: XP祭り2013-LT-Codeer @ITの記事: 特集：受け入れ検査の自動化手法の考察：Windowsアプリの受け入れテストを自動化しよう (1/5) - ＠IT 「継続的デリバリー」に貼付けた付箋を抜き出してみる 【大阪】継続的デリバリー読書会(8回目) - connpassの範囲でもありました。 受け入れ＝ビジネス的な受け入れ基準＝ユーザーの価値 ユニットテストとの色分け ユニットテスト: 作り手の意図 受け入れテスト: 顧客の意図 うまくやらないとコストが高すぎる 適切に作成して保守すれば自動のほうがはるかに安上がりになる ユニットテストやコンポーネントテストではどれほど包括的にやっても検出出来ない問題がある 手動テストはアプリケーションの複雑さに関わらずきわめて高くつく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
