skillup

技術ブログ

プログラミング全般

DIが役に立つ場面はやはりテスト

投稿日:

システム開発において、密結合とか疎結合なんて言葉が使われたりします。

密結合・・システム間の構成要素の関連性が高く、結びつきが密なこと

疎結合・・システム間の構成要素の関連性が弱く、結びつきが疎なこと

プログラムを組む際にもなるべく疎結合状態を作るように・・・なんてことがよく言われますね。

で、この思想自体やその利点は私もよくわかっていたんですが、問題はこの思想に基づいたDIとかマイクロサービスの利点なんですよね。特に前者。

簡単なサンプルプログラムを動かしてDI自体がこういうものかというのはわかりました。

が、使いどころがわかりませんでした・・あえてこれ使わないといけない場面ってどんな時なのって思ったんですね。

が、年明けからのプロジェクトのテスト工程でこういう時に使うのか!というのがはっきりわかったのでメモしておきました。このプロジェクトに限らず今まで必要な時はずっと目の前にあったのですが私が気づかなかったんですよね。

DIが一番有効性を発揮するのはローカルと開発、ステージング、本番で何らかの外部サービスと連携をする時だと思います。

例えば、典型的なのは外部のAPIと繋げている時ですね。

と言いますか、ある程度のシステムになりますと、常に3〜5つの外部APIとつながっている事が普通でしょう。

で、この手のAPIですが、だいたいいつ、どの環境で同じURLを叩いてOKなんてケースは稀でしょう。

例えばAPIに利用制限がある(回数やIP的なもの、時間が限られるなんてこともあります)、データを動かしてしまうのでステージング以上じゃないと無理、などなど・・・

そうすると一般的なプログラムで書かれている場合(DI的な思想がなく、APIを直叩きしている場合)、ローカルでは動かないんですよね。これめちゃくちゃイライラします。

んで、今まで下記のような対策を取っておりました。

  1. ローカルでのテストができないので目視だけ(メソッド単位の単体テストだけ)
  2. ローカル時はその部分をコメントアウトする
  3. ローカルでテストする時だけ素のJSONをかく

1は対策になっていないですけどね・・・・現にローカルでは目視の確認だけになってるなんて人も多かったんですね。

2、3なんですけどこれ毎回毎回やるのものすごい大変かつ面倒臭いんですよ。

色々やっているうちに本番にローカル用の処理が入って別の不具合の原因になったり・・・・複数のAPI直さなくちゃいけないとむしろそっちの方が時間を取られるなんてケースがザラです。

先日の結合テストもそういった事が原因でテストがすげー大変だったんですね。APIの部分の修正はしなくても、APIを結局通るんで、そうなると影響する処理のローカルのテストが全部ブロックされちゃいます。

で、ふと思ったんです。

あ、API部分ラッピングして、

  • ローカル環境時は生JSONを生成
  • 開発、ステージングの時にはAPIを叩く

↑のように書けばOKじゃんって思ったんです。

もともとローカルと開発、ステージングを条件分岐で分けるようなことはしてました。これが最善策だと思ってんですが、DIすれば綺麗に解決じゃないか!ってようやくDIの使いどころがわかりました。

ようはレスポンスの型、IFは同じなんだから内部を隠してしまって見えないようにすればいいじゃん・・実クラス自体は環境設定ファイルで分けて、ローカル用とそれ以外用のクラスをまさしく注入すればって思ったんですよ。

開発やっててなんらかの思想で衝撃を受けることってなかなかないんですけどDIの使いどころがわかった時は本当に目からウロコが落ちた瞬間でした。ずっと目の前にあったのねと・・・

そういえば昨年の夏に働いてた現場では一部、外部サービスとの連携部分をマイクロサービス化してたんですね。そのせいで確かにその部分のテストが楽でした。

私が今携わっているプロジェクト自体はかなり進行しており、DI的な思想でソースを書き直すことは結局叶わなかったんですが、今後はどこかで使っていければと思います。

というか、外部サービスと接続していないサービスなんて探す方が難しいですからね。

これAPIで言いましたけど、他の部分でもローカルと他の環境でクラスの内部が変わるものだったらなんでも使えますね・・

これからはガリガリ使って楽しいDI(orマイクロサービス)ライフを送りたいと思います。

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

オブジェクト指向 クラスの設計と業務ロジックの整理

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にクラスの作り方について。 Contents1 クラス設計と業務ロジック1.1 要点1.2 感想 クラス設計と業務ロジック …

no image

テストのダミーデータ作成

データベースに大量のデータを作りたいときにいつもあああやhoge,aaaですとデータという感じがしないですし、抽出や集計ができません。 なるべく自然に近いデータが欲しいのですが、簡単に作れる方法があり …

no image

コードの抽象化

リーダブルコードも終盤に少しずつ近づいてきました。 今まではどちらかというとコードの点や線の技術に注目してきましたが、これからは面的な要素に注目していきます。 リーダブルコードでは「無関係の下位問題を …

no image

オブジェクト指向設計 柔軟なインターフェイス

オブジェクト指向シリーズ。今回はインターフェイスについて。 インターフェイスといっても、implementsを使った実装だけではなく、要はあるクラスが外部の窓口となるときに使うメソッドってことだと思う …

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …