backend тестирование что это
Backend тестирование что это
Перед выпуском программного обеспечение в продакшн, его обязательно нужно тестировать. Тестирование позволяет убедиться, что софт отвечает необходимым требованиям и, скорее всего, в нем отсутствуют дефекты.
В этой статье я хочу затронуть теоретические аспекты тестирования, которые необходимо понимать абсолютно каждому разработчику. Статья больше нацелена на специалистов начального уровня, но и более опытные разработчики смогут найти тут интересную информацию.
Почему важно тестировать? Личный опыт
Начну с лирического отступления.
Не хотелось начинать статью из сухой теории. Осознание важности тестирования кода ко мне пришло со временем, и пришло оно с опытом, а не с прочитанной в интернете теорией.
Конечно я искал разную информацию по тестированию в языке Go, но находил лишь самые примитивные примеры, когда создают функцию Sum(a, b int) return a + b, и покрывают ее тестами.
Тогда я задался вопросом «А как выглядят тесты на реальных проектах? В которых много бизнес логики, работы со сторонним АПИ, различными хранилищами и внешними зависимостями».
На следующем месте работы я впервые увидел тесты. Сама архитектура приложения была куда более гибка и расширяема, что позволяло покрывать отдельные функции и модули тестами.
На проекте были как юнит, так и интеграционные тесты, а со времени у нас в команде появился разработчик, который покрывал все приложение автотестами.
После сдачи MVP (Minimum Viable Product) продукта, появилась возможность покрыть код тестами. Тогда я обнаружил множество сценариев, в которых приложение работает некорректно (например, создание продукции с отрицательным значением цены, чтение невалидных форматов хедеров и тд.).
За последних несколько месяцев я написал больше тестов, чем за всю свою жизнь. И покрывая даже самые простые программы, я убеждаюсь, насколько это важный аспект разработки.
При разработке, мы пишем код, отталкиваясь от бизнес логики. Мы фокусируемся на позитивных сценариях выполнения, когда все условия удовлетворяют данным требованиям.
«А что, если я передам в функцию создания товарной единицы отрицательную цену? А что если клиент прислал время по Unix, которое равно 0? А что если стороннее АПИ пришлет пустые значения?»
Когда мы начинаем писать тесты, мы сразу видим дыры в логике. Сценарии, которые не были учтены при разработке. Написание тестов всегда сопутствует небольшому рефакторингу кода. И это отлично!
Чем дольше идет работа над проектом, тем больше он обрастает различным функционалом. Если не уделять должного времени тестам, в будущем такая система начнет проявлять неожиданное поведение в неожиданных местах.
Когда все тесты успешно проходят, у нас появляется уверенность в качестве программного продукта. Расширять его новым функционалом становится проще, поскольку при добавлении нового или изменении старого, мы можем сразу убедиться, что система по прежнему работает корректно.
Важность автоматизации
На заре разработки ПО, все тестирование происходило мануально. Перед каждым выпуском софта программисты и тестировщики руками проверяли корректность работы приложения. Как вы понимаете, такой подход крайне непрактичен и отнимает уйму времени.
На сегодняшний день, любая команда разработки ПО стремится как можно быстрее добавлять новые фичи, или улучшать старые, при этом оперативно и безболезненно доставлять их в продакшн. Это стремление породило практику непрерывной доставки и развертывания, которая позволяет выпускать новые версии продуктов гарантированно и автоматически, хоть по несколько раз на день.
Достигается это за счет автоматизации большинства процессов, от сборки и тестирования до развертывания приложений на инфраструктуре.
Поэтому очень важно покрывать приложение тестами и автоматизировать их. Это позволяет сразу отлавливать ошибки при разработке или развертывании. Такой подход оперативен и экономит много времени и ресурсов.
Виды тестирования
Тестирование бывает разных видов и уровней. В книге «Scrum: гибкая разработка ПО» Майк Кон представил пирамиду тестов, которую следует рассматривать при автоматизации тестирования.
Оригинальная пирамида состоит из трёх уровней: юнит, сервисных и UI тестов, которые идут снизу вверх.
Из этой пирамиды стоит запомнить 2 ключевых принципа:
End-to-end тестирование проверяет полный флоу приложения. Оно помогает проверить корректность функциональных требований и пользовательского опыта. Такие тесты самые сложные в реализации и поддержке, поэтому их пишут наименьшее количество для ключевых сценариев.
Нам, как бекенд разработчикам, стоит фокусировать свое внимание только на юнит и интеграционных тестах, так как сквозными end-to-end тестами зачастую занимаются QA инженеры.
Unit-тестирование
Основа набора тестов состоит из юнит, или как их еще называют, модульных тестов. Они проверяют, что отдельный юнит (тестируемый субъект) кодовой базы работает должным образом. Модульные тесты имеют наименьшую область покрытия кода среди всех тестов в наборе. Количество юнит-тестов в наборе значительно превышает количество любых других тестов.
Сейчас вы можете задать вопрос «А что такое юнит?». Дать точный ответ на этот вопрос достаточно сложно. В индустрии нет общепринятого определения.
Если вы пишете код используя структурную парадигму, то юнитом скорее всего будет отдельная функция. Ваши юнит-тесты вызовут функцию с различными параметрами и обеспечат возврат ожидаемых значений.
В объектно-ориентированном языке юнит может варьироваться от отдельного метода до целого класса.
Однако есть вполне конкретные критерии, по которым можно определить тип теста. Как написал в своем твиттере Dave Chaney, тест не является юнит тестом если:
Но в большинстве случаев мы хотим протестировать функции или методы, которые как раз таки выполняют такие вещи как коммуникация с БД или по сети. Как нужно поступать тогда в таком случае?
Моки (имитации)
Хороший юнит тест проверяет логику работы отдельного метода или функции. Однако они, зачастую, могут зависеть от внешних зависимостей, таких как база данных, очередь сообщений, стороннее API и так далее. Эти зависимости принято подменять имитацией, поведение которой можно самостоятельно определять в самом тесте. Это помогает абстрагироваться от всех лишних деталей, и проверить исключительно логику работы текущего юнита.
Структура тестов
Давайте поговорим про структуру тестов. Хорошая структура состоит из 3х ключевых этапов, а именно: настройка тестовых данных, вызов тестируемого кода и проверка возвращаемых результатов.Для запоминания этой структуры, в английском языке есть хорошая мнемоника, три буквы А, что означают Arrange, Act и Assert (то есть расположить, выполнить и убедится)
Эта структура подходит для всех типов тестов, не только модульных.
Интеграционное тестирование
Теперь рассмотрим интеграционное тестирование.
Все нетривиальные приложения интегрированы с другими элементами, такими как базы данных, файловые системы или сторонние API, общение с которыми происходит по сети.
В юнит-тестах мы обычно имитируем их для лучшей изоляции и повышения скорости. Тем не менее, наше приложение будет реально взаимодействовать с другими частями — и данное взаимодействие стоит тестировать. Именно для этого предназначены интеграционные тесты. Они проверяют интеграцию приложения со всеми компонентами вне приложения.
Для автоматизированных тестов это означает, что нужно запустить не только собственное приложение, но и интегрируемый компонент. Если вы тестируете интеграцию с БД, то при выполнении тестов надо запустить БД. Чтобы проверить чтение файлов с диска нужно сохранить файл на диск и загрузить его в интеграционный тест. А чтобы проверить работу со сторонним АПИ, стоит использовать тестовый ключ и выполнять все проверки в sandbox.
Следуя моей практике, интеграционные тесты для веб приложений подразумевают тестирование HTTP запросов к API и последующей проверкой состояния базы данных. При этом такие внешние зависимости как очереди сообщений мокаются, а если приложение общается со сторонним API, то используеться тестовое окружение или sandbox.
Test-Driven Development (TDD)
Говоря о тестировании, необходимо также упомянуть такой подход к разработке как Test-Driven Development или TDD, что можно перевести как «Разработка через тестирование».
Данный подход заключается в том, что разработка программы состоит из небольших циклов: перед тем как писать код, вы пишите тесты, отталкиваясь от спецификации программного продукта, после чего пишете ровно столько кода, сколько будет достаточно для удовлетворения тестов, и не больше.
В конце вы делаете рефакторинг и продолжаете опять добавлять функционал, начиная с тестов.
Подобный стиль мотивируется тем, что позволяет писать более простой, понятный и чистый код, без лишних зависимостей и неиспользуемых функции. В основе TDD лежат принципы KISS и YAGNI.
Корреляция архитектуры и сложности покрытия тестами
Стоит понимать, что сложность покрытия приложения тестами напрямую зависит от архитектуры приложения. Покрыть интеграционными тестами небольшой монолит будет достаточно просто. Если же у вас микросервисная архитектура, задача становится менее тривиальной, поскольку нужно решить как будет тестироваться взаимодействие сервисов между собой.
Также, когда в самом приложении соблюдены принципы инверсии зависимостей и разделения ответственности, такой код будет легко покрыть юнит-тестами. Если же принципы чистой архитектуры не соблюдены при проектировании системы, задача становится более сложной, скорее всего для начала потребуется рефакторинг.
Итоги
Данная тема достаточно комплексная. В данной статье я лишь хотел поделиться своим опытом и разобрать ключевые концепции, чтобы подтолкнуть вас к дальнейшему изучению и практике написания тестов.
Покрывайте свой код тестами и пишите качественный код. Чести и удачи!
Что должен знать тестировщик бэкенда
Меня часто спрашивают о том, что почитать перед собеседованием на позицию тестировщика бэкенда. И в работе я сталкиваюсь с тем, что многие соискатели не всегда понимают, что будет на интервью, и приходят неподготовленными. Так родилась идея собрать полезную информацию в одной статье.
В FunCorp есть список тем с вопросами, которые мы задаём кандидатам. Я решил дополнить его, сделать более универсальным, разбить каждую тему по уровням (что нужно знать обязательно и что будет плюсом) и добавить ссылки на статьи и книги, которые можно почитать по этим темам.
Какие проблемы помогает решить этот текст: кандидату — подготовиться к интервью, любому тестировщику бэкенда — освежить знания, тестировщику фронтенда или мобильных приложений — расширить кругозор. Работодатели могут использовать список для составления требований в вакансиях.
Необходимые знания
Сразу сделаю ремарку: необходимые знания и навыки зависят от специфики вакансии. Если вакансия про тестирование API, где используется HTTP, то вам нужно очень хорошо знать HTTP и необязательно знать нюансы работы ОС. Если вы будете работать с Windows, то вам необязательно знать bash.
Также хочу обратиться и к работодателям: не стоит спрашивать про управление памятью в Linux кандидата на позицию Mobile QA Engineer, это вряд ли пригодится ему в работе.
Я не упоминаю языки программирования, потому что это сильно зависит от используемого стека. Но часто про них вообще ничего не спрашивают на собеседованиях тестировщиков (в противном случае указывают о необходимом уровне знания языка в описании вакансии).
По многим темам я буду давать ссылки, в том числе и на «Википедию». Да, пусть это не самый качественный источник информации, однако я считаю, что она вполне подходит для поверхностного изучения темы или освежения знаний и хороша тем, что в любой статье есть множество ссылок на другие статьи по конкретной предметной области. В любом случае, я привожу ссылки и на другие статьи и книги, так что каждый может сам для себя выбрать подходящий источник информации.
Теория тестирования
Начну, пожалуй, с самого очевидного, но не самого однозначного: некоторые тимлиды могут загонять вас по всем терминам и понятиям на собеседовании, некоторые не спросят вообще ничего.
Что ожидается от любого кандидата
Знание основных терминов, техник тест-дизайна, умение написать качественный баг-репорт.
Что говорит о том, что кандидат хорошо знает тему
Формально это сертификаты ISTQB.
Что почитать по теме
Есть хорошая статья на Хабре со всей необходимой информацией. Если же хочется более детально разобраться в теории тестирования, то можно почитать материалы ISTQB.
Shell
В зависимости от ОС нужно знать либо bash (sh, zsh и т.п., но нюансы вряд ли будут играть существенную роль), либо CMD и PowerShell.
Что ожидается от любого кандидата
Знание базовых команд.
Что говорит о том, что кандидат хорошо знает тему
Кандидат знает много команд, различные опции для них, их преимущества и недостатки, различные способы использования, а также инструменты для дебага проблем, например, strace, tcpdump, gdb и прочие.
Что почитать по теме
Про основные команды в Linux можно почитать в одной из моих предыдущих статей, а также есть очень крутой репозиторий c кучей примеров на GitHub. Из книг я бы посоветовал «Операционная система UNIX» Робачевского, Немнюгина и Стесик — она не только про команды, а про систему в целом.
Про команды CMD можно почитать здесь, а у PowerShell есть хорошая документация.
HTTP (или протоколы, указанные в описании вакансии)
Очень часто в качестве основного протокола для клиент-серверной архитектуры выбирают HTTP, поэтому часто спрашивают именно про этот протокол. Однако может понадобиться знать IMAP, POP3, SMTP (если будете тестировать почту), Protobuf или MessagePack или другие протоколы.
Что ожидается от любого кандидата
Здесь всё зависит от распространённости протокола. Вряд ли вам будут давать бинарный дамп трафика и просить десериализовать его на бумажке из Protobuf, но если речь идёт об HTTP, то нужно знать его на хорошем уровне: структуру запроса и ответа, основные заголовки, методы, коды ответов, HTTPS.
Что говорит о том, что кандидат хорошо знает тему
Кандидат может ответить на вопросы про кеширование, сжатие данных, cookies и использование различных заголовков в HTTP. Для других протоколов всё более субъективно.
Что почитать по теме
Про HTTP вся необходимая информация есть в «Википедии». Про другие протоколы советую читать их документации и спецификации. Также не стоит забывать про HTTPS. Ну и само собой, нужно всегда под рукой иметь ссылки на RFC 2616 и RFC 7540 (но есть и другие спецификации).
Сетевые протоколы более низкого уровня
Многие кандидаты не имеют представления о том, что находится под HTTP. Я считаю, что это не очень хорошо характеризует их, потому что тестировщик должен обладать пытливым умом и умеренной любопытностью, поэтому знать в общих чертах о сетевой модели OSI, безусловно, надо.
Что ожидается от любого кандидата
Кандидат должен знать, что существуют протоколы TCP, UDP и IP и понимать их суть.
Что говорит о том, что кандидат хорошо знает тему
Понимание механизма работы протокола TCP (three-way handshake, некоторые поля из заголовка, флаги, скользящее окно), кандидат может назвать недостатки и преимущества TCP и UDP, области их применения, общие знания IP. Будет круто, если кандидат расскажет в двух словах и про другие протоколы (например, ARP, ICMP, ICMPv6).
Что почитать по теме
Базовые знания можно получить из статей в «Википедии»: сетевая модель OSI, TCP, UDP, IP, IPv6, ICMP, ARP, ICMPv6. Если хочется погрузиться в эту тему, то можно почитать «Компьютерные сети» Таненбаума.
Базы данных
Что ожидается от любого кандидата
Основные SQL-запросы (всеми любимый JOIN).
Что говорит о том, что кандидат хорошо знает тему
Общие знания о разных СУБД, репликации, шардировании, о внутреннем устройстве СУБД, общие знания о нереляционных БД.
Что почитать по теме
В общих чертах про базы данных можно почитать в документации конкретной СУБД. Если хочется разобраться с базами данных детально, то рекомендую соответствующие главы «Высоконагруженных приложений» Клеппмана.
Что ожидается от любого кандидата
Знание основных принципов ООП.
Что говорит о том, что кандидат хорошо знает тему
Будет круто, если кандидат знает некоторые паттерны.
Что почитать по теме
Про принципы можно почитать, например, здесь, про паттерны — здесь. Также есть классная книга «Приёмы объектно-ориентированного программирования. Паттерны проектирования» «банды четырёх».
Операционные системы
Что ожидается от любого кандидата
Для большинства вакансий тестировщиков знание нюансов работы операционных систем нерелевантно.
Что говорит о том, что кандидат хорошо знает тему
Будет круто, если кандидат знает про управление памятью, ядро и стек, создание новых процессов и их шедулинг, файловые системы и прочее.
Что почитать по теме
Вкратце можно прочитать в уже упомянутой книге «Операционная система UNIX» Робачевского, Немнюгина и Стесик. Если тема заинтересует, то можно углубиться в неё с помощью, например, «Современных операционных систем» Таненбаума. В общих чертах ознакомиться с темой можно с помощью «Википедии»: есть статьи про ядро Linux, виртуальную память, context switch и прочие.
Архитектура ЭВМ
Что ожидается от любого кандидата
Для большинства вакансий тестировщиков знание нюансов работы процессоров, памяти и периферийных устройств нерелевантно.
Что говорит о том, что кандидат хорошо знает тему
Будет здорово, если кандидат знает в общих чертах про работу процессора, регистры, кеши, работу памяти и диска и прочее.
Что почитать по теме
Поверхностно ознакомиться с «железом» можно с помощью «Википедии»: ЦПУ, режим работы процессора, микроархитектура (в этой статье много ссылок на другие статьи по теме), кеш, АЛУ, конвейер, branch predictor, суперскалярность и т.д. Более целостно и глубоко эту тему можно изучить, например, с помощью книги «Архитектура компьютера» Таненбаума.
Алгоритмы и структуры данных
Вопросы по алгоритмам и структурам данных, скорее всего, не зададут (особенно если позиция не уровня Intern или Junior), но какие-то общие вещи знать всё равно надо. Лично меня только один раз на собеседовании спрашивали про двоичную кучу, сам я тоже не любитель спрашивать про это кандидатов. Поэтому никаких критериев вводить не буду и прикреплю лишь статью с хорошими картинками, можно распечатать их и положить на видном месте. Если захочется погрузиться в алгоритмы и структуры данных с головой, то смело начинайте читать «Алгоритмы. Руководство по разработке» Скиены или «Алгоритмы. Построение и анализ» Кормена.
Прочее
Несколько примеров тестовых заданий
Что будет, если ввести в адресную строку браузера google.com и нажать Enter?
Классическая задача, с помощью которой можно проверить, насколько глубоко кандидат разбирается в веб-технологиях в целом. Есть подробный разбор этой задачи на Хабре, но я не рекомендую вчитываться в нюансы типа «небольшое количество тока отправляется по электросхеме клавиатуры».
Тестирование формы с кнопкой
Да, эту задачу часто задают и на собеседовании тестировщиков бэкенда. Задача классическая, поэтому будет круто, если кандидат немного пофантазирует и представит, что может быть за этой формочкой с кнопкой. Например, можно предположить, что из формы данные уходят на бэкенд, состоящий из нескольких серверов и базы данных, что бэкенд пишет логи и имеет конфиг — это сразу добавит много тест-кейсов более глубокого уровня, чем «введём слишком длинное значение в поле ввода». Например, можно с помощью tcpdump смотреть, точно ли трафик идёт на все сервера бэкенда; можно попробовать отправить SQL-инъекцию или битый JSON (естественно, если вдруг JSON вообще есть в контексте задачи); можно проверить, что будет, если логи займут всё свободное место на диске; можно проверить работу системы при зафайрволенном бэкенде, корректность добавления данных в базу и т.д. Таким образом кандидат покажет свой широкий кругозор, что, несомненно, пойдёт ему на пользу.
Тестирование сервиса
Вариация предыдущей задачи: например, есть сервис, который слушает порт и принимает на вход JSON, отвечает в таком же формате. Всё аналогично, только формочки нет, поэтому бояться её не нужно. Подключаемся к порту, используя telnet, а дальше всё то же самое.
Тестирование эндпоинта REST API
И опять всё то же, только с HTTP (скорее всего). Здесь можно продемонстрировать знание протокола HTTP: например, проверить работу сервиса при наличии различных заголовков в запросе.
Конечно, универсальную методичку для подготовки тестировщика бэкенда с нуля составить нельзя: всё сильно зависит от специфики компании, специфики отдела и от тимлида. Да и технологии не стоят на месте: ещё недавно Docker активно не использовался, а сейчас опыт работы с ним может быть большим плюсом. Однако я постарался собрать базовые вещи в одном месте, и если это поможет подготовиться и найти работу хотя бы одному человеку, значит, я написал эту статью уже не зря.
Автоматизированное тестирование бэкенда
Бэкенд большинства проектов, которые мы реализуем, существует в формате Rest API. Одна из прелестей такой архитектуры заключается в том, что такой бэкенд можно и нужно покрывать автотестами.
Когда следует покрывать бэкенд автотестами
Всегда. Мы убеждены в этом.
Ведь это только на первый взгляд авто-тесты являются лишней статьей проектных расходов с сомнительной пользой. На практике же, покрытый тестами бэкенд делает разработку предсказуемой: ошибки не попадают на production-стенды, минимизируется вероятность ошибок при разработке новой функциональности.
Из нашей практики, особенно хорошо внедренные автотесты дают о себе знать на проектах, где разработка длится несколько месяцев. На поздних этапах разработки при внедрении нового функционала всё время повышается вероятность «сломать» старый функционал, который был реализован несколько месяцев назад.
Мы автоматизируем тестирование бэкенда везде, где позволяет архитектура. Независимо от бюджета на проект.
Как реализуется автоматизированное тестирование
Для автоматизации тестирования бэкенда мы используем PHPUnit. Расскажу в сокращенном виде, как всё работает на примере деплоя на dev-окружение. Для описания в деталях всего процесса, мы подготовим отдельную статью.
Для автоматизации прогона тестов мы используем функционал CI/CD в GitLab. Тесты запускаются при каждой попытке деплоя. При каждом обновлении код проекта разворачивается на специальном dev-стенде и тесты запускаются на нем.
Соответственно, если проектная команда видит, что выполнение тестов завершилось с ошибками, то происходит анализ отчета о тестировании (детальные логи также доступны в GitLab) и возникшие ошибки оперативно устраняются.
Таким образом, при реализации каждой новой функциональности регрессионно проверяется весь разработанный ранее функционал. Минимизируется вероятность попадания ошибок на production-стенд. Уменьшается влияние человеческого фактора на процесс разработки.
Не очевидные плюсы автоматизированного тестирования
1. Дополнительный рубеж самопроверки для разработчиков. При написании тестов на собственный функционал, разработчик вынужден взглянуть на него «со стороны», ещё раз проанализировать возможные сценарии его использования.
13 инструментов крутого backend-разработчика
Программирование — это магия. Но только для тех, кто не знает его изнутри. Сегодня поговорим о backend-разработке и о том, с чего начать её изучение.
Что такое
backend-разработка
Начнем с того, чем вообще занимается backend-программист. Он создаёт скрипты, которые выполняются на стороне сервера. Область его работы — получение данных от сайта, их обработка и подготовка к возвращению пользователю. Если нужно, то обращение в базу данных. К этому добавляется создание задач, которые решаются спустя время.
Иными словами, backend-разработка — это получение информации, её запись в базу и возврат данных на сайт, где они будут представлены пользователю средствами Frontend.
Автор в сфере IT, digital, экономики и финансов. Ведет некоммерческий проект для начинающих писателей «ЛитЦех».
Что должен знать и уметь backend-разработчик
Этого достаточно для начинающего программиста. В дальнейшем подключается работа с очередями через Cron. Он запускает скрипты по расписанию: раз в минуту, день или месяц. Так как более 80% сайтов в интернете написано на PHP, мы расскажем об инструментах веб-разработки именно на этом языке. Ну, а курс «PHP-разработчик» сделает из вас гуру в этой области.
Веб-сервер
Backend-разработчик должен развернуть на компьютере веб-сервер, чтобы тестировать свой код. Организация локального сервера возможна в трёх вариантах.
1. Поставить «чистые» PHP, Apache и MySQL самостоятельно с нуля или применить готовые пакеты — Xampp, Denwer и другие.
Такая сборка работает в системе разработчика и воспринимается программным окружением как локальный сервер.
Это виртуальная машина с широкими возможностями. Физически Vagrant находится на компьютере, но воспринимается не как локальный сервер. Разработчик подключается к нему не по localhost, а по другому IP, который он сам и прописывает.
Vagrant не зависит от системы: берём эту сборку, переносим на другую машину, и всё работает в том же режиме. Это более гибкое и удобное решение для организации веб-сервера.
Docker — уникальная и универсальная программа в области виртуализации. Она использует систему образов для хранения файлов, благодаря чему процессы операционной системы запускаются изолированно друг от друга. Веб-сервер воспринимается программным окружением как находящийся в облаке, а не на физической машине.
Более того, отдельно от основной системы в разных местах находятся PHP и MySQL. Обновить беспроблемно и быстро версию PHP или любого другого языка — это настоящее достижение в мире разработки.
Программы для создания кода
Код пишут где угодно, даже в блокноте. Однако для удобства придуманы системы, где работает автоподстановка, можно заниматься дебагом (подсказка: Процесс отладки кода) и использовать массу иных возможностей. Такая программа называется IDE — интегрированная среда разработки, или редактор кода.
Для работы с PHP рекомендуем две IDE:
Основное преимущество — это бесплатная система. Однако NetBeans съедает много памяти во время работы и не такой прогрессивный, как редактор ниже.
Очень удобный интеллектуальный редактор от компании JetBrains. Обладает отличной автоподстановкой и продвинутой системой семантического анализа. Программист допустил опечатку — анализатор тут же показывает, где именно. Незаменимый инструмент для веб-разработчика на PHP.
Работа с базой данных
MyAdmin — стандартное решение для этих целей, но не самое удобное. Во-первых, он запускается в браузере, и соединение иногда прерывается из-за таймаута. Во-вторых, он частенько выдаёт сбои и не может похвастаться гибкостью.
Советуем два варианта, превосходящие MyAdmin по характеристикам:
Они одинаковы в возможностях и качестве, так что при выборе отталкивайтесь от удобства использования. Разве что Navicat поддерживает больше баз данных, чем SQLyog, но это важно не всем.
Тестирование API
Любой backend-разработчик столкнётся с тестированием API. Для этого нужны запросы PUT, DELETE, PATCH и POST. Протестировать их работу невозможно через командную строку. Приходится писать запросы в коде PHP и использовать CURL, что занимает много времени и создаёт лишние проблемы.
Советуем программу Postman, где тестирование максимально комфортно. Просто вбивайте URL и параметры, и ответ вернётся в трёх форматах: как запрос выглядит на сайте, в JSON и в текстовом виде. Postman невероятно удобен и очень облегчает разработку API.
Программы для версионизации
Чтобы не сталкиваться с проблемой случайного удаления кусков кода, программисты используют версионизаторы. А ещё они помогают команде без проблем работать над одним функционалом совместно.
Часто выбирают систему контроля версий Git без графической реализации. Однако работать через командную строку неудобно и муторно, здесь слишком много нюансов и проблем. Например, возникающие при слиянии файлов конфликты гораздо лучше решать в графическом интерфейсе, чем в консоли.
Рекомендуем три системы:
1. GitKraken — платная программа. Предназначена для Ubuntu и macOS.