狠狠撸

狠狠撸Share a Scribd company logo

【&辩耻辞迟;8补1&辩耻辞迟;20160729资料】

?
?
8a1
8a1

2016年7月29日（金）に开催された&辩耻辞迟;8补1&辩耻辞迟;「テスト駆动开発（罢顿顿）」でいただいたイマキクへの回答です。

1 of 2
Download to read offline
コメント GOOD BAD 回答 TDDはトレーニングには良いと思うのですが、慣れ た人にとっては冗長的だと感じてしまいます。 個 人的にはコードと自動テストが揃っていれば良い のでは、と思うのですが… 6 0 コードと自動テストがそろっているなら問題はないです。また、そのよう な考え方の人もいて、例えば有名なまつもとゆきひろさんはTDDをやって ないそうです。ただ、TDDは効率的にコードと自動テストを書くための方 法ろんなのですから、うまく使えば作業が楽になりますよ。冗長に感じる のは、たぶんコツがつかめてないからです。本勉強会で説明した「考えて はいけないこと」などに気を付けるとコツがつかめるかもしれません。 自動テストがない、すでにそれなりの大きさに なってしまっているプロジェクトで、十分な量の 自動テストを用意するためのコツなどあります か？ 6 0 頑張るしかありません。モチベーションを下げることなく面倒な作業を行 う一般的な方法論（自分へのご褒美とか）を参考にして頑張っていきま しょう。特に自動テストが全くない場合はテスタビリティを全く考慮して いない設計になっている可能性が高く、かなり難易度が高いです。その場 合の参考書籍として「レガシーコード改善ガイド」があります。 ふえるん？ 容量が増えるん？ 5 0 ユーザーが使うときにファイルはそのまま見えて、ダブルクリックして開 くなどの操作も普通にできるにもかかわらず、なぜかファイルサイズが 1kB以下になり空き容量が増えるという魔法のようなシステムです（魔法 のタネはクラウド）。詳しくは当社営業にご相談ください。 最初はテストコードをきちんと書いてても、ある きっかけでうまく回らなくなり、途中挫折し、そ のままテストを書かなくなった経験があるのです が、途中挫折した場合のアドバイスがあればお願 いします 4 0 いろいろなパターンがあると思いますが、個人的経験としてはリファクタ リングが足りていないことが多いような気がします。実コード、テスト コードともに、すべてのコードがパッと見てすぐ何やっているのかわかる というレベルを目指してリファクタリングを進めてみましょう。 アジャイル、顧客の教育って観点だとプロジェク トの難易度は場合によっては上がりそう。 アジャ イルの導入で、スコープ可変ということを理解せ ずに、仕様変更が簡単になる、って変に理解する クライアント多そうだし。 3 0 TDDに関しては、顧客どころか元受の理解もあまり受けていない状況で も、割と始められます。顧客の教育は社会全体で行っていく必要があるた め、一朝一夕ではできないようですが、すでに普及率が数十%という調査 もありましたので、キャズムは越えたかもしれません。可変スコープは導 入できないけれど仕様変更が簡単になるような導入の仕方は可能です。も ちろん可変スコープとセットで導入した方がより有効ですが。 ふえるん、はたしか、Googledriveなどのクラウド をPCマウントしている場合にクラウド上とPC側に 同じ容量を必要になるが、ふえるんを導入する と、PC側にはショートカットとしておかれるため に、実質的に容量がふえるサービスだった様な… 間違ってたらすみません。 2 0 そういう説明をされていますね。ショートカットといっても普通のショー トカットと仕組みは違いますが、使い勝手は同じです。 蓄積していくテストと使い捨てるテストの違いが よくわかりません。 2 0 個人的な意見になりますが、蓄積していったほうがいいと思います。蓄積 するメリットよりテストの管理コストの方が大きくなるなら捨てるべきで すが、できればその前に管理コストを下げるようリファクタリングして対 応しましょう。 資料はコンパスにアップされてます http://www.slideshare.net/potimarimo/ss- 64497139 2 0 されています。 iOSのViewController、IBActionに書いてあるコー ドはテストコードを書きにくいように思えるんで すが、テストコードを入れるために、わざわざ publicの別メソッドを書いたりする必要があるの でしょうか？ 2 0 iOSのことは詳しくないですが、一般論としてテストを可能にするために publicを増やすことはよくあります。また自動テストをそんなに意識して ないフレームワークを使う場合は、テスト対象となるロジックのみを管理 するクラス（レイヤー）を用意し、フレームワークの仕組みはそれを簡単 にラッピングするのみという設計もよく行われます。 TDDを導入することで設計ミスを減らすことはでき ますか？できるとすればコツを知りたいです。 1 0 設計ミスを減らすというより、設計ミスをしても簡単に引き返すことがで きる、という方針ですね。腰が引けずに大胆な設計を試してみることが可 能となるので、結果的に設計品質はあがります。 明らかに動かない場合もテストをしてみるんです か？ 1 0 してみるというより、無意識に指が動いてテストをしている習慣をつけ る、という感じですね。 サイクルを回す際のcommit粒度ですが、各ステッ プ毎ですか？1commitにまとめたくなりますが、履 歴を残した方が良いでしょうか。 1 0 適切な単位でまとめるべきでしょう。今回の資料の作成では説明向けに細 かくコミットしてありますが。 TDDではインターフェイスの設計がキモだと思うの ですがこうした方が良いという指針はあります か？ 例えば現在時刻、DBアクセス、そもそも生成 に他のインスタンスが必要でそれを作るのが難し い、等 1 0 その辺の設計のうち、あまり凝ったものについては「TDDは死んだ」で否 定されたようなので、今後はほどほどに済ますようにしていくべきでしょ う。たとえばDBアクセスの分離はO/Rマッパーが対応してないとどうにも ならないように思えます。リポジトリパターン使うとどうも可読性が落ち ますし。時間はかかるようになりますが、あきらめてDBごとテストをする ようにすべきでしょう。少なくともDHHは今後その方針で行くようです。 現在時刻ならテスト時に固定値を出すようラッピングして使うのも難しく ないのでやっておくべきと思います。生成にほかのインスタンスが必要な のは自動テスト時代には設計が悪いの一言で済ませて設計しなおすべきで すが、とはいえこれもあまりやると設計が複雑になりすぎますので、あき らめて結合したままのテストとするのもよいでしょう。 足りないロジックは目に見える、という現象につ いてもう少し詳しく教えてください。 1 0 リファクタリングは、設計書として読めるほど可読性が良いコードを、 もっと可読性が高くなるように推敲する作業です。つまり、わかりやすく 整理された設計書を推敲?レビューしているのと同等に、ロジックのミス が目に見えます。
自動化によるテスト工程削減は大いに結構だと思 いますが、自動化する事でドキュメント整備が疎 かになりそうな気がしました。杞憂であれば良い ですが。 1 0 ドキュメントがなくても保守できるような工夫とセットで導入しないと、 TDDは成り立ちません。自動化しつつこれまでの手動の手順もそのまま残 していたら、自動化の意味がないのは当たり前のことです。 TDDの適用は部分的でも問題ないということでしょ うか 0 0 問題はありますが。全体に薄くテスト自動化を行うより、部分的にでも完 全にTDDが導入されていたほうが、はるかにやりやすいということです。 大きめのリファクタリングをするとテストが軒並 みレッドになる場合がありますが、 それらをメン テナンスしようとすると膨大なコストが掛かりま す。 不要なテストを削除する基準などはあります か？ 0 0 個人的な意見になりますが、個々のクラスのリファクタリングの影響を受 けないように、ある程度大き目な機能に対してのテストを書いていくべき だと思います。ただやりすぎるとそれはそれでテストの構造化ができない ためテストコード保守コストが爆発するので、バランスは重要です。 中の人などいない 0 0 そのとおりですね。

More Related Content

【&辩耻辞迟;8补1&辩耻辞迟;20160729资料】

  • 1. コメント GOOD BAD 回答 TDDはトレーニングには良いと思うのですが、慣れ た人にとっては冗長的だと感じてしまいます。 個 人的にはコードと自動テストが揃っていれば良い のでは、と思うのですが… 6 0 コードと自動テストがそろっているなら問題はないです。また、そのよう な考え方の人もいて、例えば有名なまつもとゆきひろさんはTDDをやって ないそうです。ただ、TDDは効率的にコードと自動テストを書くための方 法ろんなのですから、うまく使えば作業が楽になりますよ。冗長に感じる のは、たぶんコツがつかめてないからです。本勉強会で説明した「考えて はいけないこと」などに気を付けるとコツがつかめるかもしれません。 自動テストがない、すでにそれなりの大きさに なってしまっているプロジェクトで、十分な量の 自動テストを用意するためのコツなどあります か？ 6 0 頑張るしかありません。モチベーションを下げることなく面倒な作業を行 う一般的な方法論（自分へのご褒美とか）を参考にして頑張っていきま しょう。特に自動テストが全くない場合はテスタビリティを全く考慮して いない設計になっている可能性が高く、かなり難易度が高いです。その場 合の参考書籍として「レガシーコード改善ガイド」があります。 ふえるん？ 容量が増えるん？ 5 0 ユーザーが使うときにファイルはそのまま見えて、ダブルクリックして開 くなどの操作も普通にできるにもかかわらず、なぜかファイルサイズが 1kB以下になり空き容量が増えるという魔法のようなシステムです（魔法 のタネはクラウド）。詳しくは当社営業にご相談ください。 最初はテストコードをきちんと書いてても、ある きっかけでうまく回らなくなり、途中挫折し、そ のままテストを書かなくなった経験があるのです が、途中挫折した場合のアドバイスがあればお願 いします 4 0 いろいろなパターンがあると思いますが、個人的経験としてはリファクタ リングが足りていないことが多いような気がします。実コード、テスト コードともに、すべてのコードがパッと見てすぐ何やっているのかわかる というレベルを目指してリファクタリングを進めてみましょう。 アジャイル、顧客の教育って観点だとプロジェク トの難易度は場合によっては上がりそう。 アジャ イルの導入で、スコープ可変ということを理解せ ずに、仕様変更が簡単になる、って変に理解する クライアント多そうだし。 3 0 TDDに関しては、顧客どころか元受の理解もあまり受けていない状況で も、割と始められます。顧客の教育は社会全体で行っていく必要があるた め、一朝一夕ではできないようですが、すでに普及率が数十%という調査 もありましたので、キャズムは越えたかもしれません。可変スコープは導 入できないけれど仕様変更が簡単になるような導入の仕方は可能です。も ちろん可変スコープとセットで導入した方がより有効ですが。 ふえるん、はたしか、Googledriveなどのクラウド をPCマウントしている場合にクラウド上とPC側に 同じ容量を必要になるが、ふえるんを導入する と、PC側にはショートカットとしておかれるため に、実質的に容量がふえるサービスだった様な… 間違ってたらすみません。 2 0 そういう説明をされていますね。ショートカットといっても普通のショー トカットと仕組みは違いますが、使い勝手は同じです。 蓄積していくテストと使い捨てるテストの違いが よくわかりません。 2 0 個人的な意見になりますが、蓄積していったほうがいいと思います。蓄積 するメリットよりテストの管理コストの方が大きくなるなら捨てるべきで すが、できればその前に管理コストを下げるようリファクタリングして対 応しましょう。 資料はコンパスにアップされてます http://www.slideshare.net/potimarimo/ss- 64497139 2 0 されています。 iOSのViewController、IBActionに書いてあるコー ドはテストコードを書きにくいように思えるんで すが、テストコードを入れるために、わざわざ publicの別メソッドを書いたりする必要があるの でしょうか？ 2 0 iOSのことは詳しくないですが、一般論としてテストを可能にするために publicを増やすことはよくあります。また自動テストをそんなに意識して ないフレームワークを使う場合は、テスト対象となるロジックのみを管理 するクラス（レイヤー）を用意し、フレームワークの仕組みはそれを簡単 にラッピングするのみという設計もよく行われます。 TDDを導入することで設計ミスを減らすことはでき ますか？できるとすればコツを知りたいです。 1 0 設計ミスを減らすというより、設計ミスをしても簡単に引き返すことがで きる、という方針ですね。腰が引けずに大胆な設計を試してみることが可 能となるので、結果的に設計品質はあがります。 明らかに動かない場合もテストをしてみるんです か？ 1 0 してみるというより、無意識に指が動いてテストをしている習慣をつけ る、という感じですね。 サイクルを回す際のcommit粒度ですが、各ステッ プ毎ですか？1commitにまとめたくなりますが、履 歴を残した方が良いでしょうか。 1 0 適切な単位でまとめるべきでしょう。今回の資料の作成では説明向けに細 かくコミットしてありますが。 TDDではインターフェイスの設計がキモだと思うの ですがこうした方が良いという指針はあります か？ 例えば現在時刻、DBアクセス、そもそも生成 に他のインスタンスが必要でそれを作るのが難し い、等 1 0 その辺の設計のうち、あまり凝ったものについては「TDDは死んだ」で否 定されたようなので、今後はほどほどに済ますようにしていくべきでしょ う。たとえばDBアクセスの分離はO/Rマッパーが対応してないとどうにも ならないように思えます。リポジトリパターン使うとどうも可読性が落ち ますし。時間はかかるようになりますが、あきらめてDBごとテストをする ようにすべきでしょう。少なくともDHHは今後その方針で行くようです。 現在時刻ならテスト時に固定値を出すようラッピングして使うのも難しく ないのでやっておくべきと思います。生成にほかのインスタンスが必要な のは自動テスト時代には設計が悪いの一言で済ませて設計しなおすべきで すが、とはいえこれもあまりやると設計が複雑になりすぎますので、あき らめて結合したままのテストとするのもよいでしょう。 足りないロジックは目に見える、という現象につ いてもう少し詳しく教えてください。 1 0 リファクタリングは、設計書として読めるほど可読性が良いコードを、 もっと可読性が高くなるように推敲する作業です。つまり、わかりやすく 整理された設計書を推敲?レビューしているのと同等に、ロジックのミス が目に見えます。
  • 2. 自動化によるテスト工程削減は大いに結構だと思 いますが、自動化する事でドキュメント整備が疎 かになりそうな気がしました。杞憂であれば良い ですが。 1 0 ドキュメントがなくても保守できるような工夫とセットで導入しないと、 TDDは成り立ちません。自動化しつつこれまでの手動の手順もそのまま残 していたら、自動化の意味がないのは当たり前のことです。 TDDの適用は部分的でも問題ないということでしょ うか 0 0 問題はありますが。全体に薄くテスト自動化を行うより、部分的にでも完 全にTDDが導入されていたほうが、はるかにやりやすいということです。 大きめのリファクタリングをするとテストが軒並 みレッドになる場合がありますが、 それらをメン テナンスしようとすると膨大なコストが掛かりま す。 不要なテストを削除する基準などはあります か？ 0 0 個人的な意見になりますが、個々のクラスのリファクタリングの影響を受 けないように、ある程度大き目な機能に対してのテストを書いていくべき だと思います。ただやりすぎるとそれはそれでテストの構造化ができない ためテストコード保守コストが爆発するので、バランスは重要です。 中の人などいない 0 0 そのとおりですね。