テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
Spockのテストレポートが想像以上に凄い件について - うさぎ組
タイトルはホッテントリメーカーを使いました。http://pha22.net/hotentry/tb/r?word=Spock%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88&phrase=9 全国49万のSpockユーザのみなさま。SpockのMLを見ていると思うので、ご存知かもしれませんがSpockのテストレポートをご存知でない方もいると思うので紹介します。 Spockのテスト結果はだいたいみんなGradleで見ている Spockは言わずと知れたUnitTestingFramework界最強といわれるテスティングフレームワークですが、これのテストレポートは通常はJUnitのテストレポートXMLであり、多くのSpockユーザはGradleでビルドをしてGradleが生成するテストレポートを見て
『Javaプロジェクトでテストをたのしく書くための試み』
こんにちは、Ameba事業本部ゲームプラットフォーム室の山田（@stormcat24）です。 自分のミッションは主にゲーム部門の開発の改善で、最近はScalaでモナ・・・しながらツールを書いてたりClojureに手を出したりしています。 はじめに ところでみなさんJava書いてますか？サイバーエージェントでは最近node熱が高いのですが、Javaプロジェクトもまだまだ根強く存在します。僕も隙あらばScalaをぶっこもうとしてますが、大人の事情でまだまだJavaを書くシーンも多いのです。 で、そんなテンションが上がりにくいJavaプロジェクトをやっていく上で、せめてテストくらいはなるべくたのしく書きたい！ということで、今のプロジェクトで取り入れた施策を簡単にですが紹介します。 めちゃくちゃ尖った技術を使ってるわけではないですが、これらをやっておけばそれなりに楽しく書けるかなと思ってますので、
[Spock] Spock 関連でゴニョゴニョしてる件 - bikisuke IN ACTION
こんばんは。[twitter:@bikisuke] です。 今日の Advent Calendar ネタは、Spock です。 僕は G* 一派だからという贔屓目は抜きにしても、Java のテスティングフレームワークとして Spock はもっと評価されるべきじゃないかと思ってます。 なので、今回はその辺りに触れつつ、密かに企んでいることについて書きたいと思います。 Spock のいいところ 何と言っても、シンプルな記述ができるところは Spock の大きな魅力ではないでしょうか。もちろん、テスト対象クラス（機能）によっては複雑になることもあるかもしれませんが、可読性に関しては JUnit の比ではないと思ってます。 # これは Groovy と Java の言語特性や制約に依るところが大きいので、Spock が良くて JUnit がダメと言ってるわけではないです。念のため。 あと、拡張の仕
![[Spock] Spock 関連でゴニョゴニョしてる件 - bikisuke IN ACTION](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e105fcb24ba320ea6bb3466ae5d0cffc52cd07f/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F3188f6d2844b134abcebc282b2508102b47ef302%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fb%252Fbikisuke%252F20121220%252F20121220234708.png)
GroovyでJUnitなテストを書くときの注意点……なんて無かった #gadvent2012 - 日々常々
Groovy!!（挨拶） G* Advent Calendar 2012 の13日目でございます。 前日: SpockでビルトインされているExtensionsとかそのへん - Yamkazu's Blog / @yamkazuさん 翌日: groovy.lang.MissingPropertyException*1*2 http://piyopiyoducky.net/gadvent2012/ / @gantawitterさん JUnitをGroovyで使うなど 何も考えずに突っ込みどころ満載のFizzBuzzとテスト（色々足りてない）を書きます。 HogeJava.java HogeJavaTest.java これをGroovyで書くとします。 HogeGroovyTest.groovy(ほぼ HogeJavaTest.java のまま) そのままJUnitとして動きます。Eclips
『ビルド・リリース自動化への足掛かりとしてのGroovy・Gradle・Spock』
はじめまして！Ameba事業本部プラットフォームDivでアプリケーションエンジニアをしている池田(@yukung)です。 私は2011年5月に大手SIerから転職し、サイバーエージェントへ入社しました。前職では主に金融業界をターゲットにしたBtoB向けのシステム開発に多く携わってきましたが、開発作業の中でこんな経験を割とたくさんしてきました。 ・ソースコードやドキュメントの管理にバージョン管理ツールを使わずに、Hoge_yyyyMMdd.javaとかDB設計_yyyyMMdd.xlsみたいなファイル管理をしてどれが正しいドキュメントかわからなくなりカオスになる ・ソースコードの静的チェックツール（CheckStyleやFindbugsなど）を使わずに、目視と気合でひたすらソースコードレビューする ・Excel表で書かれたテストケースを睨みながら、手でケースに沿ったオペレーションをしてデバッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
