В первой части мы озвучили следующие тезисы:

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

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

- тесты ломают разработчики, поэтому им за них отвечать - все виды тестов должны писать и поддерживать разработчики;

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

- главный шаблон поставки в прод изменений - конвейер развертывания (Deployment Pipeline);

- конвейер делится на 2 главные фазы: commit stage и acceptance stage;

- первая фаза - быстрые тесты (до 5 минут), чтобы быстро узнать, что ветка сломана и её надо скорее чинить;

- вторая фаза - приёмочные тесты (до 1 часа), чтобы узнать, можно ли ставить в прод изменения.

Про быстрые тесты мы поговорили во второй части. Пришло время поговорить про короля автотестов - приёмочное тестирование.

Вы, наверное, слышали, что тесты — это хорошо, что тесты надо писать. И, возможно, даже согласны с этим.

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

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

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

TL;DR: eslint-plugin-interface-method-style гарантирует, что ваши TypeScript реализации соответствуют стилю, определенному в интерфейсах. Если интерфейс объявляет метод (method(): void), реализация должна быть методом. Если объявлено свойство-функция (method: () => void), нужна стрелочная функция. Это предотвращает баги с правилом unbound-method и делает код предсказуемым.

Ссылочный тип данных Object является базовым для всех ссылочных типов в TypeScript подобно тому как в JavaScript Object является прототипом всех остальных ссылочных типов.

Помимо того, что в TypeScript существует объектный тип Object , представляющий одноименный конструктор из JavaScript, также существует тип object , представляющий любое объектное значение. Поведение типа указанного с помощью ключевого слова object и интерфейса Object различаются.

Переменные, которым указан тип с помощью ключевого слова object , не могут хранить значения примитивных типов, чьи идентификаторы (имена) начинаются со строчной буквы ( number , string и т.д.). В отличие от них тип интерфейс Object совместим с любым типом данных. Возникает ошибка: Error: Type X is not assignable to type 'object' (Тип X не может быть назначен типу «объект»).

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

Из всех видов автотестирования этот самый популярный. Но даже несмотря на это, половина разработчиков юнит-тесты не пишет и не умеет писать вовсе, а вторая половина пишет так, что лучше б и не писала. Либо чисто ради покрытия, либо просто от балды, как сердце подскажет.

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

Отсюда сформулируем главные вопросы, на которые мы ответим в этой статье:

- Нужно ли вам писать юнит тесты под ваши задачи? Или лучше выбрать другой тип тестирования и ограничиться только им?

- Если все же да, то как тогда писать юнит-тесты? Какие есть подходы, и какой лучше выбрать?

Короче, всё как обычно: как и нафига?

Ситуация, знакомая многим: разрабатываем сервис, пилим в нём фичи, развиваем продукт… но постепенно всё выходит из под контроля. Кодовая база разрастается, зависимости становятся сложнее. Команда разработчиков тратит больше времени на распутывание существующих проблем, чем на создание новой функциональности.

Хорошая новость: распутать спагетти-код можно по-разному, и иногда срабатывают не самые очевидные способы. В нашем случае помогла комбинация действий: не просто выделение части кода в отдельные микросервисы, но и параллельная реализация архитектурного подхода DDD Lite (в связке с принципами чистой архитектуры).

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

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

Сегодня поговорим о том, как приручить непосредственно исходные коды программ, как они архитектурно представляются. Расскажу про идеи, которые мы используем для построения прозрачной и понятной модели, чтобы ее было легко развивать вместе с заказчиком. Эти подходы касаются и архитектуры, и хранения исходного кода, и вообще в целом вопросов разработки. Также расскажу про практические сложности. Формат статьи не позволяет включить огромное количество кейсов, поэтому приведу только два примера.

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

Бывает, что компании решают использовать микросервисный подход, но в результате получают таких же монолитных монстров, но только работающих в Кубере.

Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет.

Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.

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

Можно ли исправить ситуацию коренным образом?

Вернон, в своей книге «Implementing DDD» много говорит об архитектуре Порты и Адаптеры, как о более продвинутом уровне Слоистой Архитектуры. Хотелось бы услышать ваше мнение на этот счёт.

Введение

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS автора Remo H. Jansen

В этой статье мы рассмотрим архитектуру, известную как слоистая (onion). Слоистая архитектура — подход к построению архитектуры приложения, придерживающийся принципов SOLID. Он создан под влиянием DDD и некоторых принципов функционального программирования, а также, активно применяет принцип инъекции зависимостей.

Предпосылки

Данный раздел описывает некоторые подходы и принципы разработки программного обеспечения, необходимые для понимания слоистой архитектуры.

Принцип разделения ответственности

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

Команда Python for Devs подготовила перевод статьи о том, как можно освободить десятки гигабайт места в PostgreSQL без удаления данных и индексов. TL;DR: удаляем неиспользуемые индексы, чистим bloat, пересобираем таблицы и используем частичные индексы, чтобы хранить только то, что реально нужно.

Postman в основном известен в качестве мощного инструмента для тестирования API. Но он также может значительно облегчить жизнь новым членам команды, аналитикам и клиентам, которые интегрируются с вами.

В этой статье я, SDET-специалист SimbirSoft Дарья, проведу обзор функций, с помощью которых Postman может помочь каждой из этих групп. Покажу на небольших примерах, как превратить набор запросов в то, что не стыдно будет пошарить коллегам, взаимодействующим с вашим API, и упростит жизнь новоприбывшим членам команды. Эта статья будет полезна специалистам различных уровней как в ручном, так и в автотестировании, а также бизнес- и системным аналитикам, для которых Postman сможет быть полезным для работы с документацией. 

Примеры буду приводить на ставшем классикой тренажере для практики отправки REST-запросов Petstore Swagger. Это имитация онлайн-зоомагазина, где можно манипулировать информацией о питомцах пользователей, а также создавать заказы.

Нотация Big O («О» большое) — это способ описания производительности функции без измерения времени ее выполнения. Вместо того, чтобы засекать, сколько секунд выполняется функция от начала до конца, Big O показывает, как меняется время ее выполнения по мере увеличения размера входных данных. Этот подход помогает понять, как программа будет вести себя при разных объемах входящей информации.

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

Без сомнений, JavaScript — крайне популярный язык программирования. И разработчики постоянно создают обновления, которые позволяют писать код проще, короче и понятнее. Одним из таких инструментов стала деструктуризация — способ получения данных

Привет, Хабр! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. В этом тексте на примерах разберемся, как работает синтаксис и как деструктуризировать массив. Подробности под катом!

В теории типов вариантность описывает отношение между двумя обобщёнными типами (дженериками). Например, в каких обстоятельствах родительский тип может быть заменён дочерним, а в каких — нет, и так далее.

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

Привет, Хабр! В прошлый раз я писал об эволюции роботов-пылесосов: мы отследили их путь от обычного «глотателя пыли» на колесиках до умной системы. Сегодня предлагаю узнать, как ваш домашний помощник ориентируется в пространстве. Разберемся, как устроено «зрение» робота, что за сенсоры и алгоритмы помогают ему действовать. Заодно обсудим, что ждет нас в будущем — от миниатюрных лидаров до адаптивных систем, заимствованных у беспилотных автомобилей.

Принцип “Не повторяйся” (Don't Repeat Yourself, или DRY), то есть избегай дублирования кода, часто относят к обязательным практикам в программировании. Однако в реальности часто можно увидеть, как в общем коде оказываются концептуально разные блоки, которые похожи только по внешним параметрам. Это неминуемо приводит к ухудшению кода и появлению "костылей", без которых он не работает. Именно поэтому слепое следование принципу DRY не всегда целесообразно! В этой статьей я расскажу про типичные ошибки при использовании этого правила и способы их избежать.

1. YAGNI

Сложно внедрить DDD в NestJS, не запутавшись в абстракциях? В статье рассмотрены частые ошибки - от комбайна в контроллерах до формальных Value Objects. Разбираем, как выделять слои (Domain, Application, Infrastructure, Interface), правильно использовать Entities и репозитории и создавать поддерживаемую архитектуру.