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 実際のコーディング上のコツ1.3 感想1.4 参考文献 単一責任のクラス設計 メモ 単一責 …

no image

オブジェクト指向 データベース層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にデータベース層の考え方について。 Contents1 データべース層1.1 要点1.1.1 典型的なダメテーブル設計1.1 …

no image

命名規則について

リーダブルコードシリーズ第2段、名称について。 コードにおいては名称がとても大切で、正しい命名づけなどはなかなか難しいです。 以下に大事で重要だと思ったポイントを。 Contents1 具体的でわかり …

no image

コードの見た目について

リーダブルコード4章。コードの見た目について。 自分は結構注意されますね。多いパターンとしては空白の位置などがいい加減だったり、今はありませんが、以前はコードの末尾にスペースを空けてセミコロンをうつ変 …

no image

シェルの基礎+ユーザー切り替え関連

雑誌を見ていたらシェルの特集があったので、ちょっとメモリます。 補強したいところのみ要点をチェック。 Contents0.1 実行パスについて0.2 ビルドインコマンド0.3 シェル変数・環境変数0. …