Spock ちっくにテストデータを挿入してみた話 - Qiita
Java プロジェクトでのテストに、Groovy を使用するとすごく捗りますよね。 Spock まで採用していると、さらに捗りますね。 ただ、これらを使用しても捗らないものもあります。 それがテストデータの管理です。 これについては、みなさんどのようにしているのか、わたし自身も興味のあるところではありますが、ここではヒントになるかもしれない、アプローチのひとつをご紹介したいと思います。 環境 以下のとおり。 Java 1.8.0_45 Groovy 2.4.3 Spock 1.0-groovy-2.4 DBUnit 2.5.1 Spock の良さ Spock でのテストがなぜ捗り、快適なのか。 その助けのひとつとなっているのが where: の見通しの良さではないかと感じています。 多くの方が御存知のとおり、where: では、表形式でテストパターンを記述することができます。 以下のように
Property-based testing with Spock
Property based testing is an alternative approach to testing, complementing example based testing. The latter is what we've been doing all our lives: exercising production code against "examples" - inputs we think are representative. Picking these examples is an art on its own: "ordinary" inputs, edge cases, malformed inputs, etc. But why are we limiting ourselves to just few examples? Why not tes
GitHub Kaigiからの～Grails 2.3系にまつわるSpockやJUnitの話 - White Box技術部
※コメントを受けてSpock周りの話を修正しました（2014/06/23） GitHub Kaigi 先週GitHub Kaigiに行ってきました。 去年のLLまつり以来の勉強会ちっくなイベント参加だったのでかなり期待していましたし、 実際期待以上に面白かったです。 Rebuildの公開録音聴いてるときの家に居る感はすごかったｗ 特にはてなブログの開発フローの話とか、バグ管理システムを作ってる身としては色々思うところがあって面白かったです。 （受託開発的にはホワイトボードだけで管理される開発中の情報があると、後でお客さんの調査部門に怒られるかなーとか） いやー他にも色々話を聞いて、バグ管理システム作るの止めようかとも思ったのですが、 作ろうと思ったきっかけの理由はGitHub系のシステムじゃ満たしてくれないので、 利用フローをちゃんと提示することを忘れずに、このまま作ってみようと思います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
