薄まる自分
PCやら育児やら、徒然についてメモります。
<< March 2024 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>
 
デル株式会社 ブログパーツ
RECOMMEND
RECENT COMMENT
RECENT TRACKBACK
カウンタ
ブログパーツUL5
JUGEM PLUS
MOBILE
qrcode
PROFILE
PR
無料ブログ作成サービス JUGEM
 
スポンサーサイト

一定期間更新がないため広告を表示しています

- | | - | - | - | - |
"Why Most Unit Testing is Waste"を訳してみた。
最近話題になったDHHのブログTDD is dead. Long live testing.でも引用されていたJames O Coplienさんの論文"Why Most Unit Testing is Waste"について語る会 - スクラム道場.12 with Jim Coplien (英語:通訳なし) -に行ってきた。
豪雨の中、行ってきたかいがあったし、こんな会を開いていただいてありがたかった。また、会場提供のVOYAGE GROUPさんも無料で、寿司、ピザ、飲み物などの提供があり、素晴らしかった。ありがとうございました。

で、行く前に読むべしと思って"Why Most Unit Testing is Waste"を読み始めたのだが、19ページもあって、これはぱぱっと読めるものじゃないなと思って、最後を見るとIn Summary というところがあったので、そこだけを訳してみた。

自分で書いていても意味がよくわからないところもあるので、コメントいただけるとありがたい。
 

Keep regression tests around for up to a year - but most of those will be system-level tests rather than unit tests.

  • 再帰テストを最大1年間は続けなさい。ほとんどの再帰テストはユニットテストよりむしろシステムレベルのテストになるだろう。

Keep unit tests that test key algorithms for which there is a broad, formal, independent oracle of correctness, and for which there is ascribable business value.

  • 広範囲に適応可能で、形式的で、正しさの独立した預言者であるところの、ビジネス価値を産み出すためのキーアルゴリズムをテストするユニットテストであるなら続けなさい。

Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system test ? context is everything.

  • 前のケースを除いて(そんなユニットテストでなく)、もし、Xがビジネス価値を持つならば、X をシステムテストもしくは単体テストでテストしてもよい。システムテストを使うというのも、コンテキストが全てだ。
※text を test の誤植として訳したがあっているか。

Design a test with more care than you design the code. 

  • コードをデザインするよりもテストをデザインせよ。

Turn most unit tests into assertions. 

  • ほとんどのユニットテストをアサーションに変換せよ

Throw away tests that haven’t failed in a year. 

  • 1年以内に失敗していないユニットテストは投げ捨てよ。

Testing can’t replace good development: a high test failure rate suggests you should shorten development intervals, perhaps radically, and make sure your architecture and design regimens have teeth 

  • テスティングだけでよい開発を代替することはできない:高いテスト失敗率はたぶん急進的に短い開発間隔を取る事や、アーキテクチャと設計の変更に効果があるかを確認すべきだと教えてくれる。

If you find that individual functions being tested are trivial, double-check the way you incentivize developers’ performance. Rewarding coverage or other meaningless metrics can lead to rapid architecture decay. 

  • もし、個々の関数がテストされていることがとるにたらないことだとわかったなら、開発者のパフォーマンスに励みをあたえるやり方を二重チェックせよ。カバレッジに報酬を与えることや他の意味の無いメトリックスは急速なアーキテクチャの腐敗を招く。

Be humble about what tests can achieve. Tests don’t improve quality: developers do.

  • テストにより得られる物は控えめに考えなさい。テストは品質を上げない:が開発者は品質を上げる。
スポンサーサイト
- | 01:55 | - | - | - | - |
デル株式会社
コメント
コメントする









 

(C) 2024 ブログ JUGEM Some Rights Reserved.