薄まる自分
PCやら育児やら、徒然についてメモります。
<< October 2018 | 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 >>
 
日本最大級の靴のネット通販 ロコンド.jp ブログパーツ
RECOMMEND
RECOMMEND
プログラミングGroovy
プログラミングGroovy (JUGEMレビュー »)
関谷 和愛 上原 潤二 須江 信洋 中野 靖治
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.

  • テストにより得られる物は控えめに考えなさい。テストは品質を上げない:が開発者は品質を上げる。
JUnitとSpockが混在したテストクラス。
※追記。下記の記事を書いてみたものの。irofさんのGroovyでJUnitなテストを書くときの注意点……なんて無かった #gadvent2012の方が包括的にまとまっていた(^^; まぁ、Enclosedだけについて参照してください。

JUnitはJavaのテスティングフレームワーク、SpockはGroovy上で動くテスティングフレームワーク。

Spock は Groovy 上で動くが、JUnit が提要する仕組みも使うことができる(もともと、Spock も JUnitのテストランナーで動作しているので当たり前といえば当たり前)。
JUnitには Enclosed というテストランナーがあり、それを使うとテストを構造化(階層化)することができる。
簡単に言うと、static メンバクラスを使って、階層を作り、全体のテストを実行したり、ある階層のテストだけを実行することができる。
Spockのテストで、Enclosed を使うと、一つのテストクラスの中で、JUnitのテストクラスとSpockのテストクラスを混在させることができる。
SpockでももちろんJUnitでできるテストは実行できるけど、あるテストはJUnitで書いて、あるテストはSpockで書きたいというときがあった場合には使えるかもしれない。


実行した結果は、 下記のようになる。
Spock test1:
Spock test2:
JUnit test:

IntelliJ IDEA での実行結果はこんな感じ。


Enclosed がさらにネストしてても、対応できるのではないかと思う。
ベネッセの幼児向け英語教材 ワールドワイドキッズ

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