Laravelのテストコードを書いたらDIが少し見えてきた話【株式会社ライトコード】

※弊社エンジニアの記事になります。

はじめに

こんにちは！

今年の10月にライトコードに入社したあらいと申します。

皆さん、DIについてしっかり理解していますでしょうか。

私個人的なDIの使用経験としては、過去にJava(Spring Boot)を使用していた現場でのものです。そこでは、お作法のようにDIをコンストラクタに記述したり、テスト時にモックを用いたりしていたため、DIの深いメリットや、それを使用しないことのデメリットを深く考えることなく利用していました。また、DIではないコードによる具体的な困難を経験したことがなかったため、DIに対する理解は曖昧なものでした。

ライトコードに入社してからは、初めてLaravelを用いた開発に携わる機会があり、特にテストが不十分な機能のテストコードの実装に取り組む機会がありました。

その際に「あれ、これテスト書きにくいな...」と思った事があり、そこでDIを使ってみたところ、テストが格段にやりやすくなることに気づきました。

この経験を通じて、DIのメリットが少しずつ見えてきました。

本記事では、DIのメリットを実感するまでの過程や、その経験についてお話ししていきたいと思います。

DIとは？

今回の対応にあたり、DI（依存性注入）の理解を深めるために勉強しました。そこで得た知識を、簡単に解説できればと思います。

DIを一言で表すなら「疎結合を目的としたデザインパターン」のことです。

疎結合とは、コードの各部分が互いに独立していて、他の部分への依存が少ない状態を指します。DIでは、オブジェクトの依存関係をコードの外部から供給することで、この疎結合を実現しています。

「依存性の注入」という用語は、一見抽象的で理解しにくいかもしれませんが、実際には「依存しているオブジェクトを外部から供給する」と考えていただければ少しわかりやすいかと思います。

DIの概要について触れたところで、次に今回対応を行うことになった機能の現状のサンプルコードを見ていきます。

現状のコード

具体的な業務コードを示すことはできませんが、代わりにGoogle Cloud Storage（GCS）へのアップロード処理を例に挙げます。この処理では、データベースからデータを取得し、それを加工した後にGCSにアップロードするといったものです。

<?php
 
namespace App\Console\Commands;
 
use Illuminate\Console\Command;
use Google\Cloud\Storage\StorageClient;
 
class XxxxFileCommand extends Command
{
    protected $signature = 'file:xxxx';
    protected $description = 'Process and upload a file to Google Cloud Storage';
 
    public function __construct()
    {
        parent::__construct();
    }
 
    public function handle()
    {
        // GCSのStorageClientをインスタンス化
        $storageClient = new StorageClient();
 
        // バケットを取得
        $bucket = $storageClient->bucket('your-bucket-name');
 
　　　　　　　　// DBからデータを取得する処理
        // 省略...
 
        // アップロード対象のファイルの加工処理
        $processedFile = 'processedFile' // 仮
 
        // ファイルをGCSにアップロード
        $bucket->upload(
            fopen($processedFile, 'r'),
            [
                'name' => 'output_file_name'
            ]
        );
 
        $this->info('File has been processed and uploaded to Google Cloud Storage.');
    }
}