Devops、JUnit5、およびマイクロサービステスト：モスクワハイゼンバッグの主観的な外観

12月6〜7日に、モスクワで第5回ハイゼンバッグ会議が開催されました。

彼女のスローガンは「テスト。 テスターだけでなく！」 今回覚えているレポートの主観的なレビューを共有したいと思います。



免責事項。 もちろん、これは私の個人的な好みに基づいて選択されたレポートのほんの一部（30のうち8）です。 これらのレポートのほとんどすべてが何らかの形でJavaに関連しており、フロントエンドとモバイル開発に関する単一のレポートはありません。 いくつかの場所では、私は自分自身でスピーカーとの論争を許可します。 より完全で中立的なレビューに興味がある場合は、伝統的に主催者のブログに掲載する必要があります。 しかし、おそらく、誰かが行けなかったこれらのレポートだけを知ることは興味深いでしょう。



記事の写真は会議の公式ツイッターからのものです。

バルーク・サドグルスキー。 DevOpsがあります。 すべてのテスターを発射しましょう

（写真では、BaruchがLiquid Softwareという本を配布したときの誇大広告）



Javaに関与し、JUGRUグループの会議に参加している人は、Baruch Sadogurskyの紹介は不要です。 しかし、彼はハイゼンバグで初めて話しました。



簡単に言えば、DevOpsの主要なアイデアに関するレビューレポートでした。 ホールで「DevOpsを定義する」と尋ねられたとき、人々はまず最初に「これはこんな人だ...」



しかし、このトピックで何かをすでに学んだ人でさえ、DORA Association devops-research.comの研究について学ぶことは非常に興味深いでしょう。 そして、配信速度と品質をつなぐ曲線について（ある時点で、「より良いテスト」のための時間を必要とするため速度が低下しますが、チームが発展するにつれて、相関関係が直接になります）：







レポートのタイトルは挑発的であり、スケジュールではレポートに「燃える」というカテゴリが付けられていましたが、私の意見では、その内容はかなり主流でした。 もちろん、それはDevops変換の条件下でのテスターの解雇ではなく、テスターの仕事の性質の変化についてでした。 アランペイジとニコライアリメンコフは、1年前にこれらのことについて多くのことを話しました。 変化する役割とT字型スキルの「水平」開発の両方が、1年前のラウンドテーブル「 2018年にテスターが知っておくべきこと 」で議論されました。



「もちろん、変更したくない場合は、それほど面白くはありませんが、あなたのための仕事があります。 これまでのところ、70年代にCOBOLで記述されたシステムをサポートしたい人のための仕事があります」とBaruchは皮肉にも述べています。

アルチョム・エロシェンコ。 プロジェクトをリファクタリングする必要がありますか？ アイデアを持っている！

Artyomは、Heisenbagの参加者にアリュールレポートシステムに関するレポートをよく知っています（たとえば、2018年にサンクトペテルブルクの以前のハイゼンバグから登場したアリュール機能に関するレポートです）。 アリュール自体は、数千、数万、さらには数十万以上のテストを含むプロジェクトのコンテキストで生まれ、開発者とテスター間の相互作用を簡素化するように設計されています。 テストをチケット発行システムなどの外部リソースとリンクし、バージョン管理システムでコミットする機能を備えています。 私たちのマイクロチームでは、テスト数は数十に過ぎませんでしたが、標準的な手段に完全に対応しました。 しかし、いずれかの製品のテスト数が700に達し、全体的なタスクが顧客向けの高品質のレポートを作成することであったため、私はアリュールに目を向け始めました。



しかし、この報告はアリュールに関するものではありませんでしたが、彼に関するものでもありました。



Artyomは、IntelliJ IDEA用のプラグインの作成はシンプルで魅力的なアクティビティであると一般に確信しました。 なぜこれが必要なのですか？ 一括コード変更を自動化するため。 たとえば、多数のソースコードをJUnit4からJUnit5に変換する場合。 または、アリュール1からアリュール2の使用まで。または、カチカチ音を立てるシステムとの通信でテストのタグ付けを自動化します。



IDEAで作業する人は、コードでどのようなトリックができるかを知っています（たとえば、forループを使用してコードをJavaストリームを使用してコードに自動的に変換したり、Javaを即座にKotlinに変換したりします）。 より興味深いのは、IDEAのコード変換に対する秘密のベールがどのように開かれるかを見ることでした。私たちはこれに参加し、独自のニーズに合わせて独自のプラグインを作成するように招待されます。 次回、大きなコードベースで何かをする必要があるとき、このレポートを思い出し、IDEAプラグインを使用して自動化する方法を確認します。

キリル・メルクシェフ。 Java and Reactorプロジェクト-テストはどうですか？

このレポートは、JokerまたはJPoint Javaカンファレンスで行われた可能性があります。 Kirillは、単一のイベントログ（Kafka）を持つマイクロサービスアーキテクチャでprojectreactor.ioフレームワークを使用する方法、「リアクティブストリーム」でのコーディングの本質について少し説明しました。



人生は私たちのチームに、単一のイベントログでアーキテクチャを使用するように促しています。また、Kafkaも検討しています。 ただし、ストリーミングイベント処理については、ReactorではなくKafka Streams API（開発者にとっては、ステートフル処理のようなものが透過的に実装されているようです）で実験しています。 ただし、新しいテクノロジーでは常にそうであるように、「すくい」と「落とし穴」は事前にはわかりません。 したがって、すでにテクノロジーを使用している専門家の話を聞くことが重要でした。

レオニード・ルデンコ。 Terraformを使用したSelenoidクラスターの管理

前のレポートがJPoint会議を連想させる場合、これは確かにDevOopsに関するものです 。 Leonidは、Terraform仕様を使用してSelenoidクラスターを作成および構成する方法について説明しました。 Selenoid自体については、昨年のHeisenbug に関するレポートがありました。これは、弾力性のあるサービスとして機能し、さまざまなブラウザーで多数のSeleniumテストを実行できる豊富な分散システムです。 複数のマシンに展開する必要があるシステムと同様に、Selenoidを手動でインストールすることは困難です。 ここでは、最新のConfiguration-as-Codeシステムが役立ちます。



Leonidは、Terraformの機能のかなり詳細な概要を作成しました。これは、ほとんどの聴衆にはおそらく馴染みのないシステムですが、実際にはDevOps-automationに既によく知られています（たとえば、Devoops-2018カンファレンスでは、コードの作成と保守のベストプラクティスに関する優れたレポートがありました） Terraformで）。 さらに、Terraformスクリプトを使用して、クラスター内の各マシンのSelenoidを使用したdockerコンテナーのパラメーターと、クラスターの仮想マシンのパラメーターを記述する方法を示しました。



レオニードによって検討された特定のケースは確かにセレノイドを展開するタスクを促進することができますが、私はすべてについてスピーカーに同意しません。 基本的に、2つの異なるタスクにTerraformを使用します。リソースの作成と構成です。 そして、これは、LeonidがTerraformを一度起動して仮想マシンを作成し、各仮想マシンでもう一度dockerコンテナーを起動することを余儀なくされるという事実につながります。 私の意見では、リソースの作成の問題をうまく解決するTerraformは、構成の問題をあまりよく解決しません。 Ansibleやその他のソリューションなどの特別な構成システムを使用して、テラフォームプロジェクトの重複とそれらの繰り返し起動を回避することが可能です。



しかし、一般的に、Infrastructure as Codeの分野のテスター向けの「教育プログラム」として、このレポートは非​​常に役立ちます。

アンドレイ・マルケロフ。 グローバルSMSプラットフォームの例を使用した、TestContainersおよびJUnit 5とマイクロサービス動物園のエレガントな統合テスト

そして再びマイクロサービスについて！ 今回の会話は、同時にいくつかのサービスの起動と対話を必要とするテストを実行する方法についてでした。 拡張システムとよく知られた（そして優れた）TestContainersフレームワークを備えたJUnit5が、ソリューションの基礎として提案されました（たとえば、 Sergey Egorovによる昨年のレポートを参照）。



Javaで何かを書いているのにTestContainersが何なのかまだわからない場合は、早急に勉強することをお勧めします。 TestContainersを使用すると、Dockerテクノロジーを使用して、テストコード内で直接実際のデータベースやその他のサービスを取得し、それらをネットワーク経由で接続し、その結果、テストの直後に作成および破棄された時点で作成された環境で統合テストを実行できます。 同時に、すべてがJavaコードから直接機能し、Maven依存関係として接続し、開発者のマシン/ CIサーバーにDocker以外をインストールする必要はありません。 TestContainersを1年以上使用しています。



Andreyは、JUnit5拡張機能、カスタムアノテーション、およびTestContainersを使用して、エンドツーエンドテストのテスト環境構成をどのように規定できるかというかなり印象的な例を示しました。 たとえば、テストに注釈を書く（条件付きコード）

@Billing @Messaging
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

比較的言えば、書くことができます

 @Test void systemIsDoingRightThings(BillingService b, MessagingService m) {...}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテナ内で発生した（テスト開発者が気付かない）実際のサービスと通信できるJavaインターフェースが渡されるパラメーターに。



これらの例は非常にエレガントに見えます。 私にとって、TestContainersとJUnit 5のアクティブユーザーとして理解しやすく、比較的簡単に実装できます。



しかし、一般に、このアプローチでは、テストシステムと運用システムを構成する方法が根本的に異なるという事実に関連する大きな問題は未解決のままです。



エンドツーエンドのテスト中にシステム全体だけでなく、その構成方法もテストされた場合にのみ、すべてを壊すことを恐れずに本番環境でクイックリリースを実装できます。 開発およびテストプロセス中にシステム展開スクリプトを繰り返し実行した場合、このスクリプトが実稼働環境で起動された場合でも機能することは間違いありません。 Andreyの例でテスト環境を構成するコードの役割は、アノテーションによって実行されます。 しかし、実稼働環境では、Ansible、Kubernetesなど、まったく異なるコードを使用してシステムをレイアウトします。このようなシステムテストには一切関与しません。 そして、これは完全にエンドツーエンドではないこれらのテストを制限します。

アンドレイ・グラズコフ。 外部依存関係のあるシステムのテスト：問題、解決策、Mountebank

このレポートのトピックに関連する人のために、Andrei Solntsevによる、外部サービスに依存するシステムをテストするための原則的なアプローチに関する明るいプレゼンテーションもご覧になることを強くお勧めします。 Solntsevは、包括的なテストのために外部システムモックを使用する必要性について非常に説得力を持って語っています。 Andrei Glazkovは彼のレポートで、そのような濡れのシステムの1つであるNodeJSで書かれたMountebankについて説明しています。



サーバーとしてMountebankを解除し、ユニットテストを作成するときにインターフェイスモックを「トレーニング」する方法と同様の方法で、ネットワーク経由で要求に対する回答を「トレーニング」できます。 唯一の違いは、ネットワークサービスのモックであることです。 Mountebankを使用する好奇心をそそるケースは、それをプロキシとして使用する機能です-実際の外部システムにいくつかの要求を送信します。



ここで、Java開発者（およびAndreiがディスカッションエリアで同意した）が、Javaで作成され、埋め込みモードで実行できるWireMockライブラリ、つまり、インストールせずにテストから直接実行することをお勧めすることに注意してください開発者のマシンまたはCIサーバーにサービスを提供します（ただし、スタンドアロンサーバーとしても機能します）。 Mountebankと同様に、WireMockはプロキシモードをサポートしています。 WireMockでいくつかの肯定的な経験があります。



ただし、Mountebankの利点は、低レベルのプロトコルのサポート（WireMockはHTTPでのみ動作します）およびさまざまな技術の「動物園」で動作する機能です（Mountebankにはさまざまな言語のライブラリがあります）。

キリル・トルカチョフ。 Spring Boot Testによるテストと泣き声

また、Java、マイクロサービス、およびJUnit 5があります。Cyrilは、JoisとJPointカンファレンスのもう1人の講演者で、Javaコミュニティでよく知られ、Heisenbugで初めて講演しました。



このレポートは、昨年のSpring Curseレポートの修正版であり、JUnit5およびSpring Boot 2用に修正された例があります。コンポーネント/マイクロサービステストでSpring Bootテストを構成することに関連するさまざまな実用的な問題を詳細に調べます。 たとえば、ソースツリーの適切な場所で空の@SpringBootConfiguration StopConfiguration



を使用して構成スキャンプロセスを停止する@MockBean



と、 @SpyBean



代わりに@MockBean



と@SpyBean



を使用する可能性に@MockBean



を@SpyBean



。 CyrilとEvgeny Borisovによる他のレポートと同様に、これはSpring Frameworkの実用化の過程に戻るのが理にかなっている資料です。

アンドレイ・カルポフ。 静的アナライザーにできること、プログラマーやテスターに​​はできないこと

静的コード分析は良いことです。 継続的配信の標準によれば、それは配信パイプラインの最初のフェーズであり、コードを「読み取る」ことで検出できる問題のあるコードを除外する必要があります。 静的分析は、高速（テストの実行よりもはるかに高速）であり、安価である（テストの作成という形でチームの追加作業を必要としないため、すべてのチェックがアナライザの作成者によって既に作成されている）ため、優れています。



PVS-Studioプロジェクトの創設者の1人であるAndrey Karpov（Habrの読者はブログをよく知っています）は、PVS-Studioを使用して既知の製品のコード分析で見つかったバグの例に関するレポートを作成しました。 PVS Studio自体は多言語製品であり、C、C ++、C＃、さらに最近ではJavaをサポートしています。



上記の例は興味深く、それらの静的解析の有用性は明らかであるという事実にもかかわらず、私の意見では、Andreyのレポートには欠陥がありました。



まず、このレポートはPVS-Studio製品（スピーカーによると、「平均価格は10,000ドル」）を考慮して作成されました。 しかし、実際、多くの言語には多くの開発されたオープンソースの静的解析システムがあることに言及する価値がありました。 Javaのみで、無料のCheckstyleとSpotBugs（FindBugsの凍結プロジェクトの後継）、およびIDEとは別に実行してレポートを受信できるIntelliJ IDEAアナライザーは、非常に進歩しました。



第二に、静的分析について言えば、この方法の基本的な制限に言及する価値があると私には思えます。 誰もが大学でアルゴリズムの理論を経験しておらず、たとえば「シャットダウンの問題」に精通しているわけではありません。



そして最後に、既存のコードベースに静的解析を導入する問題はまったく発生しなかったため、プロジェクトでアナライザーを定期的に使用することができなくなりました。 たとえば、大規模なレガシープロジェクトでアナライザーを実行したところ、100,500回の変動が見つかりました。 それらをその場ですぐに修正する時間と労力はなく、コード内の何かを大幅に変更することはリスクです。 これをどうするか、静的分析を品質ゲートとして機能させる方法は？ この問題は、Andreiとのディスカッションエリアで議論されましたが、この問題はレポート自体では考慮されませんでした。



一般的に、アンドレイと彼のチームが成功することを願っています。 彼らの製品は興味深く、この分野でそのニッチを占めるというアイデアは非常に大胆です。

***

おそらく、1日目と2日目の最後の基調講演については何も言わないでしょう。どちらも、あなたが見るだけの著作権ショーでした。 それらについて話すことは、たとえばロックバンドによる演奏のように、言葉で語り直すようなものです。



1 年前のレポートでは、会議の一般的な雰囲気を伝えようとしており、ディスカッションエリア、ランチ、パーティーで何が起こっているかについて話しましたので、繰り返しません。



結論として、私は主催者に別の美しく開催された会議に感謝したいと思います。 私が理解しているように、会議への関心は期待をわずかに上回り、オーバーブッキングがあり、誰もが十分なお土産を持っていませんでした。 しかし、確かに、興味深いレポート、ディスカッションスペース、食べ物や飲み物など、誰もがもっと重要なものを持っていました。 新しい会議を楽しみにしています！