背景 経費精算システム「楽楽精算」は2009年にリリースされ、15年以上にわたり運用されてきました。 その間、基本的なシステム設計はリリース当初のまま維持されています。 しかし、年月が経つにつれ、技術トレンドやビジネス的な要求は大きく変化しましたが、現状のシステムではそれらの変化に柔軟に対応することが困難になってきています。 システムの柔軟性は低く、機能追加のたびに既存機能への影響を広範に調査する必要があり、既存の処理フローを変えることができないため、イレギュラーなテクニックが必要となることも多く、追加開発のたびに多くの手間とコストがかかるようになってきました。 すべての問題が現行システムに起因するわけではありませんが、特定のミドルウェアに強く依存した構造を持っているため、将来的な技術革新や新しいミドルウェアへの移行が困難であるという課題も抱えていました。 このような背景から、ミドルウェア
こんにちは、しんどーです。 気づいたら入社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
#概要 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
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で@Controller @Service @Repository``@Componentといったアノテーションを付与したクラスはBeanとしてSpringのDIコンテナに登録され、利用するクラス側で@Autowiredアノテーションを当該クラスに付与することで、Springが生成したオブジェクトを利用できます。 ところで、Mockitoを使って先述のアノテーションを付与したクラスをモックしてテストしたい場合、通常の@Mockや@Spyではなく、Spring Bootが提供する@MockBeanもしくは@SpyBeanアノテーションを当該クラスに付与します。 これらのアノテーションを利用することで、Autowiredされるクラスの状態をモックオブジェクトで制御することができるようになり、単体テストや下位層が未完成あるいはテストで呼び出されるべきではない場合な
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自己検証コードの歴史 「自己検証コード」の黎明期は1992年のOOPSLAであるらしい ACMが毎年開催しているオブジェクト指向の国際会議である 誰かがここでのスピーチで「クラスは自分自身の検証コードを含んでいないといけない」と言ったそうである 「技術的負債」という言葉が歴史的に初めて使われたのもここでのことらしい * wikiwikiを作ったカニンガムが使ったそうである ケント・ベックの「エクストリーム・プログラミング(1999)」、マーチン・ファウラーの「リファクタリング(2000)」の出版以降、一般に自己検証コードの重要性が広まる
はじめに 自分へのメモ的な意味合いも兼ねて書きます。 私はまだ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
前に、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
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
文字列アルゴリズムを学んでいると、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=
【前提条件】 [環境] 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
って話になって、チーム内で盛り上がった。例えばこんな感じのテストを書きたい時。 「ジュースを買う」メソッドに、お金とジュースの番号を入力したらそのジュースが返されて、在庫が一個減る。 メソッドはこんな感じかな？ Juice buyJuice(int inputAmount, int juiceId) これでどう？ buyJuice_shouldReturnJuice_whenInputAmountIs130Yen え？でもこれだと、なんかこう・・・在庫が減ってることとかは表せてなくない？ えー、じゃあこういう感じ？ buyJuice_shouldReturnSelectedJuiceAndOneLessInventory_whenInputAmountIs130YenAndSelectedIdIsValid いや、長いね・・・。 ふむ。。。全部をメソッド名に書かない方が幸せなんじゃない？
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) （以下略） 説明
渡辺です。 DevelopersIOでの100本目のエントリーがJUnitネタとなりました。 自分がJUnit実践入門を執筆したのは2011年から2012年にかけてです（出版が2012年11月）。 それからJava8がリリースされていますが、JUnit4自体は大きな進化はしていませんでした。 昨日、JUnit Lambda Prototypeが公開されました。 まだプロトタイプということで、今後の変更は大きいかと思いますが、いよいよ次世代のJUnitの足音が聞こえてきた感じがします。 今回は、このドキュメントからJUnit Lambdaの概要と方針について速報をお送りしたいと思います。 なお、現在JUnitチームでは、このプロトタイプに対するフィードバックを募集しています。 ここはこうじゃないとかはてブコメントする前にTwitterやGitHubでフィードバックを！ JUnit Lambd
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
