SberTechの従業員の目を通してHeisenBug

この投稿では、Heisenbugカンファレンスの15のレポートのレビューを共有し、企業のスタンドで何が面白いかを伝え、また、テストプロジェクトのコードをすばやく変更するのに役立つIntelliJ IDEAのアクションプラグインの作成に関するArtyom Eroshenkoのレポートのビデオ資料を共有したいと思います。

HeisenBugに関する情報

ハイゼンバグ -スペシャリストをテストするための技術会議。 基本的に、テスター、テストのソフトウェア開発エンジニア、自動テストと負荷テストのスペシャリストにとって興味深いものです。 主催者はJUG.RUチームで、その背後にはJoker、HolyJS、SmartData、DevOops、DotNext、Mobiusなどの会議があります。

会場

5回目の会議は、モスクワの地下鉄キエフスカヤ駅のスラビャンスカヤラディソンホテルで開催されました。 ホテルに近づくと、会議のロゴが付いた電子バナーが見えました。 さらに、ホテルのロビーへの入り口で、参加者にはチェックインデスクとワードローブへの標識が付いていました。 迷子になることは不可能です。 参加者と講演者の登録は1階で行われ、会議のメインロビーには、パートナーのスタンド、会議室、コーヒーブレークのあるホール、ランチがありました。 警備員のレベルは満足していたので、「密輸ウサギ」は手に入れられませんでした。 合計で、イベントには約500人以上の参加者が参加し、そのほとんどが開始の2週間前に登録されました。

プログラム

プログラムはここにあります 。 JUG.RUは、余分な水や有名な外国の専門家と一緒に、プログラムを実用的にするように常に努力していることに注意したい。 レポートは次の記号に分かれています。







これがハイゼンバッグで講演者になることを初めて計画している場合は、 講演者のメモを見てください-それには非常に多くの有用な情報が含まれています。

コミュニケーションとボランティア

参加者が会議で重要な何かを見逃さないように、電報チャンネルと電報チャットが開催されました。 ちなみに、後者では、ビデオを見るボランティアを探していて、無料の会議チケットを提供しました。



ボランティアになることに決めた場合は、できるだけ早く主催者に決定を示してください。 イベントの準備は、会議のずっと前に行われます。 空席状況に応じて、チームに割り当てられます。

会社スタンド

今回のカンファレンスでは、ドイツ銀行、アルファバンク、ライファイゼン、バドゥ、ルクソフト、SKBコントゥール、ゲットなど、大規模なIT企業が12社以上集まりました。各企業は、イベントの参加者との交流の組織にアプローチしました、したがって、パフォーマンスの間に退屈する必要はありませんでした。 思い出に残る小さなお土産の問題を解決し、ビデオやボードゲームをプレイし、宝くじに参加することができました。







ライファイゼンはあらゆる種類のパズルを解くオンラインクエストを体験することを申し出ました。また、年齢のないクラシックの愛好家であれば、SegaでMortal Kombat 3をプレイできます。 アルファバンクの同僚は、タスクを備えた電報ボットを作成し、さらに宝くじで大規模なレゴマインドストームを行いました。 ライブコミュニケーションの開発者がタスクを出して議論に参加したドイツ銀行のブースを賞賛したいのですが、他のすべてのブースでは答えを確認するだけでした。







多くの企業は控えめに専門家を探し、職務内容を記載した小冊子を配っています（慈善活動に従事するためにすべて同じではありません）。

レポートの概要

1. DevOpsがあります。 すべてのテスター -Baruch Sadogurskyを解任しましょう 。



この会議は、JavaとDevopsに関連する会議で有名なスピーカーであるJFrogの開発者であるBaruch Sadogurskyによって開かれました。 レポートでは、Baruchは頻繁にリリースされるビジネスニーズ、貧弱なアーキテクチャによるコードテストの複雑さ、現代のアジャイルチームにおけるテスターの役割の近代化に起因する頻繁なリリースに直面して、ソフトウェア品質の問題に対処しました。 このレポートは、最初から最後まで多くのユーモア、興味深い事実、比較を聞くのが面白かったです。



レポートの主な考えを1つのスライドにまとめると、テストの自動化とDevOpsの実践によりルーチンプロセスの時間コストが削減され、新しいタスクの実装により多くの時間を割けるようになります。







2.プロジェクトをリファクタリングする必要がありますか？ IDEAがあります！ -アルテム・エロシェンコ。



Artemのレポートでは、テストプロジェクトのコードをすばやく変更するのに役立つIntelliJ IDEAのアクションプラグインの作成について説明しました。







彼は、プラグインアクションの入力ポイントであるメインクラス（AnAction、PsiClass、PsiAnnotation、AnActionEvent、JavaCodeStyleManager）について説明しました。



次のタスクを解決する方法を検討しました。



a）プロジェクトで自動化されているものとされていないもの。 Jiraとの自動同期。





アノテーションテキストによると、@ DisplayNameはJiraに行き、必要なチケットを受け取り、@ TmsLinkを使用して必要な接続をすべて停止しました。



b）Jiraコンテキストから@Tagsを自動的に付加します。





お気に入りの 回帰チケットには特定のラベルがあります。 テストに行き、@ TmsLinkアノテーションがあり、プラグインを使用し、新しい@Tagsアノテーションがあり、Junitの助けを借りてこれらのタグでテストを実行できます。



c）テストでは何がチェックされますか？





自動テストがあり、ステップがあり、エクスポートし、テストにステップがあります。 また、ビデオには2つのテストの例があります。



Artyomは、アリュール1からアリュール2にすばやく切り替える方法も示しました。



コードの記述プロセスの最適化を考えている人向けの非常に実用的なレポート。 プラグインのソースコードはこちらにあります 。



3. JavaおよびReactorプロジェクト？ -しかし、テストはどうですか？ -キリル・メルクシェフ。



Cyrilは、国際的な医療系スタートアップのVivyを開発した経験を共有しました。 彼は、モノリシックシステムのスケーラビリティの問題が、マイクロサービスとReactorライブラリを使用してどのように解決されたかを語った。 このライブラリ、その基本原則、リアクティブシステムのテスト方法、キラー機能（リクエストチェーン内のチェックポイントやログ、フック、リトライリクエストなど）に多くの注意が払われました。







個人的には、リアクティブシステムのテストを扱っていなかったため、私にとっては新しくて興味深いものでした。



4. JSでメモリリークを検索するためのSealantフレームワークを書いたように 、Sergey Dokuchaev。



この講演では、単一ページのWebアプリケーションでのメモリリーク（コードからはアクセスできるが不要になったオブジェクト）について説明します。 Sergeyは、製品のリリースバージョンですべての重要なメモリリークを自動的に検出するようにタスクを設定しました。 彼は、そのようなエラーを見つけることの困難さと、Google Chromeツールを使用して手動でそれを行う方法について話しました。 次に、著者であるSeaLantツールを調べました。 SeaLantは、Chrome DevToolsプロトコルを使用してChromeプロセスと対話することにより、リーク検出を自動化します。 レポートは、ページが（ページをリロードすることなく、1つのデバイスから、1つのセッションで）循環スクリプトを実行できる場合、ほとんどの場合、それらをテストすることでほとんどのメモリリークを取り除くことができるという事実で終了しました



5.インターフェイスのビジュアルテストの機能 -Geminiツール（ビジュアルテストツール）およびHermione（スクリーンショットアサーションを実行できる次世代のより汎用的なツール）の主要な開発者であるAnton Usmansky。







このレポートは、プロジェクトにビジュアルテストツールを実装することを考えている人に役立ちます。 すでにジェミニとハーマイオニーを使用している人も興味があるかもしれません-それはツールが内部にどのように配置されているかを理解します。 一部の場所では、著者はかなり基本的なことを扱っています。



6. Selenium WebDriverのトラブル -Alexey Barantsev。



Alexeyは、Seleniumプロジェクトの問題とそれらが発生した理由について話しました。 彼は、 Bazelコレクターを使用して、モノリポジトリアセンブリの詳細を共有しました。 要素の可視性のトピックに触れ（W3C WebDriver標準では、要素が可視かどうかをチェックする操作はありません）、関数getProperty、getDomAttriubute、getAttributeの違いについて説明しました。







トラブルを知ることで、ユーザーは機能をバグと区別し、テストプロジェクトで効果的な「クランチ」を開発できます。



7.ゼロから作成するためのレシピと負荷テストシステムの開発 -Anatoly Plaskovsky。



アナトリーは、Yandex.Moneyパフォーマンス研究グループを代表しています。 彼の報告書では、パフォーマンス研究の必要性を判断する方法、これらの活動を実施する人々を見つける場所、および研究プロセスを構築する方法に関する実践を共有しました。 著者は、パフォーマンスの調査！=負荷テスト、および実稼働環境でのテストのみが関連する結果を示すことができるという事実に焦点を当てています。 同時に、テストルートとデータを選択し、シナリオの可能性のある結果を監視および予測することにより、顧客に問題なく実験を行うことができます。



Anatolyは、負荷テストと、ヘルプやアドバイスを得るためのノックできる場所について説明する電報チャットロードランドを作成しました。



8.デバイスメーカーの壮大な失敗 -Valentine Wylsacom Petukhov。



最初の日は、悪名高いWylsacomの報告によって締めくくられました。これは、一般の人々にあいまいに受け入れられました（ヘイゼンバッグの参加者の電報でのチャットで判断:)）。



私自身は、デバイスとアプリケーションのベータテストに関するレポートから何も興味深いことはしませんでしたが、ファンはそれを気に入ったのかもしれません。 写真のディスカッションエリアが並んでいたので、PRは成功しました。







9. TestContainersを使用したマイクロサービス動物園と、グローバルSMSプラットフォームの例を使用したJUnit 5のエレガントな統合テスト -Andrey Markelov。



著者は、Testontainers+ Junit 5 + MockServerバンドルを使用して、会社でマイクロサービスがどのようにテストされているかを語った。 レポートは興味深いように見えましたが、そのようなスキームは多数のマイクロサービス向けではありません。 ソースコードへのリンク。







10.テスターの盗撮、または監視ユーザーがどのように役立つか -アントニーナ・キサメトディノバ。



非常に興味深いレポートですが、テストよりもWebデザインに関連しています。 クライアントインターフェイスを設計する際に避けるべきUXプラクティスと落とし穴について説明します。







Antoninaは、ボタンの無効化、ローダーの使用、ツールチップ、使い慣れたコンポーネントなどのUIソリューションでユーザーを観察する際の主なエラーを強調しました。



また、レポートのグラフィックデザインに、実際のプロジェクトからの直観的な例（UXに関するレポートに適している）を記載することも重要です。



11.外部依存関係のあるシステムのテスト：問題、解決策、Mountebank -Andrey Glazkov。



著者は、彼のプロジェクトで濡れる段階の進化について話した。 コードレベルでのモーキングの長所と短所を考慮しました。 彼は、偽のサービスの実装を作成するのが良い場合の経験を共有しました。 しかし、偽のサービスをその場で再構築し、プロキシし、同時に着信要求のログを入力したい場合、AndreyはMountebankツールを詳しく調べることをお勧めします。







主な利点：

• mounteBank-TCPレベルで動作します。
• JavaScriptインジェクション。
• 信頼性とすぐに使える速度。
• 優れたドキュメント。
• Dockerコンテナ化のサポート。

特定されたツールの制限：

• データストレージを備えた外部システム。
• WebSocket-サポートされていません。
• ロードテスト（> 150 rps）が、バランサーを使用できます。

12.モバイルアプリケーションのエンドツーエンドテストのプロファイルを作成する理由 -Vyacheslav Frolov。



Vyacheslavは、Badooでの自動テストのステータス、つまり1つのシミュレータで30マシン時間かかるモバイル1,500テストの並列化の問題をどのように解決したかについて報告しました。 その結果、30分の結果を達成することができたため、1日あたり8万件のテストを実行できました。 消費電力の直線的な増加に加えて、シミュレータを再起動する代わりに最適化を適用して、アプリケーションキャッシュをクリアしました。 プロファイラーもレポートで言及されており、テストでのボトルネックの特殊なケースを検出するためにどのように使用されましたか。たとえば、ios 11.0のlong_press（）メソッドは5秒間実行され、最適化後すぐに実行が開始されました。 -alive "接続の再確立を回避できるため、すべてのテストを一度に大幅に高速化できます。 著者はまた、FlameGraphおよびFlameChartツールを使用してプロファイラーの結果を表示する方法を話しました。







13.ユニットテスト：理論から実践まで -Vadim Pushtaev。



著者は、UnitTestsの開発経験を共有しています。 レポートは3つの部分で構成されていました。

1. UTから何を望むか→回帰（コードの変更、チェック）、アーキテクチャへの影響（開発者がテストを書くとコードが良くなる）、理解（レガシーコードを処理する）;
2. 原則→ヴァディムは、理論は実践ほど良くないことを想起します。 実装には多くのロジックが存在する可能性があるため、「実装ではなくインターフェイスをテストする」という原則を拒否しました。 さらに、「単体テストはテストメカニズムではありません」という原則があります。 彼は、これを強力で非常に便利な一種のアーキテクチャー手法と考えていますが、これはコードのチェックと正確性のためのメカニズムではありません。
3. 実装→作成者が作業で使用する手法に関するストーリー（クラスごとに1つのテストクラス、独自のマッチャーの作成、必要に応じて外部依存関係の使用など）。

14.スプリングブートテストでのテストと泣き声 -Kirill Tolkachev



Cyrilは、私たちをIoC、DI、Springの世界に戻し、JUnit 5とSpringBootを使用して単体テストとコンポーネントテストを作成する方法を説明することにしました。







このレポートの大きな利点は、スピーカーがほとんどのテストをリアルタイムで書いたことです。 Springアノテーションでテストをラッピングする段階的なプロセスを明確に示しました。 しかし、大量のコードがあるため、示されているすべてのテクニックを頭に入れることは困難でした。 Cyrilは、プロファイル、Mock＆Spy Beanの操作、およびコンテキスト構成の設定に関するSpring機能を調べました。 私にとっては、Springはそのようなタスクのためのかなり重いフレームワークであり、経験豊富なユーザーだけが単体テストを開発するときに熊手を踏むことはできません。



15.モバイルオートテスト -Ekaterina Bateevaを利用しています。



レポートでは、著者はiOSアプリケーションを自動化するためのXCTestツールを検討しました。 このツールを他のプロジェクトに複製するのは不便でした。







つまり、次の欠点が特定されました。

• 起動設定を読みにくい。
• アセンブリの構成が難しい。
• さまざまなサービスとの統合が困難。
• スクリーンショットを管理するには不便です。
• テストの再起動を設定するには不便です。

次に、キャサリンは問題を解決したオープンソースのFastlaneフレームワークについて話しました。

まとめ

一般的に、私は会議が好きだった。 関心のある質問に対する感情と回答を受け取った。 BoFセッションでは、ほとんどの参加者が「仮面」を脱ぎ、BoFトピックの枠組み内で活発な議論を交わしました。 コーヒーブレイクとディナーは完璧で、いつも何か食べるものがありました。 また、イベントの構成に注意したいです-JUG.RUチームは、毎回、ハイゼンバグをますます良くしています。 最後に-会議に参加して、得た知識を共有し、スキルを向上させてください！



PS：記事の準備に参加してくれたAlexei Rumyantsevと、ビデオ素材のArtem Eroshenkoに感謝します。