💠 🖼️ 👨🏻 おそらくUIテストに最適なアーキテクチャ 🧙🏻 👋🏻 💪🏿

おそらく、どこかに、テストアーキテクチャのトピックを即座に完全に明らかにし、書き込み、読み取り、および保守が容易で、実装とアプリケーション領域の例を使用して初心者が理解できる理想的な記事があります。この「理想的な記事」のビジョンを、最初のタスク「自動テストの作成」を受け取った後で、私が夢見ていた形式で提供したいと思います。これを行うために、Web自動テストへのよく知られたアプローチとあまり知られていないアプローチ、それらを使用する理由、方法、タイミング、およびデータの保存と作成に成功するソリューションについて説明します。

こんにちは、Habr！私の名前はダイアナです。ユーザーインターフェイステストグループの責任者です。5年間、Webテストとデスクトップテストを自動化しています。コード例はjavaおよびWeb用ですが、実際にはテスト済みであり、アプローチはデスクトップを備えたpythonに適用できます。

最初は...

最初は単語があり、多くの単語があり、アーキテクチャやDRYの原則に関係なく、すべてのページがコードで均等に埋められていました（繰り返してはいけません。上記の3つの段落ですでに書いたコードを繰り返す必要はありません）。

シート

実際、「フットクロス」、別名「シート」、別名非構造化コードのアーキテクチャは、画面全体に均等に表示されるヒープに積み上げられており、それほど悪くはなく、次の状況に非常に適しています。

非常に小さなプロジェクトの場合は、3行（大丈夫、233）ですばやくクリックします。
ミニデモのコード例については、
自動テストの中で「HelloWord」スタイルの最初のコード。

ベッドシートのアーキテクチャを取得するには、何をする必要がありますか？必要なすべてのコードを1つのファイル、つまり共通のキャンバスに書き込むだけです。

import com.codeborne.selenide.Condition;
import com.codeborne.selenide.WebDriverRunner;
import org.testng.annotations.Test;

import static com.codeborne.selenide.Selenide.*;

public class RandomSheetTests {
    @Test
    void addUser() {
        open("https://ui-app-for-autotest.herokuapp.com/");
        $("#loginEmail").sendKeys("test@protei.ru");
        $("#loginPassword").sendKeys("test");
        $("#authButton").click();
        $("#menuMain").shouldBe(Condition.appear);

        $("#menuUsersOpener").hover();
        $("#menuUserAdd").click();

        $("#dataEmail").sendKeys("mail@mail.ru");
        $("#dataPassword").sendKeys("testPassword");
        $("#dataName").sendKeys("testUser");
        $("#dataGender").selectOptionContainingText("");
        $("#dataSelect12").click();
        $("#dataSelect21").click();
        $("#dataSelect22").click();
        $("#dataSend").click();

        $(".uk-modal-body").shouldHave(Condition.text(" ."));

        WebDriverRunner.closeWebDriver();
    }
}

自動テストに慣れ始めたばかりの場合、特にテスト設計とカバレッジについての十分な知識を示している場合は、「シート」で簡単なテストタスクを完了するのに十分です。しかし、これは大規模なプロジェクトには簡単すぎるため、野心はあるが、各テストケースを完全に実行する時間がない場合は、少なくともあなたのgitaにはより複雑なアーキテクチャの例が必要です。

PageObject

PageObjectが非推奨になるという噂を聞いたことがありますか？あなたはそれを調理する方法を知らないだけです！

このパターンの主な作業単位は「ページ」です。つまり、要素とそれらを含むアクションの完全なセットです。たとえば、MenuPageは、メニューを使用してすべてのアクションを説明するクラスです。つまり、タブのクリック、ドロップダウンアイテムの展開などです。

オブジェクト作成のモーダルウィンドウ（略して「モーダル」）用にPageObjectを作成するのは少し難しいです。クラスフィールドのセットは明確です：すべての入力フィールド、チェックボックス、ドロップダウンリスト。メソッドには2つのオプションがあります。「すべてのモーダルフィールドに入力」、「すべてのモーダルフィールドにランダムな値を入力」、「すべてのモダルクフィールドをチェック」、および「名前を入力」、「名前をチェック」の両方のユニバーサルメソッドを作成できます。「説明を記入してください」など。特定の場合に何を使用するかは、優先順位によって決まります。「モーダル全体に対して1つの方法」アプローチはテストの作成速度を向上させますが、「フィールドごとに1つの方法」アプローチと比較すると、テストの読みやすさが大幅に低下します。

例

Page Object :

public class UsersPage {

    @FindBy(how = How.ID, using = "dataEmail")
    private SelenideElement email;
    @FindBy(how = How.ID, using = "dataPassword")
    private SelenideElement password;
    @FindBy(how = How.ID, using = "dataName")
    private SelenideElement name;
    @FindBy(how = How.ID, using = "dataGender")
    private SelenideElement gender;
    @FindBy(how = How.ID, using = "dataSelect11")
    private SelenideElement var11;
    @FindBy(how = How.ID, using = "dataSelect12")
    private SelenideElement var12;
    @FindBy(how = How.ID, using = "dataSelect21")
    private SelenideElement var21;
    @FindBy(how = How.ID, using = "dataSelect22")
    private SelenideElement var22;
    @FindBy(how = How.ID, using = "dataSelect23")
    private SelenideElement var23;
    @FindBy(how = How.ID, using = "dataSend")
    private SelenideElement save;

    @Step("Complex add user")
    public UsersPage complexAddUser(String userMail, String userPassword, String userName, String userGender, 
                                    boolean v11, boolean v12, boolean v21, boolean v22, boolean v23) {
        email.sendKeys(userMail);
        password.sendKeys(userPassword);
        name.sendKeys(userName);
        gender.selectOption(userGender);
        set(var11, v11);
        set(var12, v12);
        set(var21, v21);
        set(var22, v22);
        set(var23, v23);
        save.click();
        return this;
    }

    @Step("Fill user Email")
    public UsersPage sendKeysEmail(String text) {...}

    @Step("Fill user Password")
    public UsersPage sendKeysPassword(String text) {...}

    @Step("Fill user Name")
    public UsersPage sendKeysName(String text) {...}

    @Step("Select user Gender")
    public UsersPage selectGender(String text) {...}

    @Step("Select user variant 1.1")
    public UsersPage selectVar11(boolean flag) {...}

    @Step("Select user variant 1.2")
    public UsersPage selectVar12(boolean flag) {...}

    @Step("Select user variant 2.1")
    public UsersPage selectVar21(boolean flag) {...}

    @Step("Select user variant 2.2")
    public UsersPage selectVar22(boolean flag) {...}

    @Step("Select user variant 2.3")
    public UsersPage selectVar23(boolean flag) {...}

    @Step("Click save")
    public UsersPage clickSave() {...}

    private void set(SelenideElement checkbox, boolean flag) {
        if (flag) {
            if (!checkbox.isSelected()) checkbox.click();
        } else {
            if (checkbox.isSelected()) checkbox.click();
        }
    }
}

    @Test
    void addUser() {
        baseRouter.authPage()
                .complexLogin("test@protei.ru", "test")
                .complexOpenAddUser()
                .complexAddUser("mail@test.ru", "pswrd", "TESTNAME", "", true, false, true, true, true)
                .checkAndCloseSuccessfulAlert();
    }

    @Test
    void addUserWithoutComplex() {
        //Arrange
        baseRouter.authPage()
                .complexLogin("test@protei.ru", "test");
        //Act
        baseRouter.mainPage()
                .hoverUsersOpener()
                .clickAddUserMenu();
        baseRouter.usersPage()
                .sendKeysEmail("mail@test.ru")
                .sendKeysPassword("pswrd")
                .sendKeysName("TESTNAME")
                .selectGender("")
                .selectVar11(true)
                .selectVar12(false)
                .selectVar21(true)
                .selectVar22(true)
                .selectVar23(true)
                .clickSave();
        //Assert
        baseRouter.usersPage()
                .checkTextSavePopup(" .")
                .closeSavePopup();
    }

. : , , , , — . , , , .

つまり、ページを含むすべてのアクションはページ内にカプセル化されているため（実装は非表示で、論理アクションのみが使用可能です）、ビジネス関数はすでにテストで使用されています。そしてこれにより、テストを変更することなく、プラットフォーム（Web、デスクトップ、携帯電話）ごとに独自のページを作成できます。

唯一の残念な点は、まったく同じインターフェイスが異なるプラットフォームではまれであるということです。

インターフェイス間の不一致を減らすために、個々のステップを複雑にしたいという誘惑があり、それらは別々の中間クラスに取り出され、テストはますます読みにくくなります。最大2つのステップ：「ログイン、うまくいく」、テストは終了します。Webに加えて、プロジェクトには追加のインターフェイスがなく、書き込みよりもケースを頻繁に読み取る必要があるため、読みやすくするために、過去のPageObjectsは新しい外観になりました。

PageObjectは、誰もが知っている古典です。このアプローチに関する多くの記事と、ほぼすべてのプログラミング言語の例を見つけることができます。PageObjectの使用は、候補者がユーザーインターフェイスのテストについて何か知っているかどうかを判断するためによく使用されます。このアプローチを使用してテスト割り当てを実行することは、ほとんどの雇用主が期待することであり、Webのみがテストしている場合でも、その多くは本番プロジェクトに存在します。

他に何が起こりますか？

奇妙なことに、単一のPageObjectではありません！

ScreenPlayパターンが頻繁に発生します。これについては、たとえば、ここで読むことができます。コードを読めない人を巻き込まずにbddアプローチを使用することは、オートマトンに対する無意味な暴力であるため、それは私たちの国に根付いていませんでした。
js- , PageObject, - , , .
- , , ModelBaseTesting, . , .

また、ページ要素について詳しく説明します。これにより、同じタイプのコードの量を減らしながら、読みやすさを向上させ、プロジェクトに精通していない人でもテストをすばやく理解できます。そしてその上に（もちろん、独自のブラックジャックと設定があります！）人気のある非jsフレームワークのhtmlElements、Atlas、およびEpamのJDIが構築されています。

ページ要素とは何ですか？

ページ要素パターンを作成するには、最下位レベルの要素から始めます。Wiktionaryが言うように、「ウィジェット」は、標準の外観を持ち、標準のアクションを実行するグラフィカルユーザーインターフェイスのソフトウェアプリミティブです。たとえば、最も単純なウィジェット「ボタン」-クリックすると、テキストと色を確認できます。「入力フィールド」では、テキストの入力、入力内容の確認、クリック、フォーカス表示の確認、入力文字数の確認、テキストの入力と「Enter」の入力、プレースホルダーの確認、「必須」フィールドの強調表示とエラーテキストの確認を行うことができます。特定の場合に他に何が必要になるか。さらに、このフィールドを使用するすべてのアクションは、どのページでも標準です。

内容のツリーテーブルなど、アクションがそれほど明白ではない、より複雑なウィジェットがあります。それらを書くとき、あなたはユーザーがプログラムのこの領域で何をするかに基づいて構築する必要があります、例えば：

指定されたテキストを含む目次の要素をクリックし、
指定されたテキストで要素の存在を確認し、
指定されたテキストで要素のインデントをチェックします。

ウィジェットには2つのタイプがあります。コンストラクターにロケーターを使用する場合と、ウィジェットを変更せずにロケーターをウィジェットに縫い付ける場合です。通常、目次はページ上の1つであり、ページ上の検索方法は、目次のアクションの「内部」に残すことができます。ロケーターが誤って外部から損傷する可能性があるため、ロケーターを個別に取り出すことは意味がなく、個別に保存するメリットはありません。同様に、テキストフィールドは普遍的なものです。逆に、一度に多くの入力フィールドが存在する可能性があるため、コンストラクターからのロケーターを介してのみテキストフィールドを操作する必要があります。たとえば、ドロップダウンヒントをさらにクリックするなど、1つの特別な入力フィールドのみを対象とするメソッドが少なくとも1つ表示された場合、これは単なる入力フィールドではなく、独自のウィジェットを作成するときが来ました。

全体的な混乱を減らすために、ページ要素のようなウィジェットが同じページに結合され、そこからページ要素という名前が構成されているようです。

public class UsersPage {

    public Table usersTable = new Table();

    public InputLine email = new InputLine(By.id("dataEmail"));
    public InputLine password = new InputLine(By.id("dataPassword"));
    public InputLine name = new InputLine(By.id("dataName"));
    public DropdownList gender = new DropdownList(By.id("dataGender"));
    public Checkbox var11 = new Checkbox(By.id("dataSelect11"));
    public Checkbox var12 = new Checkbox(By.id("dataSelect12"));
    public Checkbox var21 = new Checkbox(By.id("dataSelect21"));
    public Checkbox var22 = new Checkbox(By.id("dataSelect22"));
    public Checkbox var23 = new Checkbox(By.id("dataSelect23"));
    public Button save = new Button(By.id("dataSend"));

    public ErrorPopup errorPopup = new ErrorPopup();
    public ModalPopup savePopup = new ModalPopup();
}

テストで作成された上記のすべてを使用するには、ページ、ウィジェット、アクションを順番に参照する必要があるため、次のように構成されます。

    @Test
    public void authAsAdmin() {
        baseRouter
                .authPage().email.fill("test@protei.ru")
                .authPage().password.fill("test")
                .authPage().enter.click()
                .mainPage().logoutButton.shouldExist();
    }

フレームワークでこれが必要な場合（たとえば、RobotFramework用のJavaでのリモートライブラリの実装には入力としてステップクラスが必要です）、または美しいレポートの注釈を追加する場合は、クラシックステップレイヤーを追加できます。注釈ベースのジェネレーターにしました。興味があれば、コメントを書いてください。

承認ステップクラスの例

public class AuthSteps{

    private BaseRouter baseRouter = new BaseRouter();

    @Step("Sigh in as {mail}")
    public BaseSteps login(String mail, String password) {
        baseRouter
                .authPage().email.fill(mail)
                .authPage().password.fill(password)
                .authPage().enter.click()
                .mainPage().logoutButton.shouldExist();
        return this;
    }
    @Step("Fill E-mail")
    public AuthSteps fillEmail(String email) {
        baseRouter.authPage().email.fill(email);
        return this;
    }
    @Step("Fill password")
    public AuthSteps fillPassword(String password) {
        baseRouter.authPage().password.fill(password);
        return this;
    }
    @Step("Click enter")
    public AuthSteps clickEnter() {
        baseRouter.authPage().enter.click();
        return this;
    }
    @Step("Enter should exist")
    public AuthSteps shouldExistEnter() {
        baseRouter.authPage().enter.shouldExist();
        return this;
    }
    @Step("Logout")
    public AuthSteps logout() {
        baseRouter.mainPage().logoutButton.click()
                .authPage().enter.shouldExist();
        return this;
    }
}
public class BaseRouter {
//    ,      ,     
    public AuthPage authPage() {return page(AuthPage.class);}
    public MainPage mainPage() {return page(MainPage.class);}
    public UsersPage usersPage() {return page(UsersPage.class);}
    public VariantsPage variantsPage() {return page(VariantsPage.class);}
}

これらの手順は、ページ内の手順と非常によく似ていますが、実質的に違いはありません。ただし、それらを別々のクラスに分割すると、対応するページとのハードリンクが失われることなく、コード生成の範囲が広がります。同時に、ページにステップを記述しない場合、カプセル化の意味はなくなり、pageElementにステップのクラスを追加しない場合、ページとの対話はビジネスロジックから分離されたままになります。

, , . . , , , « , ». — , page object , !

テストデータを便利に操作する方法に触れずに、プロジェクトのアーキテクチャについて話すのは間違いです。

最も簡単な方法は、「現状のまま」または変数でテストに直接データを渡すことです。これはシートアーキテクチャには問題ありませんが、大きなプロジェクトは面倒になります。

もう1つの方法は、データをオブジェクトとして保存することです。これは、1つのエンティティに関連するすべてのデータを1つの場所に収集し、すべてを混同して間違った場所で何かを使用する誘惑を取り除くため、私たちにとって最適であることがわかりました。さらに、この方法には、個々のプロジェクトで役立つ可能性のある多くの追加の改善があります。

エンティティごとに、それを説明するモデルが作成されます。最も単純なケースでは、フィールドの名前とタイプが含まれています。たとえば、ユーザーモデルは次のとおりです。

public class User {
    private Integer id;
    private String mail;
    private String name;
    private String password;
    private Gender gender;

    private boolean check11;
    private boolean check12;
    private boolean check21;
    private boolean check22;
    private boolean check23;

    public enum Gender {
        MALE,
        FEMALE;

        public String getVisibleText() {
            switch (this) {
                case MALE:
                    return "";
                case FEMALE:
                    return "";
            }
            return "";
        }
    }
}

ライフハック＃1：クライアントとサーバーの相互作用の休息のようなアーキテクチャがある場合（jsonまたはxmlオブジェクトはクライアントとサーバーの間を行き来し、読み取り不可能なコードの断片ではありません）、jsonを<your language>オブジェクトにグーグルできます。おそらく、必要なジェネレーターがすでにあります。 ..。

ライフハック＃2：サーバー開発者が同じオブジェクト指向のプログラミング言語で記述している場合は、モデルを使用できます。

ライフハック＃3：あなたがジャビストであり、会社がサードパーティのライブラリの使用を許可していて、周りに神経質な同僚がいない場合、純粋で美しいJavaの代わりに追加のライブラリを使用する異端者にとって多くの苦痛を予測している場合は、Lombokを使用してください！はい、通常はIDEゲッター、セッター、toString、ビルダーを生成できます。しかし、LombokモデルとLombokを使用しない開発モデルを比較すると、各クラスのビジネスロジックを持たない数百行の「空の」コードの利益が見られます。 Lombokを使用する場合、フィールドとゲッター、セッターを組み合わせる人の手を打つ必要はありません。クラスは読みやすく、3つの画面をスクロールしなくても、オブジェクトのアイデアを一度に得ることができます。

したがって、テストデータをストレッチする必要があるオブジェクトのワイヤーフレームがあります。データは最終的な静的変数として保存できます。たとえば、これは、他のユーザーを作成するメインシステム管理者にとって便利です。テストのデータを変更する誘惑がないように、finalを使用することをお勧めします。そうすると、管理者の代わりに次のテストで、テストの並行起動は言うまでもなく、「無力な」ユーザーを取得できるからです。

public class Users {
    public static final User admin = User.builder().mail("test@protei.ru").password("test").build();
}

他のテストに影響を与えないデータを取得するには、「プロトタイプ」パターンを使用して、各テストでインスタンスのクローンを作成します。簡単にすることにしました。クラスのフィールドをランダム化するメソッドを作成するには、次のようにします。

    public static User getUserRandomData() {
        User user = User.builder()
                .mail(getRandomEmail())
                .password(getShortLatinStr())
                .name(getShortLatinStr())
                .gender(getRandomFromEnum(User.Gender.class))
                .check11(getRandomBool())
                .check21(getRandomBool())
                .check22(getRandomBool())
                .check23(getRandomBool())
                .build();
//business-logic: 11 xor 12 must be selected
        if (!user.isCheck11()) user.setCheck12(true); 
        if (user.isCheck11()) user.setCheck12(false);
        return user;
    }

同時に、直接ランダム性を作成するメソッドは、他のモデルでも使用されるため、別のクラスに配置する方が適切です。

ランダムユーザーを取得するメソッドでは、「ビルダー」パターンが使用されました。これは、必要なセットごとに新しいタイプのコンストラクターを作成しないために必要です。田畑。代わりに、もちろん、目的のコンストラクターを呼び出すだけで済みます。

データを保存するこの方法では、値オブジェクトパターンを使用します。これに基づいて、プロジェクトのニーズに応じて、任意の希望を追加できます。保存オブジェクトをデータベースに追加して、テストの前にシステムを準備することができます。ユーザーをランダム化することはできませんが、プロパティファイル（および別のクールなライブラリ）からユーザーをロードします）。どこでも同じユーザーを使用できますが、オブジェクトのタイプごとにいわゆるデータレジストリを作成します。このレジストリでは、エンドツーエンドカウンタの値がオブジェクトの名前またはその他の一意のフィールドに追加され、テストには常に一意のtestUser_135があります。

独自のオブジェクトストレージ（googleオブジェクトプールとflyweight）を作成して、テストの開始時に必要なエンティティを要求できます。倉庫は、すぐに使用できるオブジェクトの1つを提供し、それを占有済みとしてマークします。テストが終了すると、オブジェクトはストレージに戻され、必要に応じてクリーニングされ、空きとマークされて、次のテストに渡されます。これは、オブジェクトを作成する操作が非常にリソースを消費する場合に実行されます。このアプローチでは、ストレージはテストとは独立して機能し、次の場合のデータを準備できます。

データ作成

ユーザー編集の場合、編集する作成済みユーザーが必ず必要になります。通常、編集テストでは、このユーザーがどこから来たのかは関係ありません。それを作成するいくつかの方法があります：

テストの前に手でボタンを押してください。
前のテストのデータを残して、
バックアップからテストの前に展開し、
テストでボタンを直接クリックして作成し、
APIを使用します。

これらすべての方法には欠点があります。テストの前に手動でシステムに何かを入力する必要がある場合、これは悪いテストであるため、可能な限り人間の手から独立して動作する必要があるため、自動テストと呼ばれます。

前のテストの結果を使用すると、アトミック性の原則に違反し、テストを個別に実行できなくなります。バッチ全体を実行する必要があり、uiテストはそれほど高速ではありません。誰もが見事な孤立状態で、追加のダンスなしで実行できるように、テストを作成することは良い形式と考えられています。また、前回のテストを落としたオブジェクトの作成のバグは、編集のバグを保証するものではなく、そのような構成では、次に編集テストが失敗し、編集が機能するかどうかを確認できません。

テストに必要なデータでバックアップ（データベースの保存されたイメージ）を使用することは、特にバックアップが自動的に展開される場合、またはテスト自体がデータをデータベースに配置する場合、すでにあまり良いアプローチではありません。ただし、この特定のオブジェクトがテストで使用される理由は明らかではありません。データ交差の問題は、多数のテストから始まる場合もあります。たとえば、古いバージョンでテストを実行する必要があり、バックアップにすでに新しいフィールドが含まれている場合など、データベースアーキテクチャの更新により、バックアップが正しく機能しなくなることがあります。アプリケーションのバージョンごとにバックアップストレージを編成することで、これに対抗できます。データベースアーキテクチャの更新により、バックアップが再び有効でなくなることがあります。新しいフィールドが定期的に表示されるため、バックアップを定期的に更新する必要があります。そして突然それはかもしれませんまさにそのような単一のバックアップからのユーザーがクラッシュすることはなく、ユーザーが作成されたばかりか、名前が少しランダムに付けられた場合、バグが見つかります。これは「農薬効果」と呼ばれ、アプリケーションが同じデータに「慣れて」おり、落下せず、横にずれがないため、テストはバグの検出を停止します。

同じインターフェイスをクリックしてユーザーがテストで作成された場合、農薬が減少し、ユーザーの外観の非自明性が消えます。欠点は、前のテストの結果を使用する場合と同様です。速度はまあまあで、作成にバグがある場合でも（特にテストバグ、たとえば、保存ボタンのロケーターが変更される）、編集が機能するかどうかはわかりません。

最後に、ユーザーを作成する別の方法は、テストからhttp-APIを使用することです。つまり、ボタンをクリックする代わりに、目的のユーザーを作成するための要求をすぐに送信します。したがって、農薬は可能な限り削減され、ユーザーがどこから来たのかが明らかであり、ボタンをクリックする場合よりも作成速度がはるかに速くなります。この方法の欠点は、クライアントとサーバー間の通信プロトコルにjsonまたはxmlがないプロジェクトには適していないことです（たとえば、開発者がgwtを使用して記述し、テスター用に追加のapiを記述したくない場合）。 APIを使用すると、管理パネルによって実行されたロジックの一部が失われ、無効なエンティティが作成される可能性があります。 APIが変更されてテストが失敗する可能性がありますが、通常これは既知であり、変更のために変更を加える必要はありません。おそらく、これはまだチェックする必要がある新しいロジックです。APIレベルでバグが発生する可能性もありますが、既製のバックアップ以外の単一の方法が安全ではないため、データ作成のアプローチを組み合わせる方が適切です。

ドロップレットAPIを追加する

データを準備する方法の中で、別のテストの現在のニーズに対応し、テストで変更されない追加のテストデータ（オブジェクトのアイコンなど）のバックアップを展開して、アイコンがロードされたときにこれらのオブジェクトのテストがクラッシュしないようにするためのhttp-APIが最適です。

JavaでAPIを介してオブジェクトを作成するには、restAssuredライブラリを使用するのが最も便利であることがわかりましたが、これは実際には意図されていません。見つかったチップをいくつか共有したいのですが、もっと知っています-書いてください！

最初の問題は、システムでの承認です。その方法はプロジェクトごとに個別に選択する必要がありますが、共通点が1つあります。たとえば、次のように、要求仕様に承認を配置する必要があります。

public class ApiSettings {
    private static String loginEndpoint="/login";

    public static RequestSpecification testApi() {
        RequestSpecBuilder tmp = new RequestSpecBuilder()
                .setBaseUri(testConfig.getSiteUrl())
                .setContentType(ContentType.JSON)
                .setAccept(ContentType.JSON)
                .addFilter(new BeautifulRest())
                .log(LogDetail.ALL);
        Map<String, String> cookies = RestAssured.given().spec(tmp.build())
                .body(admin)
                .post(loginEndpoint).then().statusCode(200).extract().cookies();
        return tmp.addCookies(cookies).build();
    }
}

特定のユーザーのCookieを保存する機能を追加すると、サーバーへのリクエストの数が減ります。このメソッドの2番目の可能な拡張は、現在のテスト用に受信したCookieを保存し、承認手順をスキップして、それらをブラウザードライバーに投げることです。賞金は数秒ですが、テストの数を掛けると、かなりスピードアップできます！

歩き方と美しいレポートのためのパンがあります、ラインに注意して .addFilter(new BeautifulRest())ください：

BeautifulRestクラス

public class BeautifulRest extends AllureRestAssured {
        public BeautifulRest() {}

        public Response filter(FilterableRequestSpecification requestSpec, FilterableResponseSpecification responseSpec, FilterContext filterContext) {
            AllureLifecycle lifecycle = Allure.getLifecycle();
            lifecycle.startStep(UUID.randomUUID().toString(), (new StepResult()).setStatus(Status.PASSED).setName(String.format("%s: %s", requestSpec.getMethod(), requestSpec.getURI())));
            Response response;
            try {
                response = super.filter(requestSpec, responseSpec, filterContext);
            } finally {
                lifecycle.stopStep();
            }
            return response;
        }
}

ライブラリ自体がjson / xml内のモデルのシリアル化と逆シリアル化（json / xml形式から特定のクラスのオブジェクトへの変換）を処理するため、オブジェクトモデルはrestAssuredに完全に適合します。

    @Step("create user")
    public static User createUser(User user) {
        String usersEndpoint = "/user";
        return RestAssured.given().spec(ApiSettings.testApi())
                .when()
                .body(user)
                .post(usersEndpoint)
                .then().log().all()
                .statusCode(200)
                .body("state",containsString("OK"))
                .extract().as(User.class);
    }

オブジェクトを作成するために連続していくつかのステップを検討すると、コードのIDに気付くことができます。同じコードを減らすために、オブジェクトを作成するための一般的なメソッドを書くことができます。

    public static Object create(String endpoint, Object model) {
        return RestAssured.given().spec(ApiSettings.testApi())
                .when()
                .body(model)
                .post(endpoint)
                .then().log().all()
                .statusCode(200)
                .body("state",containsString("OK"))
                .extract().as(model.getClass());
    }

    @Step("create user")
    public static User createUser(User user) {
                  create(User.endpoint, user);
    }

もう一度日常の操作について

オブジェクトの編集をチェックする一環として、通常、オブジェクトがシステムにどのように表示されたか（api経由またはバックアップから）、またはuiテストによって作成されたかどうかは関係ありません。重要なアクションは、オブジェクトを見つけ、その上にある[編集]アイコンをクリックし、フィールドをクリアして新しい値を入力し、[保存]をクリックして、すべての新しい値が正しく保存されているかどうかを確認することです。テストに直接関係しないすべての不要な情報は、別のメソッドで、たとえばステップクラスで削除する必要があります。

    @Test
    void checkUserVars() {        
//Arrange
        User userForTest = getUserRandomData();
       
 //         , 
 //      -  , 
 //   ,   
        usersSteps.createUser(userForTest);
        authSteps.login(userForTest);
       
 //Act
        mainMenuSteps
                .clickVariantsMenu();
       
 //Assert
        variantsSteps
                .checkAllVariantsArePresent(userForTest.getVars())
                .checkVariantsCount(userForTest.getVarsCount());
        
//Cleanup
        usersSteps.deleteUser(userForTest);
    }

「複雑な」アクションのみで構成されるテストは読みにくくなり、コードを掘り下げずに再現することが難しくなるため、夢中にならないことが重要です。

    @Test
    void authAsAdmin() {
        authSteps.login(Users.admin);
//  ,    .     . 
//   ,   ?

実質的に同じテストがスイートに表示され、データの準備のみが異なる場合（たとえば、3つのタイプの「異なる」ユーザーすべてが同じアクションを実行できることを確認する必要があるか、異なるタイプのコントロールオブジェクトがあり、それぞれについて確認する必要があります。同一の依存オブジェクトを作成する場合、または10種類のオブジェクトステータスによるフィルタリングを確認する必要がある場合でも、繰り返し部分を別のメソッドに移動することはできません。読みやすさがあなたにとって重要であるならば、まったくありません！

代わりに、データ駆動型テストについて読む必要があります。Java+ TestNGの場合、次のようになります。

    @Test(dataProvider = "usersWithDifferentVars")
    void checkUserDifferentVars(User userForTest) {
        //Arrange
        usersSteps.createUser(userForTest);
        authSteps.login(userForTest);
        //Act
        mainMenuSteps
                .clickVariantsMenu();
        //Assert
        variantsSteps
                .checkAllVariantsArePresent(userForTest.getVars())
                .checkVariantsCount(userForTest.getVarsCount());
    }

 //         . 
 // ,   -.
    @DataSupplier(name = "usersWithDifferentVars")
    public Stream<User> usersWithDifferentVars(){
        return Stream.of(
            getUserRandomData().setCheck21(false).setCheck22(false).setCheck23(false),
            getUserRandomData().setCheck21(true).setCheck22(false).setCheck23(false),
            getUserRandomData().setCheck21(false).setCheck22(true).setCheck23(false),
            getUserRandomData().setCheck21(false).setCheck22(false).setCheck23(true),
            getUserRandomData().setCheck21(true).setCheck22(true).setCheck23(false),
            getUserRandomData().setCheck21(true).setCheck22(false).setCheck23(true),
            getUserRandomData().setCheck21(false).setCheck22(true).setCheck23(true),
            getUserRandomData().setCheck21(true).setCheck22(true).setCheck23(true)
        );
    }

これは、TestNGデータプロバイダーのアドオンであるデータサプライヤーライブラリを使用します。これにより、オブジェクト[] []の代わりに型付きコレクションを使用できますが、本質は同じです。したがって、入力データを受信する回数だけ実行される1つのテストを取得します。

結論

したがって、ユーザーインターフェイスの自動テストの大規模で便利なプロジェクトを作成するには、次のものが必要です。

アプリケーションで見つかったすべての小さなウィジェットについて説明します。
ウィジェットをページに収集し、
あらゆる種類のエンティティのモデルを作成し、
モデルに基づいてあらゆる種類のエンティティを生成するメソッドを追加し、
追加のエンティティを作成するための適切な方法を検討する
オプション：ステップファイルを手動で生成または収集します。
特定のテストの主なアクションのセクションに複雑なアクションがなく、ウィジェットを使用した明らかな操作のみが行われるようにテストを記述します。

これで、データを保存、生成、準備するための簡単なメソッドを備えたPageElementベースのプロジェクトが作成されました。これで、簡単に保守、管理、および十分な柔軟性を備えたアーキテクチャができました。ユーザーアクション形式の自動テストは読み、理解するのに最も便利なので、経験豊富なテスターと初心者の6月の両方がプロジェクトを簡単にナビゲートできます。

完成したプロジェクトの形での記事のコード例がgitに追加されます。

おそらくUIテストに最適なアーキテクチャ