いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル
@yohei さんの品質についての考え
YAMAMOTO Yohei @yohei まず、テストって言葉は広いからうまくどの「テスト」について話しているのかを切り分けないと混乱しますね。特に開発者テストといわゆる品質保証的なテストとが混乱すると悲劇。そういう意味でTDDって言葉は功罪あったと思う 2011-12-21 06:12:44 YAMAMOTO Yohei @yohei 僕がブックマークでコメントしたプロセスを強化する方向が楽だからというのは、何か問題が起きたときの対策として、その原因を突き止めてそれが再発しないことをプロセスに落としこむの方が楽だからという意味です 2011-12-21 06:15:31 YAMAMOTO Yohei @yohei もちろんプロセスの強化が必要な場合もある。でもそれってものすごく基本的なプロセスが間違っていたとか、ひどいミスが多発した場合に必要なことであって、プロセスの強化だけで何か解決
[ThinkIT] 第5回：複数人での開発におけるテストの勘所 (1/3)
これまで解説してきたように、ウノウでは各々の開発者の開発環境で慎重に組み上げられたソースコードをSubversionで管理された統一の開発環境にそれぞれコミットし、リリースに向けて足並みを揃えながらシステムテストを実施します。 ウノウではテスト専門の担当者が在籍しており、開発者とは違った視点から成果物のチェックを行う体制を整えています。今回はその実践事例を紹介しながら、複数人での開発におけるテストの勘所について解説していきます。 テスト工程はプロダクトの品質を確保するために欠かせないフローの1つです。組み上げられたばかりのソースコードは、まだ完成度が客観的に保証されていない状態であり、開発者のスキルに対する信頼によってのみ「完成した」と推測されるものでしかありません。極端にいえば、いざ蓋を開けてみたら動かなかったということもあり得るのです。 自社プロダクトの開発がほとんどであれば、問題が発
ウノウラボ Unoh Labs: 「２流のテスター」は要らない！(2)
こんにちは！ やまもと＠テスト番長です。 その1を書いてから間が空いてしまいました。 No More Second Class Testers! という面白いコラムを、引き続きご紹介しましょう。 なぜ１流のテスターでなければいけないか テスターは商品開発における重要な役割を果たします。 テスターは開発中の製品の情報とテストに関する情報を提供します。 テスターには少なくとも3種類の相手（客）がいます。 ・開発者には、分かりにくい箇所、テスタビリティ、そして動作しない箇所について報告します。 ・ユーザーには、サポート係を通して製品の情報を提供します。 ・開発マネージャーには、リリースのリスクについて情報を提供します。 １流のテスターは、コードが書かれている前にシステムのデザインとアーキテクチャを評価することができるくらいクリエイティブです。 コーディングが進む間、テストの準備を整えます
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
