新年度が始まって半月が過ぎたが、新入社員の退職希望を企業側に伝える「退職代行」サービスに、早くも依頼が殺到している。
⇧ まぁ、人手不足と言われてる時代ですから、待遇の良い会社に転職できるんであれば、転職する流れになるのは然もありなん。
何と言うか、
「働いたら負けかなと思ってる」（はたらいたらまけかなとおもってる）は、2004年に日本で生まれ流行したインターネット・ミーム。
⇧ この言葉が2004年に世の中に知らしめられたとして、今が2024年なので、20年ぐらい経過したわけですが、働いて良いと思えない社会的な状況になっているのが問題な気がしますかね...
仮に人間が生活する上で必要なコストを生涯保障する仕組みが完成したら、働かない選択肢を取る人が多くなるとは思いますかね...
労働から解放されて隠居生活したいですな...
スタブとドライバなど
複数のシステムで開発が並行して進行している場合に、それぞれの開発完了時期が異なることがあるあるだと思うのですが、
・外部結合テスト（ITb：Integration Test B）
外部システムなどの接点やデータ連携が意図通りに動作するかを確認する
⇧ 上記サイト様の説明にあるような「外部結合テスト」が実施できませんと。
そこで、他の完成していない開発機能について、代替する手段として、
■ドライバ
「ドライバ」とは、テスト対象から見た上位モジュール(呼び出す側)に成り代わる、中身を持たないテスト専用のダミー部品です。
■スタブ
「スタブ」とは、テスト対象から見た下位モジュール(呼び出される側)に成り代わる中身をもたないテスト専用のダミー部品です。
⇧ という感じで、本物の機能の代わりを担うというものになりますと。
実際に「ドライバ」と「スタブ」のどちらを担うことになっているのかについては、
■ドライバ
- テスト実行時に、呼び出し元が未完成等のときに代替として使用します。
- ダミー(本物に似ているが中身はないもの)です。
- 対象のコードから見て、ドライバは上位にあたります。
- ドライバ(driver)は、運転手という意味です。
- JUnitなどのツールを使用してコードを呼び出すイメージです。
■スタブ
- テスト実行時に、呼び出し先が未完成等のときに代替として使用します。
- 値を返します。
- ダミー(本物に似ているが中身はないもの)です。
- 対象のコードから見て、スタブは下位にあたります。
- スタブ(stub)は、切り株という意味です。
- 似ている概念としてモックがあります。モックはスタブよりも上位の機能の位置づけです。
スタブ：値を返す
モック：値を返す＋α
Java JMockitを使用するサンプル
⇧ 上記サイト様の説明がイメージし易いかと。
「モック」については、
スタブと似たような概念で用いられるものに「モック」と呼ばれるものもあります。
モックはスタブと同じく、上位モジュールから下位モジュールへのテストにおいて使用されるものですが、大きな違いは「確認する対象」です。
スタブを使用する場合、上位モジュールが下位モジュールを「正しく呼び出せているか」を確認しますが、モックは上位モジュールが下位モジュールに対して「行った出力内容が正しいか」を主に確認します。
スタブは、テストを効率よく進めるためのツールという位置づけであるのに対し、モックは、テストコードの一部と表現できるかと思います。
⇧ という違いになる模様。
Javaで所定のディレクトリに存在するファイルの数だけリクエストする処理に必要な情報を整理してみる
で、外部からリクエストが送られてくる部分について、大人の事情で、本物を利用することができないので、「ドライバ」を用意する必要があるということで、Javaで実装してみようかと。
今のところ、連携されるデータの形としては、
の2種類あるということで、
という機能を想定していますと。
リクエストするデータとしては、1カ所のディレクトリに、全てのファイルが配置されている想定。
最終形は、何らかのスケジュール機能を設けて定期実行できる仕組みにする必要はありますが、一旦は、表題の機能に焦点を当てて実装に必要な情報を整理してみようと思います。
とりあえず、Java 17での開発ということなので、他システムがJava 17に対応した処理をしてくれていることを信じることにして、HTTP Cilentについては、
⇧ 上記サイト様の説明にありますように、Java 11からJavaの標準APIとしてHttp Clientの機能として「HTTPClient」というものが用意されているので、採用する方向で検討を進めてみることにしますか。
ディレクトリに存在するファイルの数だけ、という部分については、
⇧ ディレクトリやファイルの階層が複雑な場合は、上記サイト様のような方法が良いのかもしれませんが、今回は、1つのディレクトリに全てのファイルが集約されている想定なので、
⇧ 上記サイト様のように、シンプルに実装してしまう感じで良いのかなと。
CSVファイルからJSONへの変換については、CSVファイルにヘッダーが付いている前提ですが、
⇧ 上記サイト様の実装方法でいけそう。ただ、JSONの項目の値が階層構造になっていないことが前提ではありそうですが...
文字コードとかの問題とかの対応も必要そうだけど、処理に必要そうな情報がザックリとは整理できた感じですかね。
まぁ、ザックリとした情報なので、実際に実装する段階で、いろいろ問題が出てくるとは思いますが...
Java標準のAPIで実現できずに、フレームワークやライブラリ使わないと実現できない部分が出てくるってこともあり得るでしょうし...
Java標準のAPIで実現できることの切り分けがなかなか辛い...
ネット上のJavaのソースコードのサンプルとかでimport部分とか省略されていたりすると、余計に、特定に時間がかかるから、省略するのは止めて欲しいんよな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
