Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Несколько недель назад в моей LinkedIn-ленте появился пост от коллеги-автоматизатора Куо Динга. В нем Куо предлагает использование того, что он называет моделью «клиент – тест», для улучшения разделения ответственности при создании тестов API на основе HTTP в REST Assured.

Мне очень нравятся и идея, и модель Куо, это отличный шаг к улучшению читабельности и поддерживаемости кода API-тестов. Как разработчик RestAssured.Net, C#-варианта Rest Assured, я немедленно заинтересовался, можно ли использовать эту модель в моей библиотеке, и если да, то насколько хорошо.

Если кратко: можно.

Если полно: можно, и вот как это сделать.

Я практически в точности повторяю пример Куо – я пишу тест, который верифицирует создание нового контакта, то есть простого класса, представляющего контакт, с именем, фамилией и email-адресом в качестве свойств.

Как и в примере Куо, начнем с создания абстрактного ClientBase с общими настройками, которые может использовать множество клиентов:

public abstract class ClientBase
{
    private Uri baseUri;

    protected ClientBase(Uri baseUri)
    {
        this.baseUri = baseUri;
    }

    public RequestSpecification RequestSpec()
    {
        return new RequestSpecBuilder()
            .WithScheme(this.baseUri.Scheme)
            .WithHostName(this.baseUri.Host)
            .WithBasePath(this.baseUri.AbsolutePath)
            .WithPort(this.baseUri.Port)
            .WithRequestLogLevel(RequestLogLevel.All)
        .Build();
    }
}

Этот общий базовый класс затем можно использовать для создания ContactClient, отвечающий за операции с контактами – скажем, за получение конкретного контакта через HTTP GET to /contact/{id} или создание нового через HTTP POST to /contact:

public class ContactClient : ClientBase
{
    private static readonly Uri BaseUri = new Uri("http://localhost:9876/api/v2");

    public ContactClient() : base(BaseUri)
    {
    }

    public VerifiableResponse CreateContact(Contact contact)
    {
        return Given()
            .Spec(base.RequestSpec())
            .ContentType("application/json")
            .Body(contact)
            .When()
            .Post("/contact");
    }

    public VerifiableResponse GetContact(string contactId)
    {
        return Given()
            .Spec(base.RequestSpec())
            .When()
            .Get($"/contact/{contactId}");
    }
}

Избавившись от всех настроек HTTP-клиента, тест-метод может сконцентрироваться на создании нужных данных, выполнении операции и проверке ответа:

private readonly ContactClient contactClient = new ContactClient();

[Test]
public void CanUseClientTestModel()
{
    Contact contact = new ContactBuilder()
        .WithFirstName("John")
        .WithLastName("Doe")
        .WithEmail("
 Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
 ")
        .Build();

    this.contactClient
        .CreateContact(contact)
        .Then()
        .StatusCode(201);
}

Из вышесказанного можно сделать два вывода о модели «клиент-тест», как это уже сделал Куо:

• Это отличный способ разделить ответственность в API-тестах, сделать их читабельнее и проще в поддержке.
• Это можно реализовать в RestAssured.Net так же просто, как и в Java REST Assured.

P. S.: если вы измените подпись метода CreateContact() в ContactClient на

public VerifiableResponse CreateContact(object contact)

то сможете передавать анонимный объект вместо создания сильно типизированной копии контакта:

[Test]
public void CanUseClientTestModelWithAnonymousObject()
{
    var contact = new
    {
        FirstName = "John",
        LastName = "Doe",
        Email = "
 Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
 "
    };

    this.contactClient
        .CreateContact(contact)
        .Then()
        .StatusCode(201);
}

Здорово, правда?

Весь код из статьи можно найти на GitHub.

Обсудить в форуме