Технотекст 2022: шорт-листы по номинациям

Неожиданно и очень интересно.

Строим процессы тестирования в команде через огонь, воду и собственные фреймворки

Пока не все процессы идеальны, но мы думаем, как к этому стремиться и периодически что-то пересматриваем. Думали об этом тоже, спасибо за совет!

Строим процессы тестирования в команде через огонь, воду и собственные фреймворки

Привет, спасибо за вопрос.
Наверное в идеальном мире в вакууме хотелось бы все покрыть метриками и считать профит от того или иного действия, но не всегда на практике это легко и прозрачно.

На моем примере: я — основной разработчик CUTE, пишу документацию и помогаю с вопросами. Безусловно, это определенный кост для компании, так как вместо этого я мог бы катить бизнес-фичи, заниматься RnD или просто искать носки.

Поэтому мой подход отчасти прыжок веры: условно говоря, мои 3 часа разработки CUTE потенциально сокращают работу тестировщика на 10 минут, но таких сокращений может быть сотни, так как тестов создается много. Мне хочется верить, что в этом случае мы всё же наточили пилу, чтобы потом ей быстрее пилить)

Если говорить про обучение, то оно будет всегда и везде независимо от стека, так как у всех компаний есть своя специфика и контекст. В нашей команде специфика — CUTE и Go.

Отдельно замечу, что CUTE изначально была небольшой утилитой для нашей команды, но сейчас она применяется и другими командами по их собственному желанию, а некоторые идут дальше и переходят с Python на Go, посмотрев на наш пример.

Строим процессы тестирования в команде через огонь, воду и собственные фреймворки

Привет. Спасибо за комментарии.

Началось с того, что я решил попробовать написать тест на голом Go, то есть без использования каких-либо библиотек, связанных с созданием e2e тестов. Потом я то же самое проделал с использованием и сравнил. Во втором случае время на разработку уменьшилось, но оно и понятно, так как много логики спрятано внутри библиотеки. (p.s. до принятия решения по разработке CUTE).

На счет замеров: такого не было, да и провести было бы трудно, так как сейчас мы максимально сделали всё, чтобы старт был простым. Мы написали полностью инструкцию, как освоить библиотеку и как писать тесты, да и примеров тестов создалось немало за прошедший год.

В соседние команды люди выходили без бэграунда в Go, достаточно быстро осваивались, но опять же это все очень субъективно и трудно оценить.

Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go

Спасибо! :)

Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go

Привет!

1) Да, всё стандартно.

2) На данный момент реализация возможно неудобная, но мы работаем над этим!

import (
	"context"
	"fmt"
	"io"
	"log"
	"net/http"
	"testing"
	"time"

	"github.com/ozontech/allure-go/pkg/framework/provider"
	"github.com/ozontech/allure-go/pkg/framework/runner"
	"github.com/ozontech/cute"
)

func TestExampleSingleTest_AllureProviderT(t *testing.T) {
	runner.Run(t, "Test with two steps", func(t provider.T) {
		test := cute.NewTestBuilder().
			Title("AllureProviderT").
			Description("some_description").
			CreateWithStep().
			StepName("Request 1").
			RequestBuilder(
				cute.WithURI("https://jsonplaceholder.typicode.com/posts/1/comments"),
				cute.WithMethod(http.MethodGet),
			).
			ExpectStatus(http.StatusOK).
			ExecuteTest(context.Background(), t)

		bodyBytes, err := io.ReadAll(test.GetHTTPResponse().Body)
		if err != nil {
			log.Fatal(err)
		}
		// process body
		fmt.Println(string(bodyBytes))

		cute.NewTestBuilder().
			CreateWithStep().
			StepName("Request 2").
			RequestBuilder(
				cute.WithURI("https://jsonplaceholder.typicode.com/posts/1/comments"),
				cute.WithMethod(http.MethodGet),
			).
			ExpectExecuteTimeout(10*time.Second).
			ExpectStatus(http.StatusOK).
			ExecuteTest(context.Background(), t)
	})
}

3) Allure отчеты генерируются автоматически.

Второй QA Meetup от Ozon Tech: пишем тесты на Go, потому что можем

Будем рады видеть на митапе! :)

Второй QA Meetup от Ozon Tech: пишем тесты на Go, потому что можем

Вопросы дискуссионные, приходи к нам на митап обсудим это на круглом столе — так будет быстрее, эффективнее, а главное веселее!
На митапе будет много коллег по цеху, поэтому можно будет обсудить вопросы с разработчиками, тестировщиками и лидами.
Если не получится офлайн, то присоединяйся онлайн, пиши и мы на все ответим.

Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go

Привет. Да, можно сделать тест состоящий из нескольких запросов.

Пример:

import (
	"context"
	"net/http"

	"github.com/ozontech/allure-go/pkg/framework/provider"
	"github.com/ozontech/cute"
)

func (i *ExampleSuite) TestExample_TwoSteps(t provider.T) {
	cute.NewTestBuilder().
		Title("TestExample_TwoSteps").
		CreateWithStep(). // Создание 1 шага
		StepName("Step 1").
		RequestBuilder(
			cute.WithURI("https://jsonplaceholder.typicode.com/posts/1/comments"),
			cute.WithMethod(http.MethodPost),
		).
		ExpectStatus(http.StatusCreated).
		ExecuteTest(context.Background(), t).
		NextTestWithStep(). // Создание 2 шага
		StepName("Step 2").
		RequestBuilder(
			cute.WithURI("https://jsonplaceholder.typicode.com/posts/1/comments"),
			cute.WithMethod(http.MethodDelete),
		).
		ExecuteTest(context.Background(), t)
}

Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go

Привет. Инструменты, которые ты указал, являются более широконаправлеными.

Здесь же получился инструмент исключительно для тестирования http-сервисов на более простом языке. Безусловно, использовать эти инструменты, то может получится такой же результат, но он будет сложнее. А если попробовать это обвязать Allure, то сложность еще увеличится.

В пункте «Как было раньше?» я указал ссылку на статью, чтобы можно было сравнить сложность использования. А нам хотелось делать тесты проще — откуда и название Create Your Tests Easily.