Позвольте мне кратко поговорить с вами об угловом тестировании.
Как вы разрабатываете свои угловые приложения для тестирования?
Как вы разрабатываете тесты для вашего углового применения?
Как вы выполняете тесты и убедитесь, что
ваше угловое приложение удовлетворяет всем тестам, которые вы написали
, даже когда вы разрабатываете свое угловое приложение?
Теперь здесь я бы также кратко рассказал о
тестовой разработке угловых приложений.
Интересно, что угловой сам был построен с самого основания, чтобы позволить тестирование,
быть частью вашей разработки углового приложения.
Основной силой углового Misko Хевери был сам инженер по тестированию Google и, следовательно,
его влияние на проектирование угловых, чтобы быть проверяемым с
заземления можно легко увидеть по всему каркасу.
Итак, угловой сам по себе, как вы поняли из предыдущих лекций и упражнений,
является модульным по своему характеру.
Таким образом, модули угловых вместе с компонентами и
их шаблоны, а затем услуги и трубы и директивы
означают, что угловой легко поддается испытанию.
Теперь, поскольку угловое приложение само состоит из этих различных частей,
вы можете сначала протестировать каждую из этих частей изолированно
даже до того, как они станут частью всего углового приложения.
Второй аспект - это механизм инъекции зависимостей, который угловой использует
для поддержки комбинации различных частей
ваше угловое приложение само означает, что вы можете легко заменить mocks
для этих зависимостей в пределах
ваших различных частей углового и проводить испытания.
Я использовал слово mock в,
в предыдущем предложении придет понять
, что в немного более подробно и более, что, позже слайды.
Именно здесь мы должны знать
подход к разработке приложений, называемый тестовым развитием.
В тестируемой разработке, как вы можете понять по собственному имени,
означает, что вы сначала пишете автоматизированные тесты для
все функции, которые вы хотите реализовать в своем приложении.
Итак, сначала приходит тест,
после этого вы пишете код приложения, чтобы пройти тест.
Таким образом, сам тест определяет, какую функциональность вы хотите реализовать.
После этого вы пишете код для реализации этой функции.
Поскольку у вас уже есть тест на месте,
вы можете проверить, удовлетворяет ли реализация, которую вы делаете, тест или нет.
Теперь, конечно, как только ваша реализация вашей функциональности удовлетворяет тест,
вы всегда можете реорганизовать код в соответствии с их стандартами разработки программного обеспечения.
Но даже после этого
вы можете повторно проверить код, чтобы убедиться, что он по-прежнему удовлетворяет
требованиям, указанным в
, что конкретный тест, который вы используете в своей тестовой разработке.
Таким образом, разработка на основе тестирования является
очень жизнеспособным подходом к разработке
хорошего приложения с самого основания, чтобы быть полностью протестированы.
Теперь, когда мы говорим о тестировании,
вы можете подойти к тестированию с нескольких различных аспектов.
Прежде всего, что если ваше приложение
само реализовано как различные части,
как компоненты, такие как услуги, как директивы,
, как трубы, которые вы реализуете в своем приложении.
Это означает, что вы можете легко протестировать каждый из этих отдельных блоков изолированно.
Так вот где на первый план выходят модульные тесты.
Unit test означает, что вы тестируете отдельные единицы кода,
убедившись, что этот конкретный единичный блок
удовлетворяет функциям, которые он должен поддерживать,
и что функциональность и логика внутри этого фрагмента кода реализованы правильно.
Теперь изолируя блок и тестируя его очень,
очень полезно выяснить большинство начальных проблем в вашем,
в вашем коде, а затем исправить их даже до того, как вы интегрируете этот патч в код.
Теперь, как только вы начинаете интегрировать эти части в целое,
становится еще более громоздким, чтобы иметь возможность проводить детальные тесты вашего кода.
Таким образом, изолированные модульные тесты образуют первую строку
защиты от ошибок, когда вы разрабатываете свое приложение,
конкретно ваше угловое приложение.
Теперь, как мы видим с угловым,
мы имеем четкое разделение между угловыми компонентами и самим DOM.
Таким образом, внутри компонента, например, есть
логика вашего компонента полностью реализована в
код машинописного кода, который вы реализовали в компоненте, который машинописные файлы.
И тогда сам DOM управляется через
шаблон, который вы разработали для вашего углового компонента.
Итак, Бета сама, вы видите четкое разделение между ними.
Таким образом, вы можете просто проверить только логику
вашего кода компонента без написания вертикального шаблона.
Но тогда вы также могли бы рассмотреть оба вместе, а затем оценить эти аспекты.
Как мы увидим в упражнении, которое следует за этой лекцией,
мы фактически сделаем оба этих подхода.
Мало того, что угловая использует инъекцию зависимостей
, означает, что вы можете вводить макетные зависимости в своем приложении.
Когда я говорю mock, я имею в виду, например,
, если ваш компонент зависит от конкретной службы, вы всегда можете реализовать
макет службы, который имитирует поведение службы
, а затем заменить на место во время тестирования компонента, чтобы вы могли сохранить
ваш компонент независимо от того, как сервис фактически реализован.
До тех пор, пока интерфейс между вашим компонентом и сервисом правильно спроектирован
, вы можете заменить макетный сервис на месте и по-прежнему тестировать свой компонент.
Там, из макета,
вы можете легко контролировать, что поставляется компоненту из сервиса.
Таким образом, этот подход позволяет вам выполнять модульное тестирование
в деталях в вашем угловом приложении.
Вот где доступность тестовых фреймворков типа «Жасмин».
Так что Jasmine предоставляет
управляемая поведением среда тестирования, которая полностью разработана в JavaScript.
Теперь эта структура Jasmine является общей структурой, которая
доступна для тестирования любых приложений JavaScript.
Angular принимает Жасмин в качестве подхода для определения наших испытаний для других угловых деталей,
их компонентов, услуг и различных аспектов нашего углового применения.
Теперь, в Жасмин, Жасмин использует две вещи, которые приходят вам на помощь.
Одним из них является использование функции «описать».
Функция «описать» позволяет сгруппировать набор тестов, а затем
выполнить эти тесты вместе как одну группу тестов.
Когда мы пишем код в упражнении, вы увидите меня
, заключая набор тестов внутри функции описания.
Затем мы пишем наш код для нашего,
код Жасмина, для наших угловых тестов.
Теперь в этих «описать» функциях вы также будете использовать то, что называется «это» функции.
Функции «it» позволяют указать
индивидуальные тесты, которые вы хотите выполнить на вашем угловом приложении.
Так вот где вы увидите, что я указываю «это», а затем укажите, что
характер конкретного теста, а затем
дизайн кода для этого конкретного теста с помощью функции «it».
Так как мы разрабатываем код в упражнении, обратите внимание на «описание» и
«это» в ваших угловых тестовых приложениях.
После того, как вы разработали тест с Jasmine фреймворком,
Karma представляет собой инструмент командной строки на основе JavaScript
, который позволяет выполнять эти тесты автоматически.
Now, Karma вместе с Жасмином,
позволяет вам проводить испытания для вашего углового применения.
Теперь с Karma, что поддерживает Karma,
заключается в том, что он позволяет создавать
веб-сервер, в пределах которого вы загружаете исходный код приложения и
затем Karma использует браузер для проведения фактических тестов ваших различных единиц.
Итак, это где, когда вы запускаете тесты с помощью Karma,
вы увидите, что Karma укладывает браузер,
является ли это окном браузера существующего браузера или
, будете ли вы использовать что-то под названием PhantomJS, которое запускает
фантомный браузер за кулисами для проведения теста.
Это не имеет значения, но Karma использует
браузер в один момент, чтобы провести тест для вашего углового приложения.
Как вы увидите в упражнении, которое следует,
это где, если один из ваших коллег продолжает настаивать на том, что его или ее реализация
конкретный кусок вашего углового приложения является
правильным и продолжает подчеркивать точку,
вы всегда можете разработать несколько тестов, используя Жасмин и
Карма, а затем провести тесты и в случае неудачи тестов,
вы всегда можете опровергнуть их аргумент.
Так вот, когда вы можете повернуться,
обернуться к своему коллеге и сказать:
моя Карма наехала на вашу догму.
Теперь, конечно, ваши угловые приложения не полностью лишенные
вовлеченности самого углового каркаса.
Ваш компонент не может быть спроектирован самостоятельно без
, используя многие функциональные возможности библиотеки, которые угловой обеспечивает для вас,
хотя некоторые из основных логики могут быть протестированы независимо от угловых.
То, что мы называем изолированными тестами.
Но, все больше и больше,
вы обнаружите, что если вы в,
хотите, чтобы угловая рама поддерживает себя вы
не сможете выполнять большую часть теста
ваших угловых частей, будь то компоненты или услуги или трубы или директивы.
Таким образом, здесь утилиты углового тестирования предоставляют
тестовую среду, которая позволяет выполнять
модульные тесты в пределах вашего углового приложения.
Так что угловые утилиты тестирования, как вы увидите меня, используя в упражнениях,
в самом следующем упражнении,
предоставит нам определенные реализации угловой функциональности, которые вы используете
в ваших тестах для того, чтобы настроить среду, где вы можете выполнять их тесты.
Итак, вот где взаимодействие с угловой средой,
вместо использования реальных угловых реализаций,
вы будете использовать эти тестовые утилиты, которые обеспечат
достаточную функциональность, чтобы позволить вам проводить тесты.
И именно здесь TestBed, который мы будем использовать
в нашем угловом приложении, очень полезно.
TestBed по существу создает угловое тестирование модульной.
Как вы понимаете, ваши компоненты не существуют сами по себе.
Ваши компоненты должны быть включены в модуль NG.
Теперь вы не можете просто использовать стандартный модуль NG для проведения тестирования.
Так вот где TestBed,
, который поддерживается утилита углового тестирования,
предоставляет вам среду модуля NG, которая позволяет тестировать их компоненты.
Таким образом, в TestBed,
вы будете использовать что-то под названием TestBed Create Component для создания
отдельного компонента и экземпляра компонента для выполнения тестов на этом.
И когда вы делаете это
TestBed дает вам доступ к что-то под названием ComponentFixture,
ComponentFixture это то, что предоставляет вам ручку, которая позволяет окружить
ваш компонент с достаточной функциональностью, что компонент может быть протестирован сам по себе.
Прибор обеспечивает доступ к самому компоненту и
, то также через это мы будем использовать что-то под названием DebugElement.
Вы увидите, что я использую это в следующем упражнении.
DebugElement предоставляет вам доступ к DOM,
, который является шаблоном, который поддерживается как часть вашего компонента.
Таким образом, вы можете делать манипуляции с DOM, такие как щелчок элементов в DOM,
получение доступа к элементу DOM, а затем чтение того, что заключено
внутри этих элементов Dom и так далее, что позволит вам выполнять тесты.
Теперь, прежде чем мы перейдем к упражнению,
я хочу, чтобы вы знали о некоторых из этих вещей, так что, когда мы столкнемся с ними в
само упражнение, вы увидите, почему я использую каждую из этих различных частей.