2014年11月18日に公開された、Testing Strategies in a Microservice Architectureを読んでみました。Microservicesに対するテスト戦略に関する大まかな方針を書いています。想像した通りだったのですが、理解しやすく、例も記載しているので取り組む人はいったん読んでおいたほうが良さそうです。

• http://martinfowler.com/articles/microservice-testing/

目次

Some Definitions

1. What is a microservice ?
2. Anatomy: a loook inside a microservice
3. Architecture: choreographing service

then the Testing Strategies…

1. Unit: mockist vs classic
2. Integration: datastores and eternal services
3. Component: in or our of process ?
4. Contract: ensureing consistency across boundaries
5. End-to-end: tips and tricks

the some Conclusions

1. Options: testing benefits of microservices
2. Test Pyramid: how many tests?
3. Summary: wrapping thing up

内容

以下、内容ですがいくつかピックアップする程度です。例もあるのと、ざっと読めば時間もかからないので読んでみることをお勧めします。

A microservice architecture builds software as suites of collaborating services.

• microservicesは、いくつかのサービスの集合体
  • マイクロサービスは、REST over HTTPを使って統合されることが多い
  • 統合には、軽量なメッセージプロトコル、Pub/Subモデル、ProtobufやThriftのような通信が用いられる
• Microsrvicesは、大抵は類似のモジュールを分割することができる
• Microservicesは、ネットワーク上のデータストアなどに外部接続する
• マルチサービスは、1つのシステムとして一緒に動作する

テストの話

実施されるテストを、テスト対象が小さなものから区分しています。

Unit testing

A unit test exercises the smallest piece of testable software in the application to determine whether it behaves as expected.

ポイント: テストするモジュールの関係性をテストするか、モジュール自体をテストするか

• Sociable unit testing
  • モジュールの状態を得ることで、モジュールの振る舞い(Behaviour)をテストする
  • モジュールのインタフェースを通してテストする、ブラックボックステスト
• Solitary unit testing
  • オブジェクト間の関係性や依存関係をテストする
  • テストダブル(test dubles)

Integration Testing

An integration test verifies the communication paths and interactions between components to detect interface defects.

• Integration tests
  • いくつかのモジュールを集めたサブシステムをテストする
  • コミュニケーションパスなんかを確認する
  • サブシステム全体ではなく、テスト対象で閉じた範囲でのテストが目的
• Whilst tests
  • レイヤー間のやりとりや、外部コンポーネントとのやりとりを検証するためのテスト
  • 外部コンポーネントとは、他のマイクロサービスであったり、データストア、キャッシュなど

データストアとの結合や、外部コンポーネントとの統合におけるフィードバックを素早く得ることが目的。

Component Testing

A component test limits the scope of the exercised software to a portion of the system under test, manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components.

• Componentに閉じたテスト
  • 単一のコンポーネントにスコープを限定することで、テストの保守や実施を素早くする
    • BroadStackTest
  • テストダブルを使うことで、複雑な振る舞いを抑えたテストが実施できる
  • 異常系の再現だったりを作り出してテストできる
  • microservicesでは、
    • テストダブルで外部コンポーネントを置き換え、internal APIのエンドポイントを確認するとか
  • オプションとして考慮するところ
    • ネットワークや、メモリなどをどこまで考慮するかは考える必要がある

Internal resources are useful for more than just testing…

• テスティングの側面として、監視、運用、デバッグなどに役立つ
• health checkやPingは負荷分散なんかに役立つ

Contract testing

An integration contract test is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service.

• 外部との依存関係に注目したテスト
• データ構造の入出力、副作用、パフォーマンスや平行性を見たりする
• microservicesでは、public APIをインタフェースとしてテストされる
• component testsは、サービスの振る舞い(behaviour)を深くみるのではなく、入出力のレイテンシーやスループットが許容範囲内かをみる程度、なのが異なることろ

End-to-end testing

An end-to-end test verifies that a system meets external requirements and achieves its goals, testing the entire system, from end to end.

• システム全体のテスト
• システム全体がビジネスゴールを満足するかを検証する
• ブラックボックステスト
  • GUIsや、サービスAPIがPublicインタフェースとして検証される

Writing and maintaing end-to-end tests can be very difficult

end-to-endテストのガイドライン

1. Write as few end-to-end tests as possible
2. Focus on personas and user journeys
3. Choose your ends wisely
4. Rely on infrastrucrure-as-code for repeatability
5. Make tests data-independent

Microservice architecrures provide more options for where and how to test

境界を定義することで、システムにおけるコンポーネントを見やすく、独立して扱いやすくする

The test pyramid helps us to maintain a balance between the different types of test

Unit => Integration => Component => End-to-end => Exploratory

Conclusion

http://martinfowler.com/articles/microservice-testing/#conclusion-summary