TDD Boot Camp 北陸 事前アンケート中間発表
自由回答欄がいい感じにいい感じなので、だーっとコピペします。
引き続き、このアンケートにご協力頂けるかたを募集しています。TDDBC北陸に参加してみたい方はもちろん、興味はあるけど参加はできなさそうな方なども、ぜひご協力ください。
アンケートは => http://bit.ly/6ToL7W
イベントの参加募集は、1/12くらいから始める予定です。参加表明っぽい設問がありますが、改めて募集しますので、今しばらくお待ちください。顔。
あなたが自動テストを使って開発しているなかで、課題となっていることがあれば、教えてください。
TDDを既に実践している
- テストの資産価値。今後役に立たない/足枷となるテストをいかに捨てるか。
- スローテスト。
- テストしにくいもののテスト。JavaScript や GUI など。
- 「テスト」という用語がもたらす誤解。お客様には品質保証として捉えられがち。都度説明してもいつの間にか元に戻っていて、「テストは終わっているはずですよね」という話になってしまう。開発者側も、開発の足がかりとしてのテストと品質保証のテストを混同して扱いがち (developer test で全パターンを網羅しようとするなど)。
- マルチスレッド関連のテスト方法が分からない。
- テストファーストでない部分がどうしても出てきてしまう。
- どの粒度まで掘り下げてテストを行えばいいのか迷う。
- Mock化にどこまでコストを払うか。
- TDDを実践していないコードの改修時のTDDの実装方法。
- テストを考慮した設計をしていないため先に改修しないとTDD自体が出来ないような場合。
- TDDを始めたばかりでなかなか速度が上がらない
- 経験が無い状態なので苦労の連続
- TDDをいかにチームに広げるかということが課題になっています。
- テストケース（JUnit及び受け入れテスト）のリファクタリング。
- 受け入れテストの記述方法及び管理方法（DRY原則の守り方）
TDDではないが、業務やOSS活動などの開発で使用している
- 自動化するために掛ける時間や労力と、実際のコードを書くときに掛ける時間や労力との配分。
- ほかのメンバーがなかなか自動テストを書いてくれない。また、自動テストの実施もしてくれないので自動テストが壊れる。結局、Hudsonを導入することでビルド状態を可視化することでテストが壊れていないかの確認はしてくれるようになりました。
- GUI周りの自動テストコードの実装工数とその効果について。
- ソースコードに対して自動テスト率がなかなか向上しない。ついつい手動テストで作業してしまう。
- 自動テスト項目の粒度をどれくらいにするかが人によって異なる。自動テストで行っているテスト内容が共有できていない(テスト作成者以外にはわかりづらい)。なので、作成者以外には自動テストの内容の妥当性が判断できない。
- 自動テストの実行に時間がかかりすぎる。
- 携帯アプリ開発は、自動テスト化しづらい。信頼性の低いエミュレータ頼み。
- Windows MFC/C++における開発などはツールがあるので楽だが、組み込みでgccクロスコンパイル(C++/C)環境などの場合、ビルドとテストランする時間が非常にかかってしまう。このあたりスピードアップする技などあればうれしい。
- 開発が進むにつれてリファクタリングの工数が、大きくなってしまう。
- テストを先に書くメリットが理解できていない。
- テストを書いたことのないメンバーへの教育コスト。
- ドライバーとナビゲーターの距離感が人によってさまざまなため、うまくいくペアとうまくいかないペアがある。
- 技術的な課題１：ソケット通信まわりのテストで、接続がタイムアウトした場合や、通信が強制的に切断された場合などのテストをどうやったらいいのか分からないです。モックをつくるとしても、わりとソケットの振る舞いに忠実に作らなければいけなさそうなところが課題になりそうです。
- 仕様変更にともない、メンテナンスされないテストコードが存在する
あなたが開発の中で、自動テストを導入できない理由があれば、教えてください。
試したことはあるが、開発では特に使っていない
- いまは業務の中で開発を行っていないのでテストを実践するに至っていません。
- 有用性が自分も含め身の回りに認知されていない
- どこからどのように取り組んでいけばよいのかよくわからない
- 自動テストを行ってもそれがエビデンスとはならない
- 知識不足。
- 経験不足。
- もっとも顕著な理由は開発当初から自動テスト前提でシステムも環境も設計されていないこと。現在使用しているシステムであればいたるところでマルチスレッドが使用されており、また、View側もアプレット、フレームワークなしのサーブレットで組まれているため自動テストが大変行いにくいため。
- 先日、JUnitの社内勉強会があって簡単に使い方を習ったが、実際に使ってみたら、また分からなくなってそのまま放置になってました。ちょっと再勉強しときます。
- 具体的な手法や導入方法が分からない。今までそのような文化の無いチームに、どのように導入すべきかが分からない。
- 落ち着いて、みっちりトレーニングしないとなかなか身につかないと思っています。お題を作って、自宅でじっくりしないと・・・トレーナーや一緒にやる仲間がいれば理想的。
- 会社では、「コードは資産である」という概念がまるでない。そういう風土？のなかで、プロダクトコード以外のコードを書くことの意義を伝えるのには、時間がかかりそうだなぁと思っている。年間努力目標にさりげなく、「テストコードを書く」を書いてみたが…どうなることでしょう。
- テストの粒度をどう設定したらいいかでつまづいてしまう。結果として、面倒くさくなって自動テストを実施しなくなってしまう。
- 仕事での開発では、テスト工数が軽視されがちであるという問題もあると思う。実際に工数が少ない場合は、テスト工数から削られるケースを多く経験している。
- 新規案件だとしてもあまりにも短納期である開発が多いこと。
- TDDに興味のある人間がいなく、技術習得のオーバーヘッドを理由に避けられてしまうこと。
- 全体のリテラシーが低い
TDDではないが、業務やOSS活動などの開発で使用している
- がんばることが仕事だという風潮
- 提出を要求されるテスト仕様書との間をどう取り持つか。書類がネックになって導入しにくいケースがある。
- レガシーコードが多い。既存コードに関するドキュメント(情報共有)が不足している。
- 周囲の自動テストに対する信頼性が欠けている。なので、個人活動になってしまう。
- 全員がビルド、自動テストを通さない限り、リポジトリにコミットできない、という運用を設けた場合、全員にその環境をセットアップしなくてはならないのがコストが大きい。
- また、客先常駐で仕事する場合、そういった文化がない仕事先ではなかなか導入しづらい。簡単に環境をON/OFFしたり、テストコードをHideしたりできないか？テストコードも含めて納品した場合、本番に使わないコードを極力排除するようにといわれてしまう、など。
- 客先環境で開発している場合に、リソースが確保できないなど
- 特にありません。自動テストするなって言われてもやります。
- テストコードを書こうという気概がないため、print相当のログ出力で済ませてしまう人間が多いこと。強制力がないと導入不可能。
