アカウント名:
パスワード:
激しく同意。
でも、GUIやDB周りのテスト自動化は難しいッス。
同じく単体テスト部分だけ部分導入しました. あいまいな仕様をもとに作業している上に, 人が少ない・納期が厳しい時にはドキュメントを いちいち残していられないので、テストがドキュメント (=仕様)代わりになっています.(提出すべき仕様は 後からまとめればいい)
ペアプログラミングも興味がありま
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
テストバカになる(いい意味で) (スコア:3, 興味深い)
Re:テストバカになる(いい意味で) (スコア:2, 参考になる)
ところで、GNUにはXPが話題になるずっと前から、DejaGnuってのがあったと思うのだけど、使っている人っています?
Re:テストバカになる(いい意味で) (スコア:1)
激しく同意。
僕も、XPはUnitTestから導入してみました。効果は絶大です。自動テストなのでソースの改善が自由に出来ますからね。
動いてるものは汚くてもいぢるな!」
という近視眼的な考えにとらわれる必要がなくなります。
でも、GUIやDB周りのテスト自動化は難しいッス。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:テストバカになる(いい意味で) (スコア:0)
同じく単体テスト部分だけ部分導入しました. あいまいな仕様をもとに作業している上に, 人が少ない・納期が厳しい時にはドキュメントを いちいち残していられないので、テストがドキュメント (=仕様)代わりになっています.(提出すべき仕様は 後からまとめればいい)
ペアプログラミングも興味がありま
Re:テストバカになる(いい意味で) (スコア:1)
この頃は、そうあっていいんじゃない、という事で、どのように作られているか(設計書)は軽視してます。結局の所、テスト(検証)にパスすれば製品として出荷 OK となるので。
仕様書には、やりたい事が記述されているので、どういう検証を行えばソレが実装されているかを考えます。
仕様変更が舞い込んで来た時も、どのような検証でもって、既存部に影響の無い事、追加分が実装されている事を確認できるかを考える。
初めにテストありき。自分自身 昔は、どう作ろう?という事ばかりに囚われ過ぎていたように感じます。
プログラマのトッピング (スコア:0)
ペアプログラミングの利点で,指向の異なるプログラマーをペアにすることで,コードの偏りを防げるのではないだろうか.
たとえば,セキュリティに強いプ