アカウント名:
パスワード:
> テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。まずこれから疑った方がいいと思うけど。内容にもよるがテストを書くのが一番つらい。
>内容にもよるがテストを書くのが一番つらい。たしかに例外的にテストが不向きな分野というのはある。
もしそのような例外的分野で無いとしたら、「テストを書くのがつらい」と言ってる人間のスキルをまず疑うべし。
#テストを書けない理由が、モジュール化できてなかったり、#入出力もろくに定義できてなかったりということがあるのよ。
#他人の書いたレガシーコードが原因の時は。。。orz
検索したらこれが見つかったんですが、http://gihyo.jp/dev/serial/01/tdd/0014 [gihyo.jp]
問題は、これがあまりに多すぎて「例外」に見えないところです。まあ上記の記事ではDBについてはそれ用のツール使うとなってますが、何かひっかかってます。
経験上「テストを先に書くのはコストばかりかさんで工期が増えるだけ」と言ったところは、ほぼコードの質が低く、今までまともなテストとかしておらず、コード修正時にまともに退行テストなどを行っておらず、基本的に納品後に現場張り付きで修正を繰り返す感じです。
先にテストを書くのは確かに工数かかりますが、同品質のテストをする以上「テスト項目を洗い出し、実行するのがコードを書く前か後か」の違いしかないはずなので、そこで工数が変わるわけがないんですよね。 そこで「テストが後の方が工数が減る」というのは、テスト工数を潰す気満々でしかないという感じです。
そうですか?テストを定義できさえすればいいのでみんな割と遊んでいます。ガス抜きっていうか。いやまぁ、かっこいいけれど速度がべらぼうに遅いとか、環境依存とか、困ったのを書いちゃうことはあるけど。つらいっていうほど時間も食わないと思いますけどね。
# 俺のテストのカバレッジが100%行かないのはなぜだって言って、カバレッジ計測ソフトのソースコードから調べた奴もいた。
でもまぁ、テスト駆動っていい実践だと思いますよ。高レベルのアプリケーションを書くプロジェクトではとくに。とりわけビジネスロジックの実装をするお仕事では威力が高い。
作ってるシステムにもよると思いますが、自分が入ってるプロジェクトだと、IOが関わるところ(DBへの読み書き)がメインだから自動テストは作りにくいんですよね。スタブ作ると労力かかりすぎるし、IOを除いたテストしやすい形でコード書くと逆に分かりにくくなるし。
あと最上位のメソッド以外はリファクタリングを頻繁にするので、その度にテストコード書き直すのはたぶんかなりのストレスになります。
もちろんコード変更したらテストはしますが、手動のテストで十分で、自動テストに取り組むモチベーションがありません。だからTDDについては本当にいいの?ともやもやしてます。
作ってるシステムにもよると思いますが、自分が入ってるプロジェクトだと、 IOが関わるところ(DBへの読み書き)がメインだから自動テストは作りにくいんですよね。 スタブ作ると労力かかりすぎるし、IOを除いたテストしやすい形でコード書くと逆に分かりにくくなるし。
この辺りなんですが、単体テストクラスごとに個別に DB を簡単に作成できるかどうかというのがポイントではないでしょうか。SetUp/TearDown で CREATE/DROP DATABASE していいかどうか、とか。 というか、こういう事ができて簡単にテスト用データを (テストごとにトランザクション作って) 突っ込めないと、まともな自動化テストとかやってられないと思うのですが。
単体テスト的な話で言うと、実行時間が格段に跳ね上がる (ひどいと数十の DB を一気に作りに行き、一気に削除する) とか、他の実装に依存したら単体じゃないだろとかツッコミどころは出てきますが。
リファクタリング後のプライベートメソッドまで単体テストを追加しているなら、単体テストにも書き直し (正確には追加) が入るのではないかと。 パブリックレベルで書き直しが入ったら問題ですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
まず疑うべきところ (スコア:0)
> テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。
まずこれから疑った方がいいと思うけど。
内容にもよるがテストを書くのが一番つらい。
Re:まず疑うべきところ (スコア:2, 興味深い)
あえて/いやいやでもサブプライムに回る側になり得る人が居る程度ならいいけど、ベストプラクティスを
突き詰めていくと、サブプライム側が、「人類には不可能なmission impossibleな作業」になってしまって、
実現不可能になるのがおち。
上澄みとサブプライムとトータルで考えて、やっていける開発プロセスならいいかも。
テスト駆動は、仕様の確定をサブプライムにしてうやむやにしようとしている企て以外の何者でも無い!
Re:まず疑うべきところ (スコア:1)
>内容にもよるがテストを書くのが一番つらい。
たしかに例外的にテストが不向きな分野というのはある。
もしそのような例外的分野で無いとしたら、
「テストを書くのがつらい」
と言ってる人間のスキルをまず疑うべし。
#テストを書けない理由が、モジュール化できてなかったり、
#入出力もろくに定義できてなかったりということがあるのよ。
#他人の書いたレガシーコードが原因の時は。。。orz
Re: (スコア:0)
検索したらこれが見つかったんですが、
http://gihyo.jp/dev/serial/01/tdd/0014 [gihyo.jp]
問題は、これがあまりに多すぎて「例外」に見えないところです。
まあ上記の記事ではDBについてはそれ用のツール使うとなってますが、何かひっかかってます。
Re:まず疑うべきところ (スコア:1)
経験上「テストを先に書くのはコストばかりかさんで工期が増えるだけ」と言ったところは、ほぼコードの質が低く、今までまともなテストとかしておらず、コード修正時にまともに退行テストなどを行っておらず、基本的に納品後に現場張り付きで修正を繰り返す感じです。
先にテストを書くのは確かに工数かかりますが、同品質のテストをする以上「テスト項目を洗い出し、実行するのがコードを書く前か後か」の違いしかないはずなので、そこで工数が変わるわけがないんですよね。
そこで「テストが後の方が工数が減る」というのは、テスト工数を潰す気満々でしかないという感じです。
Re: (スコア:0)
そうですか?
テストを定義できさえすればいいのでみんな割と遊んでいます。ガス抜きっていうか。
いやまぁ、かっこいいけれど速度がべらぼうに遅いとか、環境依存とか、困ったのを書いちゃうことはあるけど。
つらいっていうほど時間も食わないと思いますけどね。
# 俺のテストのカバレッジが100%行かないのはなぜだって言って、カバレッジ計測ソフトのソースコードから調べた奴もいた。
でもまぁ、テスト駆動っていい実践だと思いますよ。高レベルのアプリケーションを書くプロジェクトではとくに。
とりわけビジネスロジックの実装をするお仕事では威力が高い。
Re: (スコア:0)
作ってるシステムにもよると思いますが、自分が入ってるプロジェクトだと、
IOが関わるところ(DBへの読み書き)がメインだから自動テストは作りにくいんですよね。
スタブ作ると労力かかりすぎるし、IOを除いたテストしやすい形でコード書くと逆に分かりにくくなるし。
あと最上位のメソッド以外はリファクタリングを頻繁にするので、
その度にテストコード書き直すのはたぶんかなりのストレスになります。
もちろんコード変更したらテストはしますが、手動のテストで十分で、
自動テストに取り組むモチベーションがありません。
だからTDDについては本当にいいの?ともやもやしてます。
Re:まず疑うべきところ (スコア:1)
この辺りなんですが、単体テストクラスごとに個別に DB を簡単に作成できるかどうかというのがポイントではないでしょうか。SetUp/TearDown で CREATE/DROP DATABASE していいかどうか、とか。
というか、こういう事ができて簡単にテスト用データを (テストごとにトランザクション作って) 突っ込めないと、まともな自動化テストとかやってられないと思うのですが。
単体テスト的な話で言うと、実行時間が格段に跳ね上がる (ひどいと数十の DB を一気に作りに行き、一気に削除する) とか、他の実装に依存したら単体じゃないだろとかツッコミどころは出てきますが。
Re: (スコア:0)
Re:まず疑うべきところ (スコア:1)
リファクタリング後のプライベートメソッドまで単体テストを追加しているなら、単体テストにも書き直し (正確には追加) が入るのではないかと。
パブリックレベルで書き直しが入ったら問題ですが。