Ответы пользователя по тегу Тестирование ПО
  • Чем отличаются интеграционное, unit и e2e тестирование на frontend?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Как в юнит тестах тестить нажатие на кнопку? Или мы можем тестить только функцию-обработчик?


    В юнит тестах вы можете тестировать контроллер компонента, что мол он нужное состояние выставляет. DOM проверять не нужно. Механизм биндингов и так хорошо покрыт юнит тестами на уровне фреймворка. Чаще юнитами покрывают сервисы, ресолверы и прочее. Ими проверяют логику работы отдельных маленьких кусочков.

    в интеграционных можно уже потихоньку проверять DOM отдельных компонентов. Просто потому что вы могли опечататься при написании биндингов. Ну то есть цель интеграционных тестов - проверить что в сборке компоненты работают.

    В e2e (end to end) вы загружаете все приложение целиком и имитируете действия пользователей. Причем взаимодействие происходит насквозь. От кнопочки в браузере до запросов в базе данных на сервере (если есть бэкэнд). Это самый медленный вид тестирования и им стоит покрывать только позитивные сценарии.

    Читать про пирамиду тестирования.
    Ответ написан
  • Зачем тестировать код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.


    вы должны проверять корректность работы системы. Всего-то. Причем с оглядкой не только на "сейчас" (тут мы и руками можем проверить быстро) но еще с оглядкой на будущее. Если вы планируете этот код выкинуть - тестировать его нет смысла. Вы на автоматизацию тестирования убьете больше времени чем проверите руками.

    С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.

    Далее уже все зависит от сложности тестирования. По хорошему наши тесты должны быть маленькие и, главное, ничего не знать о деталях реализации. Скажем вы хотите проверить что система корректно добавляет новости. Самый простой способ это проверить - создать новость и проверить что не вернулись ошибки. Для этого можно составить HTTP запрос и получить HTTP ответ. Максимально просто.

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

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

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

    По сути это самое сложное в тестировании. Писать тестируемый и поддерживаемый код, а так же останавливать себя от тестирования "лишних" частей системы или слишком углубляться в тестирование там где этого не нужно.
    Ответ написан
  • Как в angular тестировать логику с данными, которые приходят с сервера?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) запихиваем $http в сервисы
    2) мокаем эти сервисы
    3) сами сервисы работающие с сетью либо тестируем в рамках e2e тестов либо через $httpBackendMock. Но юнит тестами покрывать их смысла особо нет.
    Ответ написан
  • Что такое автотесты кода и какие они бывают?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    логика простая. Вы же как-то проверяете что все работает? А теперь представьте что вы написали программу которая делает это за вас и она дает два результата - работает (зеленое) или не работает (красное).

    Тесты можно писать на разных уровнях. От отдельных модулей вашего приложения (масые маленькие кусочки) до всей системы (вся многопользовательская игра). Далее подключаем здравый смысл. Мы сначала должны убедиться что каждый отдельный компонент системы работает, а затем проверять как работают компоненты в сборе.

    Далее гуглите.
    Ответ написан
  • Способы тестирования проекта, имитируя несколько тысяч пользователей?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    называется "нагрузочное тестирование".

    Пишем сценарии, имитирующие действия пользователей. Почти все популярные решения для нагрузочных тестов (например jmeter) имеют прокси-рекордеры, которые позволяют записывать ваши действия.

    Затем мы берем несколько серваков и пуляем с них запросами на наш сервер. Ну или покупаем подписку к сервисам. Благо их много.
    Ответ написан
  • Механизм для модульного тестирования без базы данных?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Просто введите репозитории, и будет вам счастье. Внутри используйте AR, снаружи все будет чисто и красиво.
    Ответ написан
  • Какой язык выбрать для автоматизации тестирования?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Все зависит от того что вы будете тестить. Если вы будете писать E2E тесты то лучше взять простенький динамический язык, и не PHP, хотя конечно можно и его.

    Я бы рекомендовал вам посмотреть в сторону python или javascript (ruby тоже можно, с капибарой какой, просто python универсальнее).

    Так же немаловажно учитывать на чем написан проект который вы собираетесь покрывать тестами. Если у вас есть люди в команде которые помогут вам с программированием то это несомненнно будет плюсом.
    Ответ написан
  • Behat или Codeception и почему?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Behat не совсем для тестирования, Codeception исключительно для тестирования.

    Если ваша команда записывает требования в терминах Given-When-Then и загоняется по BDD, то выбор очевиден - Behat. Есть еще команды которые заставляют писать функциональные тесты своих тестировщиков и для этого используют gherkin-сценарии. Если вам надо просто покрыть все функциональными тестами то Codeception (или любой другой фреймворк, я вот peridot использую для этих целей).
    Ответ написан
  • Как в Angular тестировать темплейт контроллера при использовании vm?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Все просто - не тестируйте контроллеры. У вас там в принципе не должно быть кода который бы вы хотели потестить. Контроллеры как отдельные сущности не имеют шаблонов, вообще. Единственный случай когда это допустимо - контроллеры директивы, тут у нас есть определенные шаблоны. Но опять же, тут мы будем тестить именно директиву.

    Вы так же можете потестить контроллер напрямую дергая его методы, что предпочтительнее, так как с controller as синтаксисом мы избавляемся от такой вредной зависимости как $scope.
    Ответ написан
  • Что лучше начать изучать для тестирования js кода (AngularJS, jQuery)?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    тест помогают если они нормально написаны. Например если нет моков апишки, если у вас это есть - беда, обычно все выносится в сервисы и мокается, хотя я не особо люблю такое тестить.

    e2e тесты сильно помогают, но я использую для них cucumber.js + protractor, точнее только начинаю.
    Ответ написан
  • Считается ли правильным тоном создавать тестовые объекты если нет возможности создать моки?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    вы можете замокать __get метод и таким образом затрэкать обращение к свойству и вернуть необходимое значение. Но в целом публичные свойства для объектов типа ConnectionInterface это уже странно.
    Ответ написан
  • Что не так с резюме?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Мало букв в резюме. Под такое описание подпадают тысячи кандидатов. У вас расписаны стандартные навыки стандартного манки-тестера. Если реально больше знаний нет (процессы внутри команды, методологии и прочее) то хотя бы можно было бы расписать функции которые вы выполняли на других должностях и т.д.

    Слышали анекдот про HR-ов?


    Сидит опытный HR и HR-стажер. Перед ними пачка резюмешек на рассмотрение. Опытный отсчитывает половину стопки и выкидывает в мусор. Стажер в шоке:
    - Василий Степаныч, как же так то?
    - Ай... Нам не нужны неудачники.
    Ответ написан
  • Как организовать бенчмарк?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    нагрузочные тесты для hello world несколько бесполезны. Да и делали их уже 100 раз (не нагрузочные тесты а простые бенчмарки)
    Ответ написан
  • Есть ли инструменты обновления браузера на события изменения файлов (html, php, js, etc)?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    https://www.npmjs.org/package/gulp-webserver - рекомендую. Так же webstorm/phpstorm имеют на борту плагин LiveEdit. Это если вы хотите обойтись без node.js
    Ответ написан
  • Что представляет собой тестирование ?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Вообще вики можно для начала, а потом уже углубляться в литературу. Вот вам кратенькое описание, цель которого больше предоставить ключевые слова для поиска.

    Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к phpunit. Так же есть такая методология разработки как TDD, советую почитать "Экстримальное программирование" Кента Бэка в этом ключе.

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

    Интеграционное тестирование - тестирование нескольких модулей в связке. То есть мы тестируем наш компонент или его самодостаточный кусок в реальных условиях. Если этот компонент для работы с файлами - разрешаем ему доступ к файлам. Если база данных - то даем реальное соединение с базой. А можем что-то и замокать. Это как говорится, зависит от задачи. Скажем обращение к сторонним апишкам стоит мокать и стабить. Главная цель этих тестов, удостовериться что модули вместе работают хорошо. Особенно важно это когда модули пишут разные люди.

    Функциональное тестирование - это тестирования всего приложения в сборе. Если это REST API, то у нас через curl дергаются реальные методы, отправляются более менее реальные запросы и валидируются ответы. Если web-страничка, то это UI тесты с силениумом/phantom.js/zombi.js или, если нам не нужно еще и js тестить, просто curl + какой виртуальный браузер на том же php. Вообще по хорошему функциональные тесты не допускают никаких моков и т.д. но опять же если очень хочется то можно (опять же обращение к сторонним сервисам, контроля за которыми у нас нету).

    Но реалии таковы, что UI тестами покрывать проект не слишком удобно. Вопервых UI может меняться, а поддерживать их так же нужно. Во вторых это скучно. В третьих тесты могут просто падать... вот взяли и упали. И потом начинается, так, тесты опять упали... что там упало? А, не страшно, можно релизить. Так же на больших проектах UI тесты отрабатывают долго, очень долго, некоторых их просто ночью гоняют. Толку от тестов при таком подходе не слишком много, ибо разработчику стоит знать о том что что-то сломалось как можно быстрее. А так он приходит, видит что тесты опять красные, чинит эти красные тесты, и запускает... ждет... проходит пол часа к примеру, и где-то в другом месте отвалилось... Короче сами понимаете.

    Приемочное тестирование - по сути те же функциональные тесты, но подаются в контексте фича-спеков. Если вы работали когда-нибудь с QA отделом, то возможно слышали про такие штуки как acceptance criteria. То есть это тот чек лист, который должен проверить тестировщик что бы удостовериться что все хорошо. На основе этого чек листа можно написать функциональные тесты. Так же есть инструменты вроде Cucumber/Behat, которые позволяют писать спецификации в виде стэпов. В этом случае спецификации для этих инструментов могут писать QA а вы просто имплементите для них степы. То есть уменьшается прослойка между "acceptance criteria" и готовыми к выполнению тестов. Более того, стэпы можно реюзать, комбинировать, масса стэпов есть готовых, вам же необходимо только предоставить стэпы подготвалливающие систему (загрузка/генерация фикстур и т.д.). Короче лепота и удобно. Но медленнее интеграционных, зато не такие жесткие как функциональные, за счет этого их проще поддерживать. QA пишут спеку, реализуем тесты под эту спеку, пишем код под тесты, тесты зеленые - функционал готов.

    Ну и есть еще всякие термины типа пирамида тестов и т.д. Мол лучше много юнит тестов, чуть поменьше интеграционных и мало функциональных. Тогда тесты выполняются быстрее, а покрывать все и вся функциональными тестами обычно перебор.

    Ну и опять же, есть такая вещь как здравый смысл. Некоторые вещи скажем можно вообще забить и не покрывать тестами, некоторые стоит покрыть. Некоторые не полностью, некоторые с как можно большим покрытием.... Скажем тестить UI (именно как выглядит, где какой элемент) вообще бессмысленно. На это нужно куча ресурсов. Хотя может и есть проекты где это оправдано.

    Короче почитайте про TDD и ATDD (можно и BDD затронуть, но тут не только от программиста зависит, менеджеры, заказчик или продукт-оунер тоже должны быть вовлечены, по сути этот подход хорошо работает в рамках продукта какого-то, на фрилансе и в аутсорсе редко можно встретить) , Continious Integration и Continious Delivery.
    Ответ написан
  • Как проверить сайт на retina экране?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    в дебагере хрома можно выставлять плотность пикселей в разделе эмуляции экрана.
    Ответ написан
  • Какой есть недорогой и удобный способ тестирования web-сайта на Safari под Mac?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    spoon.net/apps/safari-5.1 - попробуйте.

    Вообще это реально единственный вариант, воспользоваться каким-нибудь облачным сервисом, который предоставляет стримминг ПО. То есть на сервере с Mac OS запускается Safari и можно тестить. Подобные сервисы будут обходиться вам не дороже $20 в месяц.
    Ответ написан
  • На каких ресурсах можно поизучать тестирование в PHP?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Почитайте в принципе про тестирование, есть масса литературы. Привязка к языку тут не особо нужна.

    Почитайте документацию к PHPUnit, там хорошо написано. Есть так же частичный перевод (чуть старый).

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

    Если вас интересует TDD - почитайте "экстремальное программирование" Кента Бэка. Мне очень понравилась подача материала в этой книге. Там же про рефакторинг в контексте TDD хорошо расписано.

    Если вас интересует BDD - behat.org
    Ответ написан