JUnit 4で消耗しているあなたに贈るJUnit 5入門 - Taste of Tech Topics
こんにちは、しんどーです。 気づいたら入社8ヶ月くらい経ってました。 さて、待望のJUnit 5のGA版が今年9月にリリースされました！ この記事ではJUnit 5の概要と新機能の一部をご紹介したいと思います。 全部User Guideに書いてあるとか言わない JUnit 5とは JUnitとは、言わずと知れたJavaのテスティングフレームワークであり、 デファクトスタンダードの地位にあります。ですが現行のJUnit 4系の最初の メジャーバージョンリリースはすでに10年ほど前であり、保守性の低下が問題に なっていました。 そこでJUnitの刷新を目指すべく、JUnit 5プロジェクトが立ち上げられました。 Junit 5の特徴を簡単に述べると、 API・アーキテクチャの全面的再設計 マルチモジュール構成 Java 8のラムダ式を利用したAPI といったことが挙げられます。 JUnit 5
H2 をデータベースに指定した場合、spring.jpa.hibernate.ddl-auto を create にしてもテーブルが作成されない現象 - Qiita
H2 をデータベースに指定した場合、spring.jpa.hibernate.ddl-auto を create にしてもテーブルが作成されない現象jpaJUnitSpringBoot 概要 Spring Boot にて AuditorAware の機能を使用して作成日、更新日を設定していましたが、通常の SQL 実行時においてもデフォルト値として現在日時を設定するために columnDefinition にて既定値を設定するよう設定した結果、H2 データベースにテーブルが作成されなくなる現象が発生しました。 なお、MYSQL をデータベースに指定した場合、正常にテーブルが作成される動作になりました。 @MappedSuperclass @EntityListeners(AuditingEntityListener.class) @Getter public class Audit imp
JUnit5で変わるテストの書き方 - きしだのHatena
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
junitでWebAPIをテスト - Qiita
jUnitとrest-assuredを使ってWebAPIをテストする JSON形式のフォーマットを使うAPIのテストをする必要になったので以下にまとめます。 検証しながらなので間違いもあるかと思います。 必要なもの rest-assured junit dbunit(DBのレコードもテストするなら) リクエストのの設定 rest-assuredが自動的にリクエストに用いるObjectクラスをJsonに変換してくれます。 今回はJackson2を使っています。 以下の順でclasspathの存在を確認してシリアライズが行われます。 Jackson2 Jackson Gson ObjectMapperを使うので、その設定と接続先を指定します。 // api接続先ホスト名 RestAssured.baseURI = "http://localhost" // ObjectMapperの設定 Re
Spring BootでAutowiredされるクラスをMockitoでモックする - Qiita
はじめに Spring Bootで@Controller @Service @Repository@Componentといったアノテーションを付与したクラスはBeanとしてSpringのDIコンテナに登録され、利用するクラス側で@Autowiredアノテーションを当該クラスに付与することで、Springが生成したオブジェクトを利用できます。 ところで、Mockitoを使って先述のアノテーションを付与したクラスをモックしてテストしたい場合、通常の@Mockや@Spyではなく、Spring Bootが提供する@MockBeanもしくは@SpyBeanアノテーションを当該クラスに付与します。 これらのアノテーションを利用することで、Autowiredされるクラスの状態をモックオブジェクトで制御することができるようになり、単体テストや下位層が未完成あるいはテストで呼び出されるべきではない場合などに
【社内勉強会】JUnitの紹介(2017/08/02) ～作成中～ - Qiita
1. ソフトウェアテストについて ソフトウェア開発におけるテストの定義 ある条件下 使用するデータ 動作環境 事前の操作手順 ソフトウェアの振る舞いを記録できる データやデータベースの状態 画面表示(人が確認するだけでOKな場合もあり) 期待される結果との検証 ソフトウェアテストの目的 品質保証（メイン） 仕様が不足なく実装されていること 設計が妥当であることを検証 用語の確認 テストケース テストスイート 2. ユニットテストについて ユニットテストのパターン [xUnit Test Pattern]参照 ユニットテストを行う目的 プログラマにとって重要なスキル クラスやメソッドがプログラマの期待した振る舞いであることを検証 ユニットテストで確認しないこと（機能テストや受け入れテスト） クラスやメソッドの相互作用 ソフトウェアの機能の確認 品質の保証 P2参照 P31参照 ユニットテスト
ユニットテストの歴史とテスタブルなコードについて - Qiita
自己検証コードの歴史 「自己検証コード」の黎明期は1992年のOOPSLAであるらしい ACMが毎年開催しているオブジェクト指向の国際会議である 誰かがここでのスピーチで「クラスは自分自身の検証コードを含んでいないといけない」と言ったそうである 「技術的負債」という言葉が歴史的に初めて使われたのもここでのことらしい wikiwikiを作ったカニンガムが使ったそうである ケント・ベックの「エクストリーム・プログラミング(1999)」、マーチン・ファウラーの「リファクタリング(2000)」の出版以降、一般に自己検証コードの重要性が広まることになる 「エクストリーム・プログラミング」は、従来のウォーターフォールモデルへのアンチテーゼであり、継続的なデプロイにより、品質の高いソフトウェアを作るテクノロジである そのためにはテストコードが必要なことが述べられている 「リファクタリング」は、技術的負債
JUnitをバッチ実行してカバレッジも取得する方法 - Qiita
はじめに 自分へのメモ的な意味合いも兼ねて書きます。 私はまだSE歴も浅く技術力も知識も未熟なため、間違っているところがあるかもしれません。 もし間違っているところがあれば、指摘していただけると嬉しいです。で、できれば優しく。。 ＜前提条件＞ ・Windows10 64bit ・Java7 ・eclipse Version: Luna Service Release 2 (4.4.2) 以下のプラグインがインストール済み ・junit ver 4.12 ・maven 4.0.0 ・EclEmma 2.3.3 ・Hudson/Jenkins 1.4.0 １．jacocoをMaven依存関係に追加する。 ・pom.xmlファイルに以下の文を追加 <!-- jacoco --> <dependency> <groupId>org.jacoco</groupId> <artifactId>jaco
Testcontainersを使って、JUnitテスト中にDockerコンテナを起動／停止する - CLOVER🍀
前に、MavenのプラグインとしてDockerの操作を行う、docker-maven-pluginを試してみました。 docker-maven-pluginで、Integration Test時にDockerコンテナの起動／停止をする - CLOVER🍀 今度は、JUnitのRuleを使用してDockerコンテナの起動停止を行う、Testcontainersを試してみたいと思います。 GitHub - testcontainers/testcontainers-java: Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything e
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
suffix arrayを一番簡単なアルゴリズムで実装する - アルゴリズム学習(その6) - $shibayu36->blog;
文字列アルゴリズムを学んでいると、suffix array(接尾辞配列)という配列が出てくる。これは文字列の接尾辞の集合を辞書順にソートし、その順でそれぞれの接尾辞の文字列中の開始位置のindexを格納した配列のことである。以下が参考になる。 接尾辞配列 - Wikipedia サービス終了のお知らせ 例えばbananaの場合、接尾辞は - banana (position=0) - anana (position=1) - nana (position=2) - ana (position=3) - na (position=4) - a (position=5)となり、これを辞書順にソートしたものは - a (position=5) - ana (position=3) - anana (position=1) - banana (position=0) - na (position=
mockitoを使用したログメッセージの検証 - Qiita
Mockito.reset(mockAppender); // Appenderの名前を設定 Mockito.when(mockAppender.getName()).thenReturn("MockAppender"); // Appenderとして利用できる準備ができていることを設定（下2行） Mockito.when(mockAppender.isStarted()).thenReturn(true); Mockito.when(mockAppender.isStopped()).thenReturn(false); // ROOTロガーを取り出し、Appenderの設定を行う。 LoggerContext ctx = (LoggerContext) LogManager.getContext(false); Configuration config = ctx.getConfigu
JUnitでResponseEntityExceptionHandlerを有効にする - シュンツのつまづき日記
【前提条件】 [環境] JDK 1.8.66 Spring Boot 1.3.3 [参考サイト] Spring-Boot の @RestController の単体テストを記述する 【概要】 Spring BootでResponseEntityExceptionHandlerをJUnitでも動かす方法です。 通常であれば例外ハンドラを意識せずにテスコードは書けます。 しかし、MockMvcBuilders#standaloneSetupを使う場合は自動で例外ハンドラが設定されないため、 テストコードのセットアップ時に少し設定が必要になります。 【サンプルコード】 サンプルコードはこちらにあります。 ブログのエントリ上ではかなり省略しているので、詳細が気になる方はサンプルコードをみてください。 【コントローラと例外ハンドラ】 対象となるコントローラと例外ハンドラのコードは下記のような感じです
JUnit5(Alpha版)使い方メモ - Qiita
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
JUnitのテストメソッド名をどういう風につけたらいいかなー？ - Mitsuyuki.Shiiba
って話になって、チーム内で盛り上がった。例えばこんな感じのテストを書きたい時。 「ジュースを買う」メソッドに、お金とジュースの番号を入力したらそのジュースが返されて、在庫が一個減る。 メソッドはこんな感じかな？ Juice buyJuice(int inputAmount, int juiceId) これでどう？ buyJuice_shouldReturnJuice_whenInputAmountIs130Yen え？でもこれだと、なんかこう・・・在庫が減ってることとかは表せてなくない？ えー、じゃあこういう感じ？ buyJuice_shouldReturnSelectedJuiceAndOneLessInventory_whenInputAmountIs130YenAndSelectedIdIsValid いや、長いね・・・。 ふむ。。。全部をメソッド名に書かない方が幸せなんじゃない？
AssertJ 使い方メモ - Qiita
package sample.assertj; import org.junit.Test; import static org.assertj.core.api.Assertions.*; public class MainTest { @Test public void test() { assertThat("hoge").isEqualTo("Hoge"); } } org.junit.ComparisonFailure: expected:<"[H]oge"> but was:<"[h]oge"> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstru
【速報】JUnit5 はこうなる!?【プロトタイプ】 | DevelopersIO
渡辺です。 DevelopersIOでの100本目のエントリーがJUnitネタとなりました。 自分がJUnit実践入門を執筆したのは2011年から2012年にかけてです（出版が2012年11月）。 それからJava8がリリースされていますが、JUnit4自体は大きな進化はしていませんでした。 昨日、JUnit Lambda Prototypeが公開されました。 まだプロトタイプということで、今後の変更は大きいかと思いますが、いよいよ次世代のJUnitの足音が聞こえてきた感じがします。 今回は、このドキュメントからJUnit Lambdaの概要と方針について速報をお送りしたいと思います。 なお、現在JUnitチームでは、このプロトタイプに対するフィードバックを募集しています。 ここはこうじゃないとかはてブコメントする前にTwitterやGitHubでフィードバックを！ JUnit Lambd
JUnit5はどこに向かうのか？ | DevelopersIO
この表から解るように、一部の機能を除けばJUnit4の機能は継承されています。 したがって、JUnit4を理解していれば継承された機能をJUnit5に移行することは難しくないでしょう。 最初は多少の混乱はあるかと思いますが、すぐに慣れるレベルかと思います。 逆に、新しくJUnit5からJavaのユニットテストに入るのであれば、JUnit4の制約がないことは良い材料です。 特に、構造化テスト（ネストクラス）の時、JUnit4ではネストクラスをstaticクラスにすることを強いられていました。 これは、テストクラスをテスト毎に作成するという制約があったためです。 この制約がある以上、テストクラスからアウタークラスのインスタンス変数にアクセスできませんでした。 ユニットテストではテスト毎にテストインスタンスを作成することが原則なので、この制約は仕方ないと考えても良いでしょう。 しかし、テストがネ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JUnit 5リリース
どうしようJUnit5
