腰部脊柱管狭窄症の再発

2週間ほど前から腰部脊柱管狭窄症が再発した感じとなりました。急性心筋梗塞後は、ずっとエアロバイク中心の運動をしていたのですが、今年の6月からは天気がよい日はウォーキングをして、雨の日に自宅でエアロバイクをしていました。

脊柱管狭窄症が再発したので、今はエアロバイクだけです（エアロバイクは、初めて脊柱管狭窄症を発症した頃に運動不足を解消するために購入したものですが、その後は、心臓リハビリテーションとしての目的でも使っています）。

初めて発症した2018年6月から2019年4月頃までは、かなり辛かった時期もあったのですが、薬だけで改善しました。今回も、今は薬で様子見となっています。

前回は六本木まで通勤している頃で、通勤がかなり辛かったという記憶があります（「通勤電車の書斎化（2）」）。幸い、今はフルリモートで在宅勤務なので、通勤しなくてよいのが助かります。12月から新たに働く会社もフルリモートで働きます。

E2Eテスト vs E2Eテスト

私が「WEB+DB PRESS, Vol.134」の特集1「実践API設計」の中で使っている用語「E2Eテスト」は、一般的な書籍で述べられているE2Eテストとは若干異なります。

どのように違うのかをウェブサービスのバックエンドのサービスで説明します。新たに図を起こすのが面倒なので、すでにある記事「マイクロサービスの開発とテストファースト／テスト駆動開発」からそのまま引用します。

この図では、「加盟店管理用APIマイクロサービス」が複数のマイクロサービスに依存しています。

一般的なE2Eテストとは

一般的な書籍では、テストピラミッドにおける頂点にあるE2E（End-To-End）テストは、「加盟店管理用APIマイクロサービス」およびそれが依存するすべてのマイクロサービスを何らかの環境（たとえば、Docker、あるいは開発用のクラウド環境）にデプロイして「加盟店管理用APIマイクロサービス」をテストすることを指すものが多いです。

テストピラミッドの例

このテストピラミッドでは、「統合テスト」は、依存しているサービスへの呼び出し部分をモックで置き換えてサービス単体でテストすることを指すことが多いです。したがって、依存しているサービスへの呼び出しを、テスト時だけモックで置き換えられるような仕組みを埋め込む必要があります。つまり、本番環境で動作するコードの動作を確認しているわけではありません。

たとえば、実際に本番環境（もしくは開発用環境）で依存するサービスを呼び出したら、呼び出しコードに間違いがあり、モックとは異なる動作をしたり、正しく動作しなかったりする可能性があります。

そのため、統合テストの次の上の段階で行いたいのは、テスト対象のサービスの実行ファイル（本番環境にデプロイするバイナリ形式）で実際に実行して、そのAPIのエンドポイントを外部から呼び出すテストを行うことになります。

この時に、依存するサービスをどうするのかという問題に直面することになります。その結果、一般的な書籍で述べられている「E2Eテスト」ということになります。しかし、それは他の依存するサービスも動作させないといけないし、それらのサービスが動作するためのデータベースの設定が必要かもしれなく、設定が非常に面倒になります。

その結果、一般的な書籍では、E2Eテストは構築が難しいくテスト時間も要するので、単体テストや統合テストを強く勧めています。

私が定義しているE2Eテストとは

私がマイクロサービスの開発とテストファースト／テスト駆動開発」や「WEB+DB PRESS, Vol.134」の特集1「実践API設計」で述べているE2Eテストは、テスト対象のサービスの実行ファイル（本番環境にデプロイするバイナリ形式）で実際に実行して、そのAPIのエンドポイントを外部から呼び出すテストを行うのですが、以下の点が異なります。

• 本物の依存するサービスは使わない
• 開発者の開発PC（たとえば、MacBook Pro）上でローカルにテストが実行できる

Go言語で開発している場合、コンパイルも速いので、開発しているサービスだけを自分の開発PCで素早く開発・テストを行えます。どのように実現しているのかは、記事を参考にしてください。

必要に迫られて開発した方法

2018年6月にメルペイに入社して、本格的にウェブサービスのバックエンドサービスの開発に従事するようになって担当したのが、上の図にある「加盟店管理用APIマイクロサービス」です。

当時は、ほぼすべてのマイクロサービスが同時に開発されており、私が担当するマイクロサービスが依存するマイクロサービスも開発中という状態でした。それで考え出したE2Eテストです。

考え出した背景は、次の通りです。

• 自分が開発を担当するマイクロサービスの開発・テストが終わったと責任を持って言えるようにするにはどうすればよいか
• マイクロサービスが定義しているAPIの仕様に書かれている動作をすべて自動テストで確認してから、フロントエンドの担当者に、マイクロサービスの開発が終わっているので使ってくださいと言いたい

私が定義しているE2Eテスト用のテストフレームワークは、メルペイやカウシェで「E2Eテストフレームワーク」として整備されており、サービスの開発に用いられています。メルペイでは、一般的な書籍でのE2Eテストは、「シナリオテスト」と呼ばれていて、別途整備されていました。

2019年12月14日に開催されたGDG DevFest Tokyo 2019で最初の発表を行っています。

〓GDG DevFest Tokyo 2019 ご登壇者紹介〓
Main Sessionにて柴田 芳樹さんにご講演いただきます。『マイクロサービスの開発とテストファースト/テスト駆動開発』と題して、merpayのバックエンドエンジニアとしてどのような手順で開発し工夫をしているのかなど紹介いただきます。 #DevFest19 #gdgtokyo pic.twitter.com/IZG1rglNCT

— GDG Tokyo (@gdgtokyo) November 16, 2019

株式会社カウシェを退職します

2022年10月1日から働き始めた株式会社カウシェを11月30日付けで退職します。1984年4月1日に社会人として富士ゼロックス（現在は、富士フイルムビジネスイノベーション）で働き始めてから8社目の会社でした。12月からの予定は、未定です。

雑誌記事・翻訳・講演・技術教育

この一年間の成果は次の通りです。

WEB+DB PRESS Vol.134

• 出版社/メーカー: 技術評論社
• 発売日: 2023/04/22
• メディア: Kindle版

メルペイとカウシェの2社で私自身が推進してきた開発手法を特集1「実践API設計」で解説しています。一年前にカウシェに入社した時点では、gRPCに基づくバックエンドサービスのAPI仕様は全く記述されていませんでした。現在は、この一年間で新規に追加されたエンドポイントでAPI仕様が記述されているだけでなく、過去の技術的負債もかなり返済され、E2Eテストも整備されている状態になっています。

雑誌の記事としては、16年振りの執筆でした。その前は「Systems Engineer Vol.1」（技術評論社、2007年4月）で書いた3本の記事が最後でした。

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ

• 出版社/メーカー: インプレス
• 発売日: 2023/08/18
• メディア: Kindle版

私にとっては21冊目となる技術書の翻訳本です。Go言語で開発するエンジニアは、「プログラミング言語Go」に加えて、必ず読んでもらいたい本です。

Developer eXperience Day 2023

「45年の歴史から振り返る、ソフトウェア開発とキャリアの変遷」と題して、私自身のソフトウェア開発とキャリアの変遷を話しました。この講演の内容は、logmiTechで紹介されています。

https://logmi.jp/tech/articles/329156

https://logmi.jp/tech/articles/329157

https://logmi.jp/tech/articles/329158

技術教育

この一年間で個人として行った技術教育は、リクルート社向けの『Effective Java 第3版』研修だけでした。

今後

今月で64歳になります。2020年6月20日に急性心筋梗塞で昭和大学藤が丘病院の救命救急センターへ搬送され、緊急手術を受けました。幸い、心筋の壊死の範囲も狭く、現在も元気に生活できています。

12月から新たな会社で働くのか、あるいは、働かないで過ごすのかはまだ未定です。一方で、私にとって6冊目となる書籍を執筆しているので、しばらくは、その執筆に専念するかもしれません。