билд что это в тестировании
Основные определения и понятия тестирования ПО
Чтобы с головой погрузиться в новую профессиональную область, важно изучить язык, на котором говорят её представители. Ведь специальная лексика не только описывает инструменты или процессы, с которыми тестировщики работают ежедневно, но и облегчает общение с коллегами на около рабочие темы.
К примеру, вы уже могли слышать фразу «это не баг, а фича». Объяснить её далёкому от информационных технологий собеседнику не так просто: в отличие от бага, который является ошибкой, фича ― это не дефект, а заранее и сознательно придуманная опция, которая служит изюминкой. Слишком долго, не так ли?
Использование подобных словечек поможет вам проявить свои знания на собеседовании и найти общий язык с HR, уже работающим в ИТ-индустрии человеком. Итак, какие же понятия и определения будут полезны каждому начинающему QA-специалисту?
Базовые термины
Баг (bug) ― это ошибка или дефект программного обеспечения. Он проявляется, когда фактическое поведение системы отличается от ожидаемого. Дефекты могут быть критическими и влиять на использование ПО или незначительными, когда их присутствие незаметно для пользователя.
Тестирование (testing) ― это исследование поведения программного продукта, основной целью которого является выявление багов. Понятия контроль качества (quality control, QC) и обеспечение качества (quality assurance, QA) часто используются в качестве синонимов, но это ошибка. Ведь тестирование нацелено на поиск ошибок в уже готовом ПО, а обеспечение качества задаёт условия, в которых дефекты появляться не будут.
Подробно об отличиях данных явлений мы рассказали в нашей статье.
Тестовое покрытие (test coverage) ― это совокупность тестов, которые проявляют работоспособность той или иной функциональности ПО. Чем больше проверок, тем шире тестовое покрытие, тем больше возможностей отследить поведение системы в различных условиях и выявить критические или незначительные дефекты.
Верификация (verification) ― оценка ПО или его компонентов с точки зрения соответствия всем заявленным к нему требованиям.
Валидация (validation) ― это проверка работоспособности функциональности приложения.
Релиз (release, RTM) ― выпуск программного продукта на рынок, например, размещение мобильного приложения в App Store или Google Play.
Артефакты ― это документы, которые используют в процессе тестирования. Подробнее о том, какими они бывают, расскажем далее.
Артефакты
Спецификация (specification, спек) ― детализированное описание работы приложения, которое включает технические свойства.
Баг-репорт (bug report, отчёт об ошибке) ― описание действий или условий, которые привели к выявлению дефекта. О принципах составления безупречного баг-репорта мы уже рассказали в одной из наших статей.
Подобные отчёты создают в баг-трекинговой системе (bug tracking system, система отслеживания ошибок). Это программа для описания и контроля дефектов. Наиболее распространённой является Jira. Новичку привыкнуть к работе в этой системе непросто, но освоить азы вы сможете с поддержкой опытного преподавателя-практика на базовом курсе от QA Academy.
План тестирования (test plan) ― в этом документе содержатся все данные о проводимой проверке: описание программного продукта, стратегия тестирования, сроки выполнения поставленных задач, используемые в процессе инструменты и оборудование, оценка потенциальных рисков и прочее.
Чек-лист (checklist, контрольный список) ― перечень параметров, которые нуждаются в проверке.
Тест-кейс (test case, тестовый случай) ― своего рода сценарий или описание последовательности шагов при проведении тестирования.
Тестовый набор (test suite) ― несколько тест-кейсов, которые объединены по типу тестирования или другим признакам.
Типы тестирования
Мануальное (ручное) ― непосредственная проверка работы ПО тестировщиком.
Автоматизированное ― оценка качества программного продукта с применением программных средств (автотесты).
Тестирование производительности (performance testing) ― анализ работы приложений под различными нагрузками.
Функциональное тестирование (functional testing) ― проверка возможности ПО в заданных условиях решать необходимые пользователю задачи.
Тестирование безопасности (security testing) ― определение безопасности ПО: защищено ли оно от атак хакеров, несанкционированного доступа к данным и т. д.
UX-тестирование (usability testing, юзабилити-тестирование) ― исследование логики и удобства использования ПО.
Подробнее о различных подходах оценки качества ПО вы узнаете из нашего материала по классификации видов тестирования.
Ещё несколько полезных слов
Фиксить (от англ. to fix — исправлять) — вносить правки, исправлять ошибки.
Локаль (от англ. locale — место) — региональные настройки или параметры ПО.
Билд (от англ. to build — строить) — финальный вариант программного продукта или его элемента, который готов к тестированию.
Асайнить (от англ. to assign — назначать) — закреплять за кем-то задачу или часть работы.
В аттаче (от англ. to attach — приложить) — добавлять к письму или сообщению документ. Например, отправить на почту письмо с CV в аттаче означает, что было отправлено письмо с приложенным к нему резюме.
Букать (от англ. to book — бронировать) — резервировать.
Бэкапить (от англ. backup — дублирование) — создавать резервные копии документов или данных на случай их потери или удаления.
Дебаджить, дебажить (от англ. to debug — отлаживать) — настраивать или регулировать работу.
Тул (от англ. tool — инструмент) — программа, которая используется при тестировании.
Фича (от англ. feature — особенность) — некий аспект ПО, который служит его характерной особенностью.
Резюмируем
Мы постарались собрать самые важные слова и понятия, которые будут полезны на старте карьеры в QA. Они облегчат понимание профильной литературы и общение с коллегами. Поможет обогатить лексику регулярное чтение статей про тестирование, тематические блоги и литература.
Но быстрее всего пополнить словарик вы сможете в процессе живого общения во время рабочего процесса. Чтобы уже через несколько месяцев вы смогли реализоваться в QA, записывайтесь на курсы Академии сегодня!
Словарь тестировщика
Баг (bug, дефект) — отклонение фактического результата (actual result) от ожидаемого результата (expected result).
Если проще, то это ошибка.
◓ Пример из жизни.
Смотрим мы прогноз погоды и слышим, что сейчас на улице тепло и солнечно. Мы ожидаем, что при выходе на улицу будет тепло и солнечно (ожидаемый результат). Выходим на улицу, а там холодно и все небо затянуто тучами (фактический результат). То есть мы ждали одного (ожидаемый результат), а получили совсем другое (фактический результат).
Если бы мы вышли на улицу и там было тепло и солнечно, то фактический результат совпал бы с ожидаем и, значит, багов нет и все работает как надо.
◆ Пример из работы.
Возьмем форму авторизации на сайте. Мы ожидаем, что введя в поле “Имя” и в поле “Пароль” те данные, под которыми мы регистрировались, произойдет вход в систему. Если этого не случается, то мы имеем дело с багом.
Тестирование — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов.
Если проще, то это процесс проверки работоспособности продукта и его пригодности к использованию. То есть это не просто поиск багов.
◓ Пример из жизни.
Нам дали на проверку кружку. Что мы будем делать? Сначала продумаем, как именно ее можно проверить и набросаем себе план. И только затем присудим к делу. Осмотрим ее снаружи, проверим на трещины, оценим качество рисунка. Уроним ее на пол, чтобы проверить на прочность. Нальем в нее холодную воду, теплую, кипяток, чтобы посмотреть не лопнет ли она. Возьмем ее в руки, оценим, удобно ли держать. После расскажем о результатах нашей работы создателю кружки.
То есть мы не просто ищем дефекты, а проверяем ее со всех сторон и оцениваем, точно ли ей будем удобно пользоваться и выполняет ли она все заявленные функции.
◆ Пример из работы.
Есть задача проверить корзину покупок. Опять же начинаем с планирования. Мы пробуем положить в нее товар, удалить, изменить количество, оцениваем удобство и так далее. После заносим все найденные баги в специальные документы (баг-репорты) и отправляем разработчику (программисту).
Обычно тестирование осуществляется на основании документации, но не всегда.
Техническое задание (ТЗ) – документ, в котором зафиксированы требования к решениям, которые должны быть реализованы в ходе создания сайта или программного обеспечения.
Если проще, то это то, что пишет заказчик, когда хочет получить продукт.
◓ Пример из жизни.
Тесть решил построить дом для тещи и нанял для этого зятя (мужа дочери), который как раз работает инженером. У тестя есть свое видение этого дома. Он рисует и описывает его своими словами и передает мужу.
◆ Пример из работы.
Данный документ описывает, каким именно должен получиться продукт. Исходя из него мы понимаем, что это будет игра в виде фермы, тематика космос и т.д.
Спецификация (specialization, спек) — детальное описание того, как должно работать ПО.
Если проще, то это описание технических свойств своего продукта (размеры, различные параметры, материалы, функции, etc).
◓ Пример из жизни.
Зять читает желания тестя и на их основании уже рисует чертежи, выбирает материал, просчитывает его количество, продумывает как именно технически будет проведены коммуникации (вода, электричество, канализация) и так далее. И уже по этим готовым схемам строители начинают строить дом.
◆ Пример из работы.
На основании ТЗ прописывается, как это все реализовать с технической точки зрения. То есть по спецификации мы будем видеть, как именно должен работать наш продукт. В ней мы пропишем какие семена у нас будут, что из них вырастет, сколько времени займет рост, с помощью чего уже можно ускорить, сколько будут стоить сами семена и т.д.
(!) Все что не соответствует ТЗ и спецификации как раз и будет багом.
Отчет о дефекте (bug report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Его еще называют отчет об ошибке, баг-репорт.
Если проще, то это документ, в котором мы фиксируем найденный баг.
◓ Пример из жизни.
Вернемся к нашему забагованному прогнозу погоды. Что делать? Кому и как сообщить, что погода-то совсем не такая, как говорят? Надо просто написать отчет. Причем написать так, чтобы они поняли про какой именно район речь и что именно с этой погодой не так.
◆ Пример из работы.
На каждую найденную ошибку (баг) составляется отчет об ошибке. Данный отчет имеет определенный шаблон. У каждой компании может быть свой шаблон, но основные поля остаются неизменными. Именно этот шаблон позволяет разработчикам быстро ориентироваться и находить ошибку в коде.
Система отслеживания ошибок (bug tracking system) — программа учета и/или контроля багов.
Ее обычно называют баг-трекер или баг-трекинг.
◓Пример из жизни.
Где вы храните информацию о всех ошибках, которые допустила ваша вторая половинка, чтобы при удобной возможности ей это припомнить? Если вы ее где-то записываете и храните в определенном месте, то считайте, что у вас есть система отслеживания ошибок.
◆ Пример из работы.
Каждая фирма использует свою систему учета. Это могут быть как специально разработанные программы, так и обычные гугл-таблицы. Суть в том, что в одном месте собраны все наши отчеты об ошибках и в любое время можно получить доступ к любому отчету и посмотреть пофикшен он или нет.
Пофиксить — внести изменения, а именно исправления, в код программы.
Если проще, то это правка.
◓ Пример из жизни.
Жена сломала дверцу шкафа. Пошла к мужу, привела к дверце за руку, все показала (считайте, что предоставила баг-репорт с прикрепленным видео). Муж сел, там покрутил, тут постучал и дверца опять начала работать как положено. То есть муж исправил (пофиксил) шкаф.
◆ Пример из работы.
Мы создали баг-репорт и отправили в наш баг-трекер. Разработчик взял баг-репорт в работу, изучил его и внес изменения в код. То есть он исправил (пофиксил) код так, чтобы в продукте больше не было бага.
Билд — версионированная сборка программного обеспечения.
Если проще, то это продукт или кусок продукта, который можно тестировать.
◓ Пример из жизни.
Зять строит дом для тещи. Уже готов каркас и пару комнат. Эти комнаты уже можно показать жене на проверку. Именно эти пару комнат, которые ей уже можно смотреть и оценивать — это и есть билд, который будет тестировать жена.
◆ Пример из работы.
Разработчик создает продукт. Часть кода уже написана и готова к проверки. Именно эту часть он и отдает тестировщикам на проверку.
Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.
Если проще, то это продукт, который видит конечный пользователь.
Можно сказать, что релиз — это билд, который команда разработчиков предоставляет наружу.
◓ Пример из жизни.
Зять закончил строить дом для тещи. Жена все протестировала. Теперь можно привозить тещу и поздравлять ее с новосельем. То есть готовый дом — это и есть релиз.
Также этот пример наглядно показывает насколько вообще важно тестирование и чем может закончиться ситуация, когда продукт вышел в релиз без этапа тестирования)
◆ Пример из работы.
Разработчик создал продукт. Тестировщик его проверил. Если все хорошо, то принимается решение отдать продукт конечному потребителю.
Семь правил тестировщика
«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»
Е. Херригель
«Дзен и искусство стрельбы из лука»
Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?
Тогда прошу под кат!
Свою карьеру тестировщика я начал в одной небольшой фирме, занимающейся тестированием самолетного ПО. Там было только автоматизированное тестирование, все процессы были уже построены, в общем — не сильно сложная работа. Мне показали основы написания кода на Visual Basic, показали как запускать тесты, и отправили в дальнее плавание.
Затем моё студенчество закончилось, захотелось больше интересной работы, и я перешел в другую компанию на должность простого ручного тестировщика. Тут нужно сделать небольшое отступление — в небольших кампаниях/отделах тестировщик порой выполняет целую кучу задач, не связанных напрямую с тестированием. Например, развертывание тестовой среды, ведение нескольких веток продукта в сорс контроле, саппорт выпущенных продуктов и т.д. Я попал именно в такую ситуацию.
Поначалу все было хорошо — мы делали свой 1 проект, я все делал руками, и у меня еще оставалась куча свободного времени.
Но постепенно проектов становилось все больше, программисты постоянно фиксили баги, нужно было накатывать билды чуть ли не каждый час. В какой-то момент я заметил, что на собственно тестирование я трачу лишь 40% времени. Остальное время занимают какие-то левые активности. Тогда я понял первое простое правило:
1. Если ты тестировщик, то можно и нужно автоматизировать не только тестирование
Именно тогда я сделал простую табличку в Excel, и отметил все задачи, на которые тратилось время. И нашел то, что выжирало больше всего времени — банальная выкладка билдов (обновление файлов, екзешников и т.д.). Вечером дома я зарылся в яндекс, и нашел, как убрать эту активность в 0. Я посмотрел синтаксис билдов на нашем билд-сервере, и сделал автоматическую выкладку всего этого хозяйства. После этого я привязал запуск билда к check-in’у в сорс контроле, и обрадовался жизни — у меня опять появилось свободное время! Тогда же я понял второе простое правило:
2. Автоматизируй то, что даст наибольший выигрыш по времени
Постепенно проекты росли, и появились системы, расположенные на нескольких серверах. И, о ужас, — конфиги разработчиков не работали на серверах! А программисты почему-то(!) не хотели их править. Я опять полез ковыряться в билд-машине, и обнаружил, что конфиги можно легко менять на этапе сборки. Тогда я понял третье простое правило:
3. Полностью изучи работу билд-машины
Примерно тогда же в моем распоряжении появилась первая виртуальная ферма на Hyper-V. Через пару месяцев я уже не представлял себе, как жил до этого. Настолько легко и просто оказалось поднимать тестовые стенды! Отсюда четвертое простое правило:
4. Подними сервер виртуализации
В то время компания очень сильно выросла, и внезапно оказалось, что для простого заведения учетки в домене нужно писать заявку админам с обоснованием и подтверждениями. Какое-то время мы терпели, а потом я сделал свой тестовый домен. Через месяц я понял, что не только сервер виртуализации был необходим. Отсюда пятое простое правило:
5. Сделай, наконец, свой тестовый домен
Когда я поднимал тестовый домен, то обнаружил на сервере забавную вещь — Power Shell. Как оказалось, кучу вещей можно сделать без интерфейса — заводить пользователей, настраивать IIS, делать правила в файрволе, устанавливать сервисы и т.д. Кроме того я узнал, что это можно делать не только на своей машине!
И если какую-то задачу на удаленной машине нужно будет сделать больше трёх раз, я всегда пишу скрипт — экономия времени огромна.
В общем, шестое простое правило:
6. Разберись с PowerShell/cmd/bash
В какой-то момент я осознал, что даже не приступив к автоматизации тестирования, я автоматизировал все остальное!
Тогда я взялся делать свой первый огромный(как мне тогда казалось) проект по автоматизированному тестированию одной огромной монструозной бизнес-функции. Делал я его долго, мучительно, но все-таки сотворил. Вот только там было столько костылей, неявных зависимостей, хардкода и прочего добра, что как-либо поддерживать это создание воспаленного ума оказалось невозможным. Именно тогда я понял, почему эти умные программисты допускают столько косяков… Но это была не последняя монструозная система в моем исполнении — их было еще много. В общем, самое главное седьмое правило:
7. Хочешь автоматизировать? Учись правильно программировать! Прочитай книги по архитектуре программ
Именно тут проявила себя цитата, вынесенная в эпиграф. Только сделав несколько ужасных проектов, обломав кучу зубов на поддержке своих творений, я начал понимать то, что написали эти умные дядьки в своих книгах. Только тотальная нехватка времени и тупизна работы по копированию файликов из одного место в другое толкнули меня на путь автоматизации. Только полностью влившись в команду разработки я начал писать относительно нормальный код.
А потом я втянулся. И следующие несколько книжек в плане на прочтение — о программировании. Причем я не буду переходить в программисты, это не моё. Ну а программирующим тестировщиком я уже стал.
И главное, не нужно бояться автоматизации. Это не всегда огромные труды, которые могут принести мифическую прибыль в будущем. Посмотри вокруг! Что-то можно сделать мышкой? С вероятностью в 95% это можно заскриптовать. Ты выполняешь ручные операции уже в пятнадцатый раз? Значит заскриптовать их нужно было еще вчера.
И еще одно пожелание. Научился сам, просвети своих коллег — согласитесь, интереснее работать с людьми, которые делают красивые, сложные проекты, а не ходят в грязном свитере и страдают от своей работы.
Желаю интересных багов, хороших проектов и дружных коллег-программистов!
Что такое сборщик продукта
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
Написать код приложения
Поднять его на сервере приложения
Сегодня я расскажу про второй этап. Сборку приложения можно проводить вручную, но есть также специальные инструменты для этого, которые называются «сборщик продукта». О них мы и поговорим.
Содержание
Что это такое и зачем он нужен
Вася решил стать разработчиком, еще будучи студентом. Он выбрал язык программирования Java и начал его изучать. Тренировался на простых вещах:
Сначала весь код его мини-программ хранился в одном файле — Main.java. Чтобы запустить приложение, достаточно было дважды кликнуть этот файл. И всё!
Потом Вася освоил Page Object Pattern и стал разносить логику по разным классам. Но всё равно это были простые программы, и для запуска оставался главный класс.
А потом Вася. Устроился на работу. Да-да, зеленым новичком, и такое бывает! Старший разработчик Николай на собеседовании разглядел в нем потенциал. Так Вася стал джуниор-разработчиком в компании ООО «Котики».
Проект в компании большой, с семилетней историй. Он состоит из 6000 классов исходного кода, над которыми трудятся 5 разработчиков.
В первый рабочий день Николай подошел к Васе и стал рассказывать:
— Наш код хранится в git. Знаешь, что это такое?
— Ага, система контроля версий!
— Да. Вот тебе ссылочка, скачивай.
Вася скачал. Только вот. Что делать дальше? Какой из 6000 классов запустить, чтобы пощупать приложение?
Николай только ухмыльнулся:
— Нет, так оно только для мелких проектов работает. А тебе нужно:
скомпилировать проект — из исходных текстов получить файлы классов с байт-кодом (которые потом будет исполнять JVM);
объединить вот эти классы в библиотеку Search.jar;
объединить вот эти классы в библиотеку Clean.jar;
объединить вот эти классы в библиотеку Update.jar;
объединить вот эти классы в библиотеку Report.jar;
объединить вот эти классы в библиотеку Link.jar;
Вася в шоке выкатил глаза и промямлил:
— Ээээ, подожди. Мне это выучить надо?
— В учебных проектах тебе не надо заморачиваться. Запустил конкретный класс, и всё работает. Ну, может, еще одну-две библиотечки собрал, но это тоже несложно.
Но когда приложение растет, растет и список действий. Вручную его выполнять смысла нет — скука, да и только. К тому же человек легко может ошибиться, а в итоге получим неработающее приложение.
Поэтому эту работу автоматизируют. Можно написать скрипт сборки на коленке, но зачем, если уже есть стандартные сборщики? Скажем, для java это ant, maven, gradle. У нас используется maven, почитай пока о нем.
Сборщик уже настроен, так что тебе достаточно зайти через командную строку в директорию проекта и написать команду:
А дальше он сам всё сделает. На выходе получим cats.war. Это и есть наше приложение, которое мы потом подложим на сервер wildfly, чтобы его запустить.
— Ага, хорошо, спасибо!
Николай ушел, а Вася завороженно смотрел в экран, где в командной строке работал maven. Быстро-быстро бежали буквы по экрану. И вот, наконец, сборщик остановился. Он написал «BUILD SUCCESS». Значит, всё прошло хорошо. И в нужной директории Вася нашел архив «cats.war».
Пока Николая не было, Вася успел нагуглить это новое слово: «maven». И даже смог найти в проекте скрипт сборки, и начал разбираться, что конкретно там происходит. Всё-таки не зря его взяли на работу! Это отличное качество разработчика (да и не только его) — гуглить и копать самому, а не сидеть сложа ручки в ожидании ментора.
Когда Николай вернулся, он подытожил то, что Вася узнал:
— Когда разработчик пишет код — он просто создает набор файликов с текстом. Чтобы эти файлики превратились в работающее приложение, код нужно скомпилировать и запустить.
Что нужно сделать с кодом-источником:
объединить классы в файл JAR или другую библиотеку;
установить набор зависимостей;
запустить конкретный класс или несколько классов.
И только после всех этих манипуляций у нас появляется ПО. Набор манипуляций зависит от конкретного проекта, но чем сложнее проект, тем больше действий надо сделать.
А если задача повторяется снова и снова, она становится первым кандидатом на автоматизацию. Ведь нам нужно что? За один шаг получить работающий проект! Этим и занимаются системы сборки!
— О, стой! Так в IDEA (среда для написания кода) же кнопка «Build» есть. Она ведь тоже билдит, то есть собирает код! Да? Это аналог maven-а?
— Не совсем. Это кнопка:
компилирует код — проверяет его на наличие простых синтаксических ошибок вида «забыл поставить точку с запятой в конце команды»
собирает нужные ресурсы (файлы конфигов и подобные) в одну папочку, из которой уже можно запускать программу
— Так если она все собирает и можно программу запускать, зачем maven нужен?)
— Она не собирает само приложение, так как не знает всех зависимостей. Поэтому нужна отдельная программа-сборщик кода.
— А в чем тогда смысл собирать ресурсы?
— Ну, например, для запуска автотестов. Когда мы их запускаем, там не используется полностью варник (приложение cats.war). Там вызываются конкретные функции + используются конкретные ресурсы типа справочника телефонных номеров.
Разработчик исправил код и нажимает «Build». Это обновляет ресурсы, которые используются в тестах. А если тебе нужен варник приложения, то собираешь maven-ом (ну или аналогом).
— Диалог правильный, но это подход 10-летней давности. Сейчас всё делегируют maven/gradle. В IDE даже галочка есть отдельная для этого. А уже в maven/gradle делаются гранулярные цели для каждой задачи.
— А вообще главное отличие сборщика от IDE — сборщик можно запустить из командной строки, на любом окружении, независимо от среды разработки + в CI/CD системе (TeamCity, Jenkins и тп). Это воспроизводимый билд.
То есть при желании IDEA можно настроить, чтобы она все это делала. Прописать все зависимости и другое, но это будет нерасширяемо.
Как работает сборщик
Сборщики работают примерно одинаково. Базовый функционал:
компилировать код (проверять на простейшие синтаксические ошибки)
создавать и удалять директории
Есть и более продвинутые программы, которые также позволяют автоматически извлекать зависимости в библиотеке или автоматизировать тестирование.
Как сборщик поймет, что именно от него нужно? Благодаря скрипту компоновки. В нем разработчик описывает, что конкректно сборщик должен делать.
Давайте посмотрим, как такой скрипт выглядит, на примере Ant. Ant — инструмент компоновки для Java-проектов.
Файл компоновки Ant — это XML-документ. Он разбит на 4 основные части:
В каждом файле компоновки есть проект, и хотя бы одна (умолчательная) цель. Внутри цели находятся задачи — что именно системе надо сделать, если вызвана данная цель.
Проект
Всё в файле является частью проекта. Поэтому тег
является корневым в скрипте:
default — умолчательная (дефолтная) цель, срабатывающая при запуске скрипта.
Внутри проекта уже находится все остальное — цели, которых мы хотим достичь, и конкретные действия для их достижения.
По-хорошему, у проекта должно быть имя и умолчательная цель. Хотя согласно официальной документации, эти параметры не являются обязательными.
Дефолтная цель сработает по умолчанию, если при запуске ant не указана другая. Поэтому в ней должно быть все нужное для работы проекта.
Свойства
Свойства Ant похожи на константы. Один раз указали значение, и используем в скрипте хоть в 20 местах. А если значение изменилось, исправить надо будет одно место, а не двадцать. Сюда очень хорошо выносить версии продукта и зависимых библиотек, а также пути к директориям.
Записываются свойства в теге
У каждого свойства есть:
значение — value, или место — location (если указываем путь к директории)
Цель — это то, что мы хотим получить от сборщика. Краткое название для «я хочу скомпилировать проект» или «я хочу создать все нужные папочки».
Цели записываются в тегах :
Основные атрибуты цели:
name — имя цели, которое мы будет указывать в командной строке, поэтому лучше делать его коротким. Обязательный параметр.
description — описание цели. Выводится при запросе информации по проекту.
depends — от кого эта цель зависит. То есть какую цель надо запустить перед выполнением текущей. Необязательный параметр
В примере цель ”build” зависит от цели ”compile”. Мы не можем начать сборку билда, пока не скомпилировали его. Поэтому, если мы вызываем ant с целью сборки билда, то он:
Выполнит цель ”compile”
Выполнит цель ”build”
То есть за один присест можно выполнить сразу несколько целей, если прописать их в блоке depends. В данном случае мы вызвали одну цель, а выполнили две. Можно ли выполнить больше? Можно ли указать сразу несколько зависимостей? Да! Для этого надо записать имена целей через запятую в блоке depends:
Обратите внимание на граф вызова целей. Исходно мы хотим выполнить цель D. Читая атрибут depends, можно подумать, что первой будет вызвана цель C, потом B, и потом A. Это не так! Читать блок depends надо так:
Таким образом, сначала мы вызываем цель A, потом B, и только потом C. То есть фактически читаем справа налево этот атрибут.
У цели могут быть и другие атрибуты. Например, условие «if». Но подробнее о них читайте в официальной документации Ant — статья «Targets».
Цель по умолчанию
Какой должна быть цель по умолчанию? Должна ли проводиться компиляция, группировка, генерирование документации или все вместе?
Это зависит от проекта. Если кто-то берет код с сервера, что он будет с ним делать? Захочет посмотреть на проект и будет ожидать, что он запустится за один шаг? Если так, целью по умолчанию будет выполнение всех операций.
Но для выполнения всех операций надо использовать ключи шифрования, установщики типа InstallShield и т.д. Стоит ли париться? Многие ставят целью по умолчанию вывод справки по проекту, чтобы новые люди сообразили, что им нужно делать.
Задачи
Задача — это конкретное действие, которое нужно выполнить, чтобы достичь поставленной цели. Например, создать директорию, скопировать файлы, скомпилировать Java-код.
В Ant задача обычно отражает определенную команду: «javac», «mkdir» или даже «javadoc». Именно эта команда и будет названием тега:
Внутри цели может быть одна задача. Например, для компиляции проекта нам нужно скомпилировать java-код в конкретной директории:
При вызове цели compile будет вызвана задача javac. Она компилирует код java в srcdir и складывает классы в destrdir.
Внутри цели может быть несколько задач, как одинаковых, так и разных. Например, мы хотим создать все нужные проекту директории, а их несколько. Вызываем несколько раз задачу mkdir. Она создает директорию, определяемую атрибутом dir:
При вызове цели init у нас будут созданы 2 директории — ”bin” и ”lib”.
Возможно, нам надо не только создать директорию, но и подложить в нее какой-то файл. Тогда задачи будут разные.
Стандартная версия Ant содержит более 150 заданий. Вот некоторые из них:
echo – вывод сообщений в консоль
mkdir – создание директорий
copy — копирование файлов
delete – удаление файлов и директорий
move – перемещение файлов и директорий
replace — замещение фрагментов текста в файлах
javac – компиляция Java–кода
java – запуск class и jar файлов
jar – создание jar файла
junit – запуск тестов
exec — выполнение внешней команды
zip — создание архива в формате Zip
Доп ссылки
Writing a Simple Buildfile — официальная дока на английском
Как запустить сборку
Все зависит от сборщика. Но обычно это название сборщика + название цели, которую мы запускаем. Для Ant это выглядит так:
Целей может быть несколько:
Фишка ant в том, что вы можете назвать цель как угодно:
С одной стороны, это звучит даже забавно:
И все вокруг знают, что это означает пересобрать проект. Но такие хиханьки-хаханьки хороши лишь в умеренных дозах. Подумайте сами — если каждую цель назвать как-то «невпопад», то придется просто заучивать эти названия. Что неудобно.
А уж если в коллектив придет новый человек, то ему придется пояснять, почему используются такие загадочные названия и почему ему надо их выучить.
Поэтому обычно используют стандартные названия целей
clean — чистка проекта: удаление файлов заготовок, которые остаются после компиляции. Приводит проект к виду, в котором он хранится в репозитории
compile — компиляция исходного кода
test — запуск тестов
install — установка пакетов в локальный репозиторий, чтобы использовать зависимости от других проектов локально
Посмотрим на примере, который можно взять и пощупать — в проекте folks используется сборщик maven. А в статье «Как собрать проект и запустить тесты» (в старой версии, там возникли проблемки со сборщиком после обновления и команды заменили) мы видим такие команды:
Эти команды — типовые для maven-а. Давайте разберемся, что они означают.
Это сокращение от maven. Название сборщика, к которому мы обращаемся.
Первое слово, которое вы пишете в командной строке — это вызов команды. Это может быть путь к самой программе вида:
А может быть просто название команды:
В этом случае система (я говорю про винду) полезет в PATH и проверит: а есть ли там такое? Если есть, то запустит программу и по короткой команде. Подробнее про PATH можно почитать здесь.
Когда вы устанавливаете maven (ant или любой другой сборщик), вы прописываете путь к нему в переменную PATH. По крайней мере, в инструкции по установке есть такой пункт. Именно благодаря этому пункту команда «mvn» в командной строке начинает работать.
По сути, тут все то же самое, что и в ant — мы пишем название сборщика (mvn) и те цели, которые мы хотим запустить. Точнее, фазы. В maven это называется phases, и набор фаз вполне определенный. В этом отличие сборщиков, ant более гибкий и цели мы можем настраивать и называть так, как захотим. В maven не можем.
clean
В обеих командах сначала вызывается фаза clean. Она нужна для того, чтобы очистить созданные другими сборками артефакты. Так как я тестировщик, то объясню с точки зрения тестирования.
Допустим, мы запускаем автотесты. Их можно запускать пачкой (вообще все или из конкретной папки), а можно запускать один конкретный. Во время прогона система создает артефакты — это может быть состояние базы данных или поискового индекса, временные файлики, или что-то еще.
Теперь, когда мы просто запускаем тест, без clean, система переиспользует созданные артефакты. И это хорошо! Потому что так тесты гоняются намного быстрее. Система уже не тратит время на повторное создание артефактов.
Это как если у вас перед готовкой пустой холодильник или полный. Если пустой — надо идти в магазин. Если вы уже вчера туда сходили и продукты все есть, можно сразу приступать к готовке!
Да, переиспользование артефактов — это хорошо. Но иногда их надо почистить. Вот, скажем, если у вас яйца протухли, то и омлет станет отравой, и шарлотку есть будет нельзя. Любое блюдо будет испорчено из-за одного плохого ингредиента. Баг в исходнике «сломал» готовый продукт!
Что мы делаем в таком случае? Испорченные яйца выкидываем, идем в магазин за новыми. Примерно так и работает clean — чистит наш холодильник. Единственная проблема — она чистит всё. Удалять так удалять!
Фаза удаляет все артефакты, созданные предыдущими сборками. То есть система возвращается в состояние на момент забора данных из репозитория. Плюс твои локальные изменения кода (именно исходного кода, а не сгенеренных по нему артефактов).
Фазу можно и не вызывать, но это надо делать с полным осознанием своих действий. Чтобы потом не тупить над тем, почему это вдруг разработчик исправил баг и у него все хорошо, а у вас до сих пор плохо.
Понимаете, часто повторяющиеся действия мы делаем на автомате, не задумываясь о них. Допустим, что мы привыкли утром очищать свой репозиторий и прогонять
А потом, в процессе дня, мы фазу clean уже не вызываем:
Так вот, в коде обнаружился баг, который из кода «переехал» в артефакты. Разработчик баг исправил, даже проверил у себя локально — работает! Отдает вам, вы пересобираете проект — не работает! Как так?? Вы же пересобрали! Ведь вызвали же фазу «install».
При этом иногда над простыми ошибками тупят дольше всего. Разработчик снова ковыряется в коде, тратит время — должно же работать. Вы снова собираете — нет, не работает! И только когда разработчик приходит посмотреть, что именно вы делаете, он обращает внимание на команду:
— Стой! Ты же clean не делаешь!
— Ну да, я его только по утрам вызываю.
Это называется «делать на автомате», не задумываясь о своих действиях. Если вы не хотите думать над командой по сборке, то всегда вызывайте clean, не прогадаете. Да, сборка чуть дольше будет идти, но вы точно не огребете такую проблему.
Аналогичная ситуация может возникнуть при прогоне автотестов. Прогнали один тест — все хорошо, он работает. Прогоняете другой — он падает, причем очень странно. Тест пишет, что ожидает «Иванова», которого в вашем тесте нет вообще! Откуда же он взялся??
Да просто первый тест не почистил базу за собой! И Иванов остался в артефактах. А вы не вызвали фазу clean для экономии времени. Отсюда и баг. Поэтому при подозрительных падениях тестов из серии «откуда он взял эти данные» стоит перепрогнать тест с фазой clean.
install
Это сборка продукта. Folks нельзя развернуть и потыкать, но если бы можно было, то это выглядело бы именно так:
Скачали исходный код продукта
Выполнили команду «mvn clean install»
Забрали готовый билд в определенной папочке!
Хотя по сути своей фаза install ничего не собирает. Она публикует собранный артефакт в локальном репозитории. Смотрите — в maven есть свой жизненный цикл (подробнее см в статье «Maven in 5 Minutes», раздел «Maven Phases»):