Привет, Хабр.
Мне по работе часто приходится заниматься переводом, и чтобы упростить себе жизнь, я решил настроить себе помощника, который был бы знаком с контекстом моей работы. Ниже делюсь результатами своих экспериментов.

Переводчик в своей работе ориентируется не просто на какой-то язык, а на терминологию и стилистику определённого сообщества. Мой основной рабочий процесс выстроен в Obsidian (подробнее об этом я писал вместе с Игнатием Сатирским), и я подумал, что база знаний, которая накопилась на этой платформе, может послужить «отражением» терминологии и стилистики, на которые мог бы опираться помощник. Я стал искать плагин, который давал бы интеграцию с нейросетью, и из всех возможных вариантов наиболее зрелым мне показался Obsidian Copilot — о нём и пойдёт речь.

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

Хранилище с использованными плагинами и результатами экспериментов доступно здесь.

Привет, Хабр. Сегодня поговорим о новой версии Allure Report — Allure 3, а именно о её модульной архитектуре. В ней можно настроить сколько угодно отображений тестовой иерархии в разных форматах; я покажу это на простом примере. В какой ситуации может это быть полезно?

Когда с тестами работает несколько команд, обычно удобно, чтобы у каждой был своя классификация тестов. Кто-то хочет, чтобы тесты были организованы по фичам, т. е. близко к требованиям. Кто-то предпочитает видеть организацию по сюитам — ближе к коду проверяемого приложения.

Мы сделаем так, чтобы при каждом запуске тестов Allure генерировал два отчёта, каждый со своим отображением тестов.

Нестабильные (flaky) тесты создают постоянные трудности для тестировщиков. Такие тесты не отражают состояния тестируемой системы и подрывают доверие к тестовому набору.

Вооружившись лучшими практиками, нестабильность можно свести к минимуму, но полностью избавиться от неё крайне трудно. Чтобы лучше её контролировать, нужны инструменты, позволяющие выявлять нестабильные тесты — например, Allure Report. В этом руководстве мы посмотрим, как Allure работает с нестабильными тестами.

Заодно мы познакомимся с Allure 3. Многие из вас наверняка пользуются Allure 2 — в третьей версии (помимо прочих изменений) работа с нестабильными тестами стала гораздо удобнее, в особенности настройка истории тестов.

Привет, Хабр.

Меня зовут Михаил, я технический автор, работаю с инструментами тестирования в команде ТестОпс. В какой-то момент мне стало интересно — а как получила распространение мысль о том, что разработчикам тоже надо писать тесты?

У меня было смутное представление о некотором тёмном «раньше», и условно-ограниченно-просвещённом «сейчас», когда мысль о том, что тестирование не должно жить отдельно от разработки, кажется, стала нормальной.

Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки.

С учётом этого, я решил заняться «археологией» автотестирования: посмотреть на прародителя современных фреймворков xUnit, SUnit для Smalltalk. Я хотел потрогать его руками, а также понять, что двигало его автором. В результате получилось довольно интересное путешествие, которым я хотел бы с вами поделиться.

Вначале я посмотрю на то, что из себя представляло автоматизированное тестирование в 1990-е. Чтобы понять, что добавил SUnit, попробую запустить на нём несколько примитивных тестов. А потом посмотрю, что можно наскрести по сусекам интернета о мотивации создателей и пользователей. Как они пришли к тому, что барьер между разработкой и тестированием надо преодолеть? Сам я не был участником этого процесса (годами не вышел), так что придётся опираться на вторичные источники.

Второй мозг для автора — собираем экосистему из нейросетей и заметок

Привет, Хабр! Эта статья - результат совместного труда двух авторов. В своей карьере мы перепробовали много различных методик. Мы искали способы «вытаскивать» мысли из головы в цифровое пространство, где их удобнее структурировать, чтобы затем превратить в связный живой текст. Делимся своим опытом работы с инструментами написания и редактирования текстов, среди которых есть как проверенные временем, так и появившиеся сравнительно недавно.

“Запахи” в тестах — это признаки антипаттернов. Хотя причины появления запахов тестов могут быть самыми разными, сегодня мы хотим рассмотреть одну повторяющуюся тему — структуру команды, а более конкретно — проблемы в общении у тестировщиков с другими командами. 

Общение между специалистами важно для создания качественных тестов, потому что тест — это пересечение нескольких специальных областей знаний:

- знание того, что хочет пользователь, интерпретируемое менеджментом как требования;

- знание всех технических нюансов и слабых мест тестируемой системы (SUT), известное разработчикам и ручным тестировщикам;

- теория тестирования, известная тестировщикам;

- реализация тестов на конкретном языке и фреймворке, с которыми знакомы инженеры по автоматизации (SDET).

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

"Запахи" в тестах — это полезные сигналы, которые важно уметь распознавать, чтобы писать удобные и легко поддерживаемые тесты. Мы уже писали про "запахи" в E2E-тестах; сейчас же рассмотрим распространённые ошибки, которые возникают при написании модульных тестов.

Хоть написание модульных тестов и является обычной практикой для программистов, тестовый код по-прежнему часто рассматриваются как код второго сорта. Между тем здесь, как и в любой области программирования, стоит знать паттерны и антипаттерны. 

В книге Джерарда Месароша о паттернах в xUnit есть полезные главы о «запахах тестов», и в интернете можно найти много других полезных материалов по этой теме. Нам же показалось интересным подойти к этой проблеме не со стороны теории, а со стороны практики: какие частые ошибки можно встретить в тестах, как их исправлять, и почему именно тесты нужно писать так, а не иначе?

Мы разберём всё это на примере: напишем один модульный тест на JUnit, и по ходу дела будем исправлять возникающие ошибки. Код примера доступен на GitHub.

На практике знание того, как НЕ писать тесты, может быть столь же важно, как и знание того, как их писать. В интернете можно найти множество материалов про “тесты с запашком”; в частности, им посвящено несколько очень полезных глав в книге Джерарда Месароша о паттернах в xUnit.

Нам показалось интересным подойти к этой проблеме не со стороны теории, а со стороны практики: какие частые ошибки можно встретить в тестах, как их исправлять, и почему именно тесты нужно писать так, а не иначе? Мы продемонстрируем всё это для стека JUnit + Selenide. 

В статье про тестируемость я косвенно упоминал подход "разработка через тестирование" (TDD); сейчас же хочу поделиться переводом статьи от гуру TDD, Роберта Мартина. Он обсуждает с Марком Симаном, нужно ли при динамической типизации больше тестов. Симан утверждает, что статическая типизация исключает многие недопустимые состояния, и поэтому часть тестов становится просто ненужной. Мартин же доказывает, что тесты необходимы для проверки поведения независимо от языка. При использовании методологии TDD типизация не обеспечивает дополнительной надёжности.

В итоге оба подхода приводят к рабочему коду, но разными путями: TDD шаг за шагом строит поведение через тесты, а статическая типизация формально исключает ошибки на уровне структуры программы.

(Статья — результат совместной работы с Максимом Степановым)

В прошлой статье мы показали, как тесты помогают найти изъяны в архитектуре. Для этого мы попытались протестировать скрипт на Python, проверяющий погоду. Нам пришлось разбить его на несколько функций в зависимости от зон ответственности, и это позволило написать несколько тестов. Но у них были существенные недостатки:

• Хрупкость

• Зависимость от внешних систем

• Невозможность протестировать пользовательский сценарий в отдельности

• Избыточное покрытие.

Чтобы написать более качественные тесты, нам придётся улушить архитектуру кода, а именно реализовать внедрение зависимостей и перейти на модульную архитектуру. Посмотрим, как именно тесты заставляют нас совершенствовать код.

(Статья — результат со вместной работы с Максимом Степановым)

Когда начинаешь писать тесты к коду, иногда возникает ощущение, что пытаешься расчесать запутанные волосы, и чем больше дёргаешь, тем больше узлов находишь. Это полезный сигнал, к которому стоит прислушиваться: плохая тестируемость подсказывает, что у кода есть изъяны в архитектуре. 

Связанный код, который сложно поддерживать и расширять, сложно и тестировать. Как сказал Боб Мартин: 

«Тестируемый код — синоним разъединённого кода»

А значит, тестируемость может быть маркером хорошей архитектуры. Именно это мы и попробуем здесь продемонстрировать.

Мы напишем тесты для примитивного скрипта на Python, который проверяет IP пользователя, определяет их регион и сообщает текущую погоду в регионе. Нас будет интересовать, как эти тесты заставят нас изменить код. Они, как расчёска, помогут нам методично разобрать проблемные места, чтобы код (как и волосы) стал гладким и послушным. Полный пример доступен здесь, каждый основной шаг находится в отдельной ветке.

В первой части статьи мы сделаем простейшее преобразование — разобъём скрипт на отдельные функции, а потом выясним, какие недостатки кода нам пока не удалось устранить. Во второй части мы от них избавимся с помощью разъединения зависимостей и модульной архитектуры. Поехали!

Почему так сложно сделать отчёт, который будет полезен и разработчику, и аналитику, и менеджеру? Написать красивую HTML-оболочку — дело не такое уж и трудозатратное. 

Но одного этого мало. Чтобы отчёт могли читать люди без навыков тестирования и программирования, он должен уметь скрывать технические подробности тестов; а чтобы им по-прежнему могли пользоваться тестировщики и разработчики, код по-прежнему должен быть под рукой, на расстоянии одного-двух кликов.

Нативные отчёты, используемые фреймворками тестирования, здесь обычно не подходят, или не предоставляют нужную функциональность «из коробки». Из опенсорсных решений, позволяющих анализировать тесты на разных уровнях, стоит упомянуть ReportPortal и Allure Report. На примере последнего мы проанализируем, что нужно, для того, чтобы сделать тесты «читаемыми» для всей команды — а в конце покажем, как эту функциональность можно расширить, если вдруг под ваш уникальный стэк её не удалось найти.