Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
#概要 Spring Boot にて AuditorAware の機能を使用して作成日、更新日を設定していましたが、通常の SQL 実行時においてもデフォルト値として現在日時を設定するために columnDefinition にて既定値を設定するよう設定した結果、H2 データベースにテーブルが作成されなくなる現象が発生しました。 なお、MYSQL をデータベースに指定した場合、正常にテーブルが作成される動作になりました。 @MappedSuperclass @EntityListeners(AuditingEntityListener.class) @Getter public class Audit implements Serializable { @CreatedBy private String createdBy; @CreatedDate @Column(nullable =
JUnit5が案外よさげなので、JUnit5を使うとどんな感じでテストが変わるのか考えてみます。 実際にどこが変わったかとか、使い方自体はいろいろまとめられたブログがあるし、公式ドキュメントも読みやすいのでそちらを。 http://junit.org/junit5/docs/current/user-guide/ メソッドごとのテスト JUnit5でいいのは、Nestedですね。 いままで、いろんなメソッドを対象にしたテストが入り混じってたと思います。 import org.junit.Before; import org.junit.Test; public class PurchaseTest { @Before public void setup() { // 全体のセットアップ // purchase()用のセットアップ // history()用のセットアップ } @Test p
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
【前提条件】 [環境] JDK 1.8.66 Spring Boot 1.3.3 [参考サイト] Spring-Boot の @RestController の単体テストを記述する 【概要】 Spring BootでResponseEntityExceptionHandlerをJUnitでも動かす方法です。 通常であれば例外ハンドラを意識せずにテスコードは書けます。 しかし、MockMvcBuilders#standaloneSetupを使う場合は自動で例外ハンドラが設定されないため、 テストコードのセットアップ時に少し設定が必要になります。 【サンプルコード】 サンプルコードはこちらにあります。 ブログのエントリ上ではかなり省略しているので、詳細が気になる方はサンプルコードをみてください。 【コントローラと例外ハンドラ】 対象となるコントローラと例外ハンドラのコードは下記のような感じです
JUnit5 の Alpha 版が公開されてたので、関西DDDに補欠になってしまった悲しみを紛らわすために使い方を調べた。 ※Alpha 版なので、今後変更されるかもしれません。 JUnit5 とは 言わずと知れた JUnit の次期バージョン。 Java 8 以上のみをサポートするようになり、 JUnit4 からは大きく変わっている。 でも、テストメソッドとか基本的な考えは変わっていない。 2016/02/06 現在、 Alpha 版が公開されている。 Hello World Gradle で使う方法（Maven でもいけるらしい）。 ビルドファイル buildscript { repositories { maven { url 'https://oss.sonatype.org/content/repositories/snapshots' } } dependencies { cl
org.junit.ComparisonFailure: expected:<"[H]oge"> but was:<"[h]oge"> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at sample.assertj.MainTest.test(MainTest.java:10) （以下略） 説明
この表から解るように、一部の機能を除けばJUnit4の機能は継承されています。 したがって、JUnit4を理解していれば継承された機能をJUnit5に移行することは難しくないでしょう。 最初は多少の混乱はあるかと思いますが、すぐに慣れるレベルかと思います。 逆に、新しくJUnit5からJavaのユニットテストに入るのであれば、JUnit4の制約がないことは良い材料です。 特に、構造化テスト（ネストクラス）の時、JUnit4ではネストクラスをstaticクラスにすることを強いられていました。 これは、テストクラスをテスト毎に作成するという制約があったためです。 この制約がある以上、テストクラスからアウタークラスのインスタンス変数にアクセスできませんでした。 ユニットテストではテスト毎にテストインスタンスを作成することが原則なので、この制約は仕方ないと考えても良いでしょう。 しかし、テストがネ
#みなさん、Serializable のテストってどうしてますか？？ え、やってない？！ まさか、そんな、ご冗談を．．． java.io.Serializable の実装は、見かけに反してとても難しいです。（少なくとも私はそう感じます。） どのような実装ミスの危険があるのか、どのようなテストをすべきなのか。 本稿から何回かに分けて、Serializable 実装クラスに対する JUnit テストについて考えてみたいと思います。 #おさらい：シリアライズ／デシリアライズ クラスのインスタンスが使われている間、そのオブジェクトはヒープメモリ上に展開されています。このメモリ上に "モヤっと" 存在しているオブジェクトを、ファイルに保存したりネットワーク越しに送信したりしようとすると、一列のバイト列に変換してやる必要があります。 これがシリアライズですね。 逆に、オブジェクトをファイルから読み込ん
メール送信はまだまだ業務で重要ですね。javaでメール送信をする処理をユニットテストしたいけどメールが大量に飛んでしまうのは困るし、誤って本番環境のメールアドレスにメールが飛んだら大変です。そんな時はwiserを使いましょう！ SubEthaMail build.grade メール送信ユニットテスト 雑感 SubEthaMail GitHub - voodoodyne/subethasmtp: SubEtha SMTP is a Java library for receiving SMTP mail wiserができる事は以下の通りです。 jarのみで仮想SMTPを立てられる組み込みメールサーバ機能を持つ。 アプリケーションからwiserに投げられたメールは破棄される。 wiserは送信されたメールの内容を記憶しており、メールの宛先等が取得できる。 組み込みの仮想SMTPなので例えば以下
2018/6/13追記 jUtaime は JUnit5 の登場によりその使命を終えました。 長らくご愛顧ありがとうございました m(_ _)m みなさま JUnit5 を使いましょう。 What's the issue ? JUnitでの例外検証コードをもっとスッキリ書きたいっ！ そう思っているのはきっと私だけではないはず・・・ before 例えば Person#setAge(int) なんていうよくあるメソッドを作ったとして、次の4点を検証したい。 setAge(-1) は NG → IllegalArgumentException をスロー setAge(0) は OK setAge(200) は OK ： 超長寿社会の到来に備えて。 setAge(201) は NG → IllegalArgumentException をスロー、例外メッセージあり 通常のJUnit4ではこんな感
JUnitに追いつこう(2周回遅れ、男子一万メートルだと2分近くの差、箱根駅伝なら4分40秒の差)という趣旨のエントリーです。 要約はこっちを見るほうが早かった kyon-mm.hatenablog.com irof.hateblo.jp Parameterized Test Parameterized TestがこれまではIterable<Object[]>だったのが、Iterable<Object>になったらしい。で、これに合わせるかのようにIntelliJ IDEAもParameterized Testでテストデータごとに結果を表示・再実行できるようになってた。で僕は、これまでパラメタライズドテストする場合は、Iterable<Object[]>を嫌って@RunWith(Theories.class)でテストしてたわけで、IntelliJ IDEAがParameterized Tes
ネットの検索結果でチラチラとは見ていたのですが、この度初めて自分でもDBUnitを使ってみました。ネット上のサンプルコードをほとんどそのまま実行しただけですが、私の手元でも簡単にユニットテスト用のDBとデータを準備することができました。 従来、H2 DatabaseはRunScriptで初期化用のスキーマを流し込んでいたのですが、これならJDBCドライバを選ばない気がします。 ※ 他のJDBCドライバでH2 DatabaseのINIT=RunScript相当の機能が可能なのか知りません。 ##環境 DBUnit 2.5.1 JUnit 4.12 ユニットテストのコード（パクリですが） 以下のような感じです。Excelファイルもデータソースとして使える点は、仕事でプログラムを作る人にとってかなりのアドバンテージな気がします。 import java.io.File; import org.j
事の起こり テストをしないでいることに耐えられず、むしゃくしゃしてやった。 反省はしているが後悔はしていない。 各種ダウンロード Pleiades All in One(Eclipse 4.4 Luna)1 諸般の事情によりUltimate Full Edition MySQL用のJDBCドライバ2 Platform Independent-ZIP Archiveをダウンロード このサイト3の下半分を参考にした JUnit/DBUnit関係のライブラリ ここ4を見ながらやればOK 取得したjarファイルは基本的にpleiades/eclipse/pluginsフォルダに入れて、プロジェクトごとにビルドパスを通している もっとうまいやり方があるのかもしれないのであとで探す データベースの準備 pleiades/xamppにあるsetup_zampp.batを実行 zampp_control.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[Java][test] Java Webテストツール文法まとめ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9f56659b822dd0872a7afe981b30328c50c18f44/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNTk0NzUlMkZwcm9maWxlLWltYWdlcyUyRjE3Mzg0NzI2MTI_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9ZDYwNWJiMWY5OGE0NTEyODRmMjlhOWQ0ZWRjMjM0ZjE%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D427d8c13291b6c4be1bd49cf10a50948%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCSmF2YSU1RCU1QnRlc3QlNUQlMjBKYXZhJTIwV2ViJUUzJTgzJTg2JUUzJTgyJUI5JUUzJTgzJTg4JUUzJTgzJTg0JUUzJTgzJUJDJUUzJTgzJUFCJUU2JTk2JTg3JUU2JUIzJTk1JUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9ZDA3ZWJiMzE3ZDBjMzg4NjZhMjBhZjcyMDg3NDdlZGE%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBzZW5nb2t1JnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9NGZjM2NlOTllNTNiODNlZjhjZDI2NGZmMjhlZDAwMTI%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D6c016af1838726b3d3892b59216ebc54)
