真空での球状試験：現状のまま、あるべき姿、あるべき姿

テストは、私たち一人一人の仕事において特別な場所を持っています。 これは非常に重要で複雑なものであり、最も楽しいものではなく、私たちの仕事の最後まで過小評価され、過小評価されている部分です。 したがって、私は小規模なスタートアップの実践的な開発者および技術マネージャーとして、この分野の専門家と話をして、彼に苦痛な質問をする機会を得てうれしく思いました。 プログラマーがTDDで作業しないのはなぜですか？ データベースを操作するシステムの単体テストに関連する問題を解決するにはどうすればよいですか？ 「ヒューマンファクター」を取り除き、最終的にユーザーインターフェイステストを自動化する方法







Joker 2016の準備の一環として、 レガシーに関する投稿がリリースされたため、Javaでのテストの議論が白熱し、ニコライアリメンコフとのインタビューを続けることにしました。



Nikolayは、12年の経験を持つJava開発スペシャリストです。 彼の主な仕事活動に加えて、彼はXPインジェクショントレーニングセンターの共同設立者およびトレーナーであり、国際会議の積極的な参加者および講演者です。 彼の参加により、IT会議Selenium Camp、JEEConf、XP Days Ukraine、IT Brunchが開催されました。 ここで、そして今、私たちのチームのテストの分野で何を改善できるか、そして将来どのような技術的変化に備えるべきかについて話しました。



-ニコライ、私の最初の質問は、内部でアサーションを使用する自己テストコードについてです。 この実践に対するあなたの態度。



-この考えは明らかに間違っていたようです。 このようなチェックがテストに取って代わり、コードを自己検証できると想定されていましたが、残念ながら、一緒に成長することはありませんでした。 その理由は非常に単純です。このアイデアは、コードを記述するときに、開発者が実装と発生する可能性のある副作用の両方について考えるという事実に依存しています。 しかし、開発者はその場でコンテキストを切り替えるのがあまり得意ではありません。 代わりに、単体テストでは、最初にテストに集中し、次に開発に集中するように強制します。



アセットはテストではなく、ランタイムチェックで置き換えられます。たとえば、何かがnullの場合、例外が必要です。 ただし、アサーションは実行に必須ではありません。アサーションをオフにすると、チェックは実行されません。 今、あなたはより良いことを可能にする他の多くのアプローチがあります。 たとえば、メソッドまたは変数の入力パラメーターにNotNull注釈を付けることができる注釈付きのアプローチ。 そして、この注釈は、例外をチェックしてスローするハンドラーに入れることができます。 現在、非常にうまく機能する特別な検証フレームワークがあります。



しかし、私には、アサーションは登場するとすぐに死んだようです。 私は非常に多くの会社で多くのコードを見ましたが、それらが真剣に使用されている会社は見ませんでした。 ここでは、1つではありません。



-理論的には、誰もがテスト駆動開発がすばらしいことを理解しています。 しかし実際には、すべてのコードが単体テストによってブロックされるわけではありません。 あなたの意見では、開発者の怠に加えて、なぜこれが起こるのですか？



-そして、これは開発者の怠inessではありません。 私の意見では、これには2つの理由があります。



最初は、人々はこれを行う方法を知らないということです。 TDDで開発するには、準備が必要です。 それだけでなく、ツール、その使用方法、およびその利点を理解する必要があります。 コースを受講するか、TDDを学習するか、すでにTDDに取り組んでいるリテラシーのある人物と一緒に仕事をする人は、働くことで多くの利点を感じます。



そして2番目の理由は、多くの開発者、特に自尊心の高い開発者が「アーキテクトモードを有効にする」ことです。 これは、人がパズルを片目で見て言ったときです。「わかりました。それで終わりです。 ここに工場があり、ここにそのようなパターンがあります-ここにそのようなものがあります。」 そして、彼はすぐにこれらの考えをコードにこぼします。 次に、彼が「設計」したすべてのものを残りのコードと統合する必要があります。 そして、統合されないことが明らかになります。 または誰かがコードレビューコードを見て、すべてのメソッドが巨大であることが明らかになり、何も明確ではない、ifの5番目のネスト。 「Hello、world！」の場合、誰もが例を見たはずです。デザインパターンの助けを借りて、「Hello、world！」が目の前にあることを理解できないように描くことができます。



TDDで作業するときは、テストを作成しましたが、今では、タスクを機能させるだけです。 あなたの仕事は、スーパークラスの設計をすることではありません。 スーパークラス設計を作成するタスクは、コードが機能した後に発生します。 それからあなたは彼を見て言った：「それで私は簡単な解決策を書いた。 そして、どういうわけかそれをより美しくすることができますか？ なんとなくエレガントにできますか？ または、再利用可能ですか？」 うまく機能します。さらに先に進みましょう。 つまり、ここに理由があります。「アーキテクトモード」とテストを記述できないこと、および適切なツールを使用できないことです。



-まあ、すべて同じように、ここでのポイントは、テストを書くことができないだけでなく、テストコードを書くことができないことでもあるように思えます。 テスト可能なコードの作成に伴う問題。



-そして、あなたはそれを書く必要はありません。 TDDで作業する場合、テスト不可能なコードを記述する機会がないため、テスト可能なコードを記述する必要はありません。 なんて冗談でしょう！



-うーん！ うん！ シンプルなアイデア、あなたは何も言わないでしょう！



-テストが便利になるように最初にコードをどのように表示すべきかをテストで描いたとき、テストされたコードを確実に取得できます。テストされたコードは美しくテストでき、うまく統合され、クールなAPIがあります しかし、実際にテストを実施することに決めた場合、もちろん、テスト容易性は非常に大きな役割を果たします。



最初にいくつかのコードを作成し、それから次のように言った場合、「さて、最初のユニットテストを作成します」と言うと、「ギャグ」がしばしば発生します。 さて、ここに古典的な例があります-メソッドで3つのブールパラメータを作成したとき。 そして、それらを渡します：foo（true、false、true）。 そして、あなた自身がそれを見て、言う：「ああ、それは何についてですか？ 何も理解できません！」または、たとえば、1つのメソッドを呼び出すには、多くのセットアップを行う必要があるため、このテストを作成する理由をすでに忘れています。 これは、事後テストを作成するときに起こることです。



そして、TDDで作業している場合、次のようになります。あなたが書いて、テストを書いて、最後に見てください。 それがどのように見えるか、あるべき姿です！」そして、API全体を素早く生成しました。 なぜなら、Java開発について話しているのであれば、テストからIDEを使用して多くのものが生成され、手作業で書く必要がないからです。 その結果、TDDで作業する人は、この要因のために少し速くなります。 彼は、単一のメソッドシグネチャ、単一のコンストラクタ、単一のフィールドを手で書いていません。 これはすべて生成されます。 さらにメガバイト。 TDDで作業する人が書くのは、メソッドの実装だけです。 IDEは、クラス、コンストラクター、ゲッター、セッター、メソッド宣言の作成を処理します。これは非常に役立ち、膨大な時間を節約します。



-しかし、それでもテストでは、コードの実装に介入する必要がある場合があります。 例えば、私はプライベートにしたいのですが、それを開かなければなりません。



-いいえ、開く必要はありません。 ここで、方法がわからないものに戻ります。 内部で何かをテストし、プライベートで閉じている場合、テストしているクラスの責任が多すぎることを意味するためです。 そしてこれは、良い方法でデザインを少し変更し、テストしたいコードの側面を別のクラスに入れなければならないことを意味します。そのタスクはまさに​​それを行います。 経験豊富な開発者は、彼のデザインが複雑になりすぎていることを示唆しています。 もちろん、すべてを詰め込む1つのクラスを作成できます。 また、ベースを印刷して保存し、JSONに変換して、いくつかのアルゴリズムを計算できるようになります。 そして、結果は過度に複雑なソリューションです。 チームで作業が完了すると、そのようなコードを修正するのは非常に困難になります。誰もがこのコードに乗り込み、とにかく変更するからです。 そして、ここに手がかりがあります。 あなたが見て、言ったなら：「どうやってこれをテストするの？ 開ける必要があります」-それだけです。デザインを変更する必要があるということです。



-おもしろい。 わかった それでは、データベースを使用するテストの必要性などについて話しましょう。 アクセス可能なデータベースを常に持ち、接続を構成し、データベースに依存する単体テストを実行する必要があるため、私たちは地獄になりつつあります。 正直に言うと、アセンブリスクリプトでそれらを無効にします。 どうする どこかでmoki JDBCデータソースを記述しようとしました-非常に困難です。



-実際、私は非常に多くの時間が経過したことに驚いていますが、それでもそのような疑問が生じます。 これは、私がそれを伝えることができる場所ではないことを意味する、と私は報告した。



私はずっと前にこの問題について話し始めました。「データベース関連コードのTDD、どうすれば可能ですか？」というレポートがあります。これはいくつかの大規模な会議で話しました。 こことここにビデオがあり、 ここにライフコーディングモードでこれを行う方法、データベースの接続方法、このデータベースをテストで使用する方法を示すプレゼンテーションがあります。



まず、JDBC APIをダンクしないでください。 JDBC APIでmokiを作成する場合、何をテストするのでしょうか？ データ統合が正常に機能することをテストするのではなく、ある程度正確に定式化されたSQLクエリを送信したことをテストします。 ただし、SQLでは、クエリを簡単に再構築して、見た目を変えることができますが、本質的には同じです。 たとえば、それらの間でAND部分を再配置します。 WHERE "user" = 'Vasya' AND "role" = 'admin'、またはその逆。 そのような要求に対してmokiを実行した場合、機能的には何も変更しなかったこのような変更を加えた場合、何もテストしません。 したがって、統合テストをデータベースに書き込む必要があると考えられています。これにより、実際のコンテキストが上がり、実際のデータベースが上がり、作業が行われます。



-しかし、実際のベースでの作業は非常に遅いです！



-ここで、インメモリデータベースが役立ちます。 古き良きHSQLDB、つまりH2があります。これは、たとえばその最新バージョンです。 H2はメモリ内データベースとして上昇するだけでなく、さまざまなデータベースをサポートする構文モードでも機能します。 つまり、次のように言うことができます。「H2、起きて、MySQL構文で作業してください。 H2、Oracle構文で起動して実行します。 100％互換性はありませんが、それでもほとんどの問題を解決します。



さらに、多くの記事がすでに書かれています。どれくらいの速さ-正確に速い！ -RAMディスクを使用してベースを上げます。 つまり、ディスクサブシステムにマップするのではなく、RAMディスクを作成してRAMにマップします。 結局のところ、単体テストを作成するために、実稼働環境からダンプを10ギガバイト増やす必要はありませんか？ 特定のパフォーマンスシナリオを推進するつもりはありません。 通常の単体テストを作成します。これは、少数のレコードで作業のロジックをテストする必要があります。



そして最後に、これの別のヘルパーはDbUnitです。 DbUnit。テストデータセットを非常に簡単に操作し、それらを非常に便利にし、XMLで、JSONで、便利に作成します。 しかし、最善の方法は、これらのタスクをXMLで処理することです。これが、構造化データを取得する方法だからです。 この場合、特定のテストに焦点を当てたデータセットを簡単に作成できます。 つまり、たとえば、検索が機能することを確認する必要がある場合、探しているものの多様性を示す5〜10個のエントリを挿入し、これらの10個のエントリのみに注目します。 さらに、必要な列のみを挿入します。



相互接続されたデータがある状況について話している場合、オンザフライ制約を無効にするなどのトリックがここで機能します。 つまり、たとえば、Connectionを開き、「すべての定数の検証を無効にしてください」と言います。 それはデータベースに依存します：どこかでのみグローバルに実行でき、どこかで接続のフレームワーク内で実行できます。 定数をオフにします。これにより、たとえばユーザーを探している場合、ユーザーに必要な追加データに気を取られたり、挿入されたりすることがなくなります。



別のトリックは、トランザクションでテストを実行する機能です。 これは、トランザクションデータのテストで挿入され、同じトランザクションで、このデータを受信するために必要な要求が行われ、最終的にロールバックされることを意味します。 このアプローチですべてのテストを作成できるわけではないことは明らかです。 これは、データを受信するテストで特にうまく機能します。 データを挿入するテストの場合、これは常に良いとは限りません。 定数がどのように機能するか、例外が正しくスローされたかどうか、正しくインターセプトされたかどうか、ラップされたかどうかなどを見るのは興味深いのはそこだけだからです。



私がリストしたのは唯一の解決策ではありません。 それは、すべてのものに知られているもの、長い間知られているものです。 彼らは、この機能を拡張し、より便利にし、データベースのテストを快適にする新しいソリューションを作成しています。



-長い間、ユーザーインターフェイスのテストの自動化は非常に複雑で信頼性の低いものであり、自動化されたスクリプトを記述するよりも、漠然と言い表されたテストシナリオで作業している人々に信頼する方が良いと感じていました。終わらせる。



-さて、あなたは無駄です。近年、膨大な数のツールとアプローチがありました。 Webインターフェースについて話すと、確かに昔々、ブラウザを一周し、さまざまなハックを考案し、JavaScriptを介してページ自体に何かを「プル」する方法を発明しました。 しかし、特定の基準があるため、すべてがはるかに簡単になりました。 Webアプリケーションのツールについて話している場合、これはWebDriverであり、そのサポートは現在ブラウザー自体とは異なります。ブラウザー自体は既にWebDriver実装を内部に挿入しているため、ブラウザーをリモートで制御できます。 そして、テストからブラウザを完全に制御し、通常のユーザーと同じようにブラウザで何でもできることがわかりました。 ブラウザから情報を受け取ることができ、すべてのログ、内部処理、外部環境との通信を引き出すことができます。



同様に、モバイルアプリケーションのテストは非常に拡大しています。 実際のデバイスとエミュレーターの両方を操作するためのオプションが増えていますが、これらにも独自のフレームワークがあり、APIテストで簡単に記述できます。



実際のデバイスに関して、現在活発に開発されている分野の1つはロボットテストです。 電話が挿入されている3Dプリンターでミニロボットが印刷され、それらがプログラム可能である場合。 つまり、マイクロコントローラーがあり、このマイクロコントローラーにコマンドを送信することでプログラムできます。 したがって、ロボットには、機械的な指のように、端に輪ゴムが付いた羽があります。 デバイスを特定の位置に配置すると、すべてが簡単に機能します。



「画面に表示されているものをどのように読みますか？」



-電話の接続により画面に表示されるもの。 画面の内容を読むことができ、それに応じていくつかのアクションを実行します。 すべてに適しているわけではないことは明らかですが、一部のアプリケーションでの作業は自動化が非常に簡単です。 このアプローチは現在活発に開発されています。 この分野のテスターに​​代わる生産ソリューションはありません。 しかし、それにもかかわらず、ますます人気が高まっています。



-素晴らしい！ しかし、もちろん、私たちのチームはまだ遠いです。



-お願い：現在、テスト用のクラウドソーシングは開発を続けています。アプリケーションを大規模なプラットフォームに送信すると、多くの専門家（中国人、インド人、私たちの同胞）が働いています。 半自動モードで好きなようにテストをスケーリングできます。それを呼び出しましょう。



-これらの人々はテストケースを取得しますか？



-テストスクリプトを受け取り、それがどのように機能するかの説明を含むアプリケーションを受け取り、テストを実施します。 これは興味深い機会であり、多くの人がテスターのチームを浮かばせずに苦しんでいますが、彼らはそこでそれを与えることができます。



さらに、現在非常に活発に開発されているもう1つの分野は、視覚テストです（たとえば、Applitoolsを使用）。 非常に簡単な言葉で説明すると、Webについて話しているときにスクリーンショットが撮られている場合、WebDriverを使用してアプリケーションの特定のスクリプトが実行されます。 そして、スクリーンショット比較アルゴリズムが実装され、変更が特定されます。 たとえば、昨日、スクリーンショットが撮られました。私たちは彼を見て、次のように言いました。 これがベースラインになります。」 そして、今日はスクリーンショットを撮りました。 これらのスクリーンショットを分析するアルゴリズムがあり、変更が発生した場所を正確に追跡してグループ化できます。



-そして、フォントを変更し、画像が変更されたとしましょう。 それで何？ テストは今失敗しましたか？



-いや！ 彼らはこれを実践する方法を知っています。 彼らはこれらをグループ化する方法を知っています。 つまり、彼らは言う：「ええ、ここでフォントが変更されたことがわかります。」 さらにいくつかのスクリーンショットを見て、「これは変更の種類です。1番-フォントが変更されました。」 そして、あなたはそれを確認しなければなりません。 「そうです、アプリケーションのフォントを実際に変更しました。」 , , , , .



, . , , - , , , . « »? : « — - , , », . , , . - , , , , , .



, : «, ». : «Confirmed, , ». baseline . , .



, : . , . : Firefox, Chrome, IE, Safari, . . , baseline- .



, .



— .



— , . , Selenium Camp , . Selenium WebDriver. , WebDriver- , «». , .



, . . , Google, Facebook .



— , , ? — ?



— , , .



— UI?



— ! , , API.



, , -, - , «» . , , - , , . . .



— - workflow . . workflow- , , , , , , . , , , , .



— ? , ?



— ? . - flow. flow, , . , flow , , . flow, , , . . , , , . - , . . , , - , , . , , , API , «». , , . , . , , , - , .



, . IDE . , - , . background-. , , , IDE , , - , - .



, , , , . , , CI- TeamCity. : , , : «, ?» — , , , — CI-.



— Jenkins ?



— , , .



— !



— , Jenkins , ! , CI. , : « quality gate». quality gate , .



, IDE . , , nightly builds, . , , .



, , , , WebDriver, . API . W3C, , , — , , , — , . , , , API , .



— , . !



— ! !

---

, QA, Joker 2016 (, 14-15 ).

• Stream API
• Tracing distributed services: experiences with implementing APM for the JVM
• Java
• : ?

, (, 10 ).



, 09.09!