見出し画像

薬学生エンジニアによるプログラミング学習でのエラー奮闘記、そこから得た学びをお話します!

今回の話のネタは「自動テストの導入作業」

 こんにちは!薬学生エンジニアの伊藤です。今回の内容は個人開発で取り組んでいるJava(spring boot)へのテストツール(Junit Dbunit)の導入作業。ここから得た学びについてです。

 1.作りたかったもの→2.エラー発生→3.そこから得た学び
の順にお話します。プログラミング学習始めたけど原因不明のエラーが出てしまい先に進めない、挫折しそうみたいに悩んでる方がいましたら考え方など是非参考にしていただければと思います!

初めに:今回作りたかったもの

 僕は以前の記事でも説明したように現在ポートフォリオ第二弾として処方監査ツールの個人開発に取り組んでいます。 ソースはこちら

 今回の一連の作業は「自動テストツール」の導入作業でした。

作りたかったものの概要です!

 主にDBunitを用いて、データベースへのアクセス階層のテストを行うような実装を目指しました。この層をテストしようと思った理由としてはカスタムクエリとしてSQLを書いているのがここだったためです。

 そもそもDBと情報をやり取りしているコードにテストを書くのは「正しいデータを取れる事を担保すること」が目的であることが殆どだと考えています。

 テスト用データベースをH2などのインメモリにせず、敢えて別コンテナとして分離して建てたのはアプリケーションコンテナのメモリ負荷を考えてのものでした。

 デプロイ時にテストDBコンテナ起動→テスト実行→テストDBコンテナ停止→アプリケーションのコンパイル,起動みたいな流れにしたかった感じです。

※もしインメモリのデータベースだけを止めるような方法知ってる方いたら教えて欲しいです!

学び:今回の一番の学びは「エラーとの向き合い方」だった。

自動テストにこだわった理由

 今回の実装作業、かなり多くのエラーにぶつかりました・・・
隙間時間に作業を進めていたのもあり、テストが完璧に通るようになるまで2週間ほどかかってしまったと思います

 そこまでしてでもテストコードを導入を成功させたかった理由としては2つほどありました。1つは学習目的、もう1つは今後の開発効率を考えての事でした。

 まず最初の学習目的についてですがこれが一番大きい理由だったと思います。というのも今回の開発の目的は「長期インターンを通して一度プロの業務を知った学生エンジニアが」それに匹敵するレベルの開発をできるようになる事がそもそもの学習目的だからです。

 それなりの規模とポテンシャルを持つアプリケーションを自作すると機能の担保は必須になります。その第1歩として単体自動テストの導入は何が何でも自力で成し遂げたかったのです!

 今回の実装を通してDbunitの使い方の勉強にもなりました。が、それ以外にもスタブ、ドライバ、モックなどのテストに関連する用語の理解、そしてテスト用データベースを構築する為のインフラ知識、複数データベースに対するマイグレーション管理など学べることは非常に多かったです!

 色色あって時間こそかかってしまいましたが、当初の目標通りにテスト周りの構築を達成することができました。以下の画像は作った部分の概要です!

実装完了したテストの全体像 プルリクはこちら

今後に活かしたいエラー解決能力

 実装する際にぶつかったエラーは以下のようなものでした・・・

org.dbunit.dataset.NoSuchTableException at DatabaseDataSet.java:278

1.データベースが存在しているはずなのにテーブルが存在しませんエラー
2.コネクションが確立出来ませんエラー

 実際に上記の実装を達成する為にこちらの記事を参考に開発を進めていたのですがなかなか上手く行かなかったです。最終的な原因としてはDbunitやspring-testのアノテーションのバージョン互換性import先が間違っていたなどが原因でした。

 特に後者の間違いについては以下のようなイメージです。

エラーのイメージ

 ただこれ厄介なことに依存関係のバージョンによってimport先が違うみたいなことが起こりえます。例えばjunit4では import org.junit.Testでいいのにjunit5だとorg.junit.jupiter.api.Testにしなきゃいけないなどです。

 これは標準パッケージのバージョンによって使いたい部品が置かれてる場所が違うことなどが原因です。

 新しい依存関係を使う以上、ネット上の情報をそのまま流用するのではなく内部のコードを端から端まで読んでモジュールの構造を理解するくらいやらないと上記の問題点は解決できないと感じました。

 今回のパターンに限らず、新しい実装をする際は最初に多少時間かけてでもしっかり調べて記録に残す。そうすることで後々しっかり動くコードとして流用することができ将来的な技術的資産につながるのでは?との気付きもありました。まさに急がば回れです!

反省と足りない点

 学びの多かった今回の実装ですが、やはり反省も多いです。その中でも一番は時間かかりすぎ問題です。今回は仕事ではないのでいいですが、もしこれが実際の開発業務だったら?と考えると二週間はかかりすぎです。

 これが僕が今後エンジニアを目指していく上での課題になるのかなと感じたところでした。その対策としてエラーへの対処を自分の中である程度マニュアル化してみようと考え、以下のようなフローチャートに整理してみました!

 エラー解決できず悩んでいる初学者の方などいましたら是非参考にしてくれればと思います!

おまけ:エラーにぶつかったときの考え方をフローチャートにまとめてみました!

エラー対策フローチャート

 最後までお読みいただきありがとうございました!😊

コードを参考にしたい方は是非こちらもご覧下さい。
https://github.com/poteto1212/medicine_audit_system/pull/19


この記事が気に入ったらサポートをしてみませんか?