【JUnit5】MethodSourceで空Streamをエラーにしたくない場合の対処

状況

JUnit5ParameterizedTestで、MethodSourceが空Streamを返した場合、以下のようなエラーになります。

Configuration error: You must configure at least one set of arguments for this @ParameterizedTest
org.junit.platform.commons.PreconditionViolationException: Configuration error: You must configure at least one set of arguments for this @ParameterizedTest

このエラーは、例えば「Abstract Classにテストを定義し、各実装でMethodSourceを実装する」ような形でテストを実装している場合問題になります。

対処法

この問題は、EnabledIf/DisabledIfアノテーションを用い、テストを実行しないパターンを設定することで回避できます。
例えば以下のようになります(サンプルコードはKotlinですがJavaでも殆ど同じになります)。

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
abstract class Foo {
    abstract fun provider(): Stream<Arguments>

    private fun providerReturnsEmpty(): Boolean = provider().count() == 0L

    @ParameterizedTest
    @MethodSource("successProvider")
    @DisabledIf(value = "providerReturnsEmpty", disabledReason = "providerが空を返すため")
    fun test(/* 引数略 */) { /* テスト実装略 */ }
}

補足

EnabledIf/DisabledIfはどれ位何ができるか

EnabledIf/DisabledIfの詳しい使い方については以下のドキュメントで紹介されています。

junit.org

また、当該のドキュメントには出てきませんが、Springと組み合わせている場合SpELという記法で書くこともできます。

www.baeldung.com

ただ、個人的には、サンプルで紹介したようにbooleanを返す引数無し関数を定義するやり方をおすすめします。
理由は以下の通りです。

  • 読み書きに知識が必要になって面倒
  • アノテーション内で複雑なことをやり始めると(特にJavaでは)読みにくくなる

ParameterizedTestの方にオプションは無いのか

ParameterizedTestの方で空Streamをエラーにしないオプションは無いのか」と思われるかもしれませんが、それは提供されていないようでした。
詳しくは下記のissueにてやり取りが有ります(このオプションが欲しい方は👍を残すなりお願いします、自分は残しました)。

github.com

1年のアウトプットを振り返る

毎年やっている振り返りですが、今年もやります。

wrongwrong163377.hatenablog.com

アウトプットまとめ

まず今年1年で行った主なアウトプットです。

外部OSSへのコントリビュート

昨年のOSS活動は自作ライブラリへのコントリビュートが主でしたが、今年は多くの外部OSSにコントリビュートしました。
数だけなら8リポジトリに対してです。

外部OSSへのコントリビュートを始めたのは2020年の12月末からで、自分の時間の使い方としては一番大きな変化だったと思います。

多くはドキュメントやビルドスクリプトの微修正ですが、FasterXML/jackson-module-kotlinsquare/moshiには実際に動くコードでコントリビュートしました。
特にFasterXML/jackson-module-kotlinについては多くの修正・改善・機能追加を行いました。

外部OSSへのコントリビュートに関しては、来年も継続して行っていきたいと思っています。

自作ライブラリについて

自作ライブラリについては、正直メンテのモチベが下がっている状態です。
色々な改善案は思いついているものの、GitHubスターや利用者の反応はあまり得られず、かと言って宣伝等する気にもなれないので放置してしまっています。

正直、現状では上手いことモチベーションが湧くような機会待ちという感が有ります……。

ブログ

今年は特にブログでのアウトプット量は減少しました。
これは、OSSへのコントリビュートを始めたことも有りますが、新しいことに取り組む機会が少なかったり、精神的にモチベーションが低下していたことが大きいかなと思います。

それでも60本は書けており、2017年からの年間ブログ数50本記録は継続できました。

12月からは新しい会社で働きはじめ、新しいことに取り組む機会はどんどん増えていくものと思われるので、来年はアウトプット量を増やすことができればと思います。

終わりに

今年のアウトプット量は減ってしまいましたが、有名(= 沢山使われている)OSSに方々で貢献できたことも有って、アウトプットの価値は過去最高に高い1年だったのかなと思います。
ドキュメント修正・コードの両方でコントリビュートは続けていきたいです。

私事の方でもいい感じにアウトプットを続けていければと思っています。

それではよいお年を。

【gradle】gradlewの実行がGeneral error during semantic analysis: Unsupported class file major version 60で失敗する問題への対処

TL;DR

  • ローカルのJavaバージョンを16から1.8に変更することで成功するようになった

本文

当該のgradlewはバージョン6.xで生成されたもので、これはJava 16には対応していません。
gradlewの再生成ができない状況だったため、ローカルのJavaバージョンを1.8に落とすことで対処しました。

参考にさせていただいた記事

yusuke.blog

【日記】Intellij IDEA Ultimateの無料トライアルがJetBrainsアカウント必須になっているっぽい

今まではIntellij IDEA Ultimateの無料トライアルはアカウント登録も不要な完全無償で行えていました。
このため、ライセンス発行までどうしても時間がかかる場合なんかには無料トライアルで済ませることができていました。

一方、今日見た所アカウント登録が必須になっているように見えました(アカウントを新しく作ってまで確認するのは面倒だったのでやっていません)。
恐らく他のJetBrainsIDEでも同様の状況になったものと思われます。

昔の仕様を悪用すればライセンス期間を無理やり伸ばすようなことができていましたし、JetBrainsの収益的にはこちらの方が絶対にいいとは思います。
ただ、ライセンス発行が会社の手続き待ちになったり、オープンソース開発用ライセンス発行を待つような状況で無料トライアルを利用しにくくなるのは不便だなあと思いました。

www.jetbrains.com

余談ですが、自分はオープンソース開発用ライセンスの発行とライセンス購入時期が被ったせいで無料ライセンスがほぼ無駄になった悲しい過去が有ります。
この辺もう少し融通が利くようにして欲しいなあ……。

画像や動画の透過情報をChromeで確認する

TL;DR

  • コンテンツをChromeで開き、開発者ツールでbackgroundを設定することで、背景色を変えてプレビューできる
    • カラーパレットから色を変更すればより分かりやすく確認できる
  • 変更対象とする要素は、有ればbody、無ければ一番外側の要素が安定
  • Chromeに限らず、開発者ツールから内容を書き換えられるなら別ブラウザでも同等の確認が可能

背景

画像や動画などで透過有りの内容を確認するとき、プレイヤーなどの背景が真っ黒で、黒で塗りつぶされているのか透過しているのか分からない場合が有ります。
そのような場合に、プラットフォームを問わずにそれらを確認する方法として、Chromeとその開発者ツールを使った方法を紹介します。

やり方

下記のサイトから画像をお借りしてやり方を紹介します。

icooon-mono.com

まず画像ファイルをChromeで開き、そのタブでF12キーを押して開発者ツールを開きます(画像では見やすさのためウィンドウサイズを変更しています)。

f:id:wrongwrongwrongwrong163377:20211101151237p:plain
開発者ツールを開いた様子

次に、elementsタブでHTMLを表示し、body要素にカーソルを合わせ、クリックします。

f:id:wrongwrongwrongwrong163377:20211101151515p:plain
bodyをクリックした状態

最後に、StylesタブからCSSbackground要素のカラーコードをダブルクリックし、適当な値に変更することで、背景色が変更できます。
画像では#0e0e0eからaquaに変更しています。

見た目通りかもしれませんが、この画像は背景が変化していないため、透過が無効になっていることが分かります。

f:id:wrongwrongwrongwrong163377:20211101152951p:plain
背景色を変更した様子

また、小さい四角で色のプレビューが表示されていますが、これをクリックすることでカラーパレットを開くことができ、手動でさまざまな色を設定することができます。
変更はリアルタイムで反映されるため、透過の確認に便利です。

f:id:wrongwrongwrongwrong163377:20211101153414p:plain
カラーパレットから変更している様子

ここまで紹介した内容は、同等の機能を持ったブラウザであればどれでも利用できます。

補足・注意点

今回の例ではbackgroundプロパティが最初から存在していましたが、これが無い場合もあります。
その時は、ここまで紹介した画像でいうelement.styleをクリックし、backgroundプロパティを追加することで対応できます(画像の通り、途中まで入力すれば補完が効きます)。

f:id:wrongwrongwrongwrong163377:20211101153200p:plain
プロパティを追加している様子

書き換え対象をbodyとして紹介したのは、画像や動画をいくつかプレビューしてみた限りでは、ここを書き換えれば背景色を適切に書き換えることができたためです。
ただし、SVGファイルのようにbodyでラップされていない状態になるものや、bodyでは背景を書き換えられない内容もあり得るため、その場合は適切な要素の背景を書き換える必要があります(bodyが無い場合、まず一番外側の要素から書き換えを試すと良さそうです)。

f:id:wrongwrongwrongwrong163377:20211101154225p:plain
SVGの背景を編集している様子

また、Chromeでプレビューできないメディアの場合、残念ながらこの方法は使えません。

【DbUnit】DatabaseSetupで、特定ディレクトリに配置したファイルがUnable to load dataset from ${ファイル名}となって読み込めない問題への対応【Spring】

TL;DR

  • 問題が起きているディレクトリを一旦削除して作り直し、ファイルを配置し直した所解決した
    • 恐らくDbUnit等の不具合ではなかったと思われる

状況

SpringDbUnitでテストを作成していた所、DatabaseSetupアノテーションに設定したファイルがjava.lang.IllegalArgumentException: Unable to load dataset from "${ファイル名}" using class com.github.springtestdbunit.dataset.FlatXmlDataSetLoaderという内容のエラーになり、読み込めない問題が発生しました。

このエラーは「ファイルが読み込めない」という内容で、基本的には入力のtypo等で発生する問題です。
一方、自分の遭遇した状況では、アノテーションに設定するファイル名やファイルパスをいくら直して確認しても解決しませんでした。
また、他のテストでは同じ文法で書いていて、特に問題が発生していない状態でした。

確認・対応

一旦はtypoや制御文字が入り込んだことを想定し、diffを取りながら動作確認を行いました。

それでも解決しなかったため、別ディレクトリに配置して実行する検証を行った所、特定ディレクトリに配置した場合に再現することが確認できました。
そこで、一旦ファイルを退避した上でディレクトリを再度追加して実行した所、成功するようになりました。
なお、この変更の前後でgitのdiffは出ていませんでした。

補足

この問題は、mac環境で、Intellij IDEAから全てのファイル・ディレクトリ操作を行っている間に発生しました。

MacのDocker Desktopが更新できない問題への対処

ここで紹介する方法は正規の更新手段でなく、設定ファイルに変更が入っていたりすると動かなくなることも考えられるため、実行は自己責任でお願いします。


自分のMac環境で、Docker DesktopからDownload Updateを押しても実行が上手く行かず、更新できない状態になりました。
そこで、以下の手順で更新を行いました。

  • Docker DesktopQuit
  • 公式ページからdmgファイルをダウンロード
  • ダウンロードしたファイルで現在のアプリを置き換え

この方法でも、設定やコンテナはそのままになっていました。
ただし、ここで紹介した方法は正規の更新手段でなく、設定ファイルに変更が入っていたりすると動かなくなることも考えられるため、実行は自己責任でお願いします。