Поговорим о том, когда, как и для чего писать тесты, а так же научимся проходить интервью на позицию junior test automation engineer. Подумаем над тем, почему TDD не взлетает, и может ли что-то быть хуже. Рассмотрим на примере использование таких инструментов, как NUnit, FluentAssertions, Moq, HttpMock.
Фофанов Илья - Лучшие практики проектирования и реализации API на C#Elias Fofanov
C# – мощный и красивый объектно-ориентированный язык. Но мощь сама по себе не гарантирует, что всё написанное вами на C# будет эталоном. "Кривой" код встречается даже у опытных программистов, особенно если они пришли с других языков и платформ . И ладно бы некрасивости были связаны с реальными сложностями. Нет же! Кривизна возникает и в таких простых вещах, как именование элементов в соответствии со спецификацией языка C#. Многие не умеют выбрать между структурой и классом, не отличают команду от запроса и так далее. Если хотите, чтобы коллеги любили ваш код – этот вебинар для вас! Мы разберем:
- Принципы именования классов, переменных и т.д.
- Как выбрать между классом и структурой.
- Как выбрать между абстрактным классом и интерфейсом.
- Как выбрать между методом и свойством.
- Чего не стоит делать в конструкторе.
- Когда фабрика лучше конструктора.
- Как реализовать паттерн Dispose.
- Признак «одержимости примитивами».
- Скрытые зависимости.
- Нарушения закона Деметры.
- ВременнАя связанность.
- Когда хорош Switch-Case.
В первую очередь вебинар будет полезен:
– начинающим со знанием основ C# (без минимального знакомства с языком не все будет понятно),
– тем, кто переходит на C# с другого языка.
В некоторых разделах даже middle-девелоперы могут найти для себя что-то новое.
Поговорим о рефлексии в C++, о том, что это такое, для чего нужно и почему это вообще важно. На практическом примере с котами рассмотрим эволюцию подходов к рефлексии в рамках разных версий языка: C++03, C++11/14, C++17. Посмотрим на то, что для нас готовят разработчики нового стандарта, узнаем где и как можно "пощупать" эти новые возможности. Поделимся полезными утилитами и подходами, которые облегчат жизнь пока эти новые возможности не придут к вам на проект.
Тестируем тесты с PIT (мутационное тестирование)Vitebsk Miniq
Презентация подготовлена по материалам выступления Евгения Барановского на витебском Dev Day MiniQ (https://vk.com/devdayminiq), который был проведен 15 сентября 2016.
Модульное тестирование является неотъемлемой частью современного процесса разработки. В своем докладе я хочу поговорить о том как нужно разрабатывать модульные тесты в проекте на C++ так чтобы это приносило максимум пользы.
В лекции рассказано о доступных средствах по отладке веб-сайтов, их возможностях, а также способах их использования. Также речь пойдет о том, как искать ошибки у пользователей в продакшене и контролировать качество продукта.
Фофанов Илья - Лучшие практики проектирования и реализации API на C#Elias Fofanov
C# – мощный и красивый объектно-ориентированный язык. Но мощь сама по себе не гарантирует, что всё написанное вами на C# будет эталоном. "Кривой" код встречается даже у опытных программистов, особенно если они пришли с других языков и платформ . И ладно бы некрасивости были связаны с реальными сложностями. Нет же! Кривизна возникает и в таких простых вещах, как именование элементов в соответствии со спецификацией языка C#. Многие не умеют выбрать между структурой и классом, не отличают команду от запроса и так далее. Если хотите, чтобы коллеги любили ваш код – этот вебинар для вас! Мы разберем:
- Принципы именования классов, переменных и т.д.
- Как выбрать между классом и структурой.
- Как выбрать между абстрактным классом и интерфейсом.
- Как выбрать между методом и свойством.
- Чего не стоит делать в конструкторе.
- Когда фабрика лучше конструктора.
- Как реализовать паттерн Dispose.
- Признак «одержимости примитивами».
- Скрытые зависимости.
- Нарушения закона Деметры.
- ВременнАя связанность.
- Когда хорош Switch-Case.
В первую очередь вебинар будет полезен:
– начинающим со знанием основ C# (без минимального знакомства с языком не все будет понятно),
– тем, кто переходит на C# с другого языка.
В некоторых разделах даже middle-девелоперы могут найти для себя что-то новое.
Поговорим о рефлексии в C++, о том, что это такое, для чего нужно и почему это вообще важно. На практическом примере с котами рассмотрим эволюцию подходов к рефлексии в рамках разных версий языка: C++03, C++11/14, C++17. Посмотрим на то, что для нас готовят разработчики нового стандарта, узнаем где и как можно "пощупать" эти новые возможности. Поделимся полезными утилитами и подходами, которые облегчат жизнь пока эти новые возможности не придут к вам на проект.
Тестируем тесты с PIT (мутационное тестирование)Vitebsk Miniq
Презентация подготовлена по материалам выступления Евгения Барановского на витебском Dev Day MiniQ (https://vk.com/devdayminiq), который был проведен 15 сентября 2016.
Модульное тестирование является неотъемлемой частью современного процесса разработки. В своем докладе я хочу поговорить о том как нужно разрабатывать модульные тесты в проекте на C++ так чтобы это приносило максимум пользы.
В лекции рассказано о доступных средствах по отладке веб-сайтов, их возможностях, а также способах их использования. Также речь пойдет о том, как искать ошибки у пользователей в продакшене и контролировать качество продукта.
The 3rd part of the 3rd lecture from the course "Java Core".
The Department of Information and Network Technologies.
St-Petersburg State University Of Aerospace Instrumentation.
Russia
The 2nd part of the 3rd lecture from the course "Java Core".
The Department of Information and Network Technologies.
St-Petersburg State University Of Aerospace Instrumentation.
Russia
The 5-th lecture from the course "Java Core".
The Department of Information and Network Technologies.
St-Petersburg State University Of Aerospace Instrumentation.
Russia
Все разработчики автоматизированных тестов рано или поздно сталкиваются с проблемой - "то, что есть в тулзе, которую я юзаю, явно не достаточно и надо что-то делать".
Мы поговорим с чего начать и чем продолжить, так чтоб получить действительно хорошее решение для автоматизированного тестирования. Обсудим интеграцию с continues integration и реализации систем репортинга. За опорный пример возьму фреймворк на базе Selenium.
The 3rd part of the 3rd lecture from the course "Java Core".
The Department of Information and Network Technologies.
St-Petersburg State University Of Aerospace Instrumentation.
Russia
The 2nd part of the 3rd lecture from the course "Java Core".
The Department of Information and Network Technologies.
St-Petersburg State University Of Aerospace Instrumentation.
Russia
The 5-th lecture from the course "Java Core".
The Department of Information and Network Technologies.
St-Petersburg State University Of Aerospace Instrumentation.
Russia
Все разработчики автоматизированных тестов рано или поздно сталкиваются с проблемой - "то, что есть в тулзе, которую я юзаю, явно не достаточно и надо что-то делать".
Мы поговорим с чего начать и чем продолжить, так чтоб получить действительно хорошее решение для автоматизированного тестирования. Обсудим интеграцию с continues integration и реализации систем репортинга. За опорный пример возьму фреймворк на базе Selenium.
КГТУ Лекция 6: Обеспечение Качества Программного Обеспечения Iosif Itkin
КГТУ - Костромской Государственный Технологический Университет
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Лекция 6: Обзор методов создания тестовых сценариев
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
TDD: когда нужно и, самое главное, когда не нужно / Павел Калашников (SimbirS...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 18:00
Тезисы:
http://backendconf.ru/2017/abstracts/2738.html
TDD - Test Driven Development. Разработка через тесты.
Очень многие знают про эту методологию, очень многие хотели бы использовать, далеко не все используют.
На этом докладе мы разберём:
* когда стоит использовать TDD в разработке проекта;
* когда НЕ стоит использовать TDD, потому что он будет мешать;
* несколько аргументов для тимлида, заказчика, PM и т.д., которые помогут разработчику продвинуть TDD в проект;
* о применении TDD в продуктовой разработке и в аутсорсе.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
Практический доклад о том, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование.
В докладе рассмотрены основные проблемы, с которыми команда столкнулась при внедрении и способы их устранения.
Продемонстрированы результаты, которых смогли достичь в течении полугода.
Доклад содержит большое количество лайфхаков и обзоров инструментария, который использовался для достижения цели.
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...solit
Зубович Вадим, Минск. Опыт в IT более 5 лет, работает в компании ISSoft, специализация: разработка (.NET C# ASP\MVC, WPF, WinForm, Java) и автоматизация функционального тестирования програмного обеспечения (Web, Desktop, Mobile) и тестирования производительности (Web).
«Сравнительный анализ инструментов для автоматизации тестирования мобильных приложений». Development секция. Отделение тестирования.
Мобильные платформы уже набрали огромную популярность, и продолжают наращивать обороты. Ни один разработчик уже не обходит стороной мобильные приложения и автоматизация тестирования в этой сфере актуальна как никогда.
В настоящем докладе мы рассмотрим наиболее популярные и перспективные инструменты для автоматизации тестирования приложений для мобильных операционных систем iOS, Android и WindowsPhone, проведем анализ их особенностей и возможностей, основываясь на опыте их использования в рамках реальных проектов, а также подведем общий итог с рекоммендациями по выбору того или иного инструмента.
«Централизованное управление тестами с помощью TestLink». Development секция. Отделение тестирования.
Эффективное управление тестами это не только грамотный тим-менеджмент, это еще и правильный учет, контроль результатов и своевременное и централизованное обновление информации о тестах для всех участников процесса и силами всех участников процесса.
Достичь этого невозможно без системы управления тестами, позволяющей эффективно распределить права и обязанности участников и обеспечить постоянное поддержание информации о тестах в актуальном состоянии.
TestLink – бесплатный инструмент, предназначенный именно для выполнения этой задачи.
В рамках доклада мы рассмотрим:
1. Как устроен TestLink
2. Как построить работу с TestLink
3. Как создавать информативные отчеты в TestLink
4. Как наладить связь между автоматизацией и TestLink
Любите ли вы велосипеды? Все разработчики любят свои ненаколеночныерешения велосипеды! И мы не исключение. В нашем докладе мы покажем как собирать, сколачивать, вылепливать собственный велосипед так, чтобы на нем потом могла ездить без слёз вся команда, компания, или может весь мир.
Что в докладе будет:
- много Spring Boot-а;
- live coding;
- создание собственного Spring Boot Starter-а;
- Apache Thrift в качестве подопытного кролика.
Чего не будет:
- бенчмарков и сравнений Thrift vs REST vs gRPC vs XXX.
Презентация со встречи QA Club Minsk 11 декабря 2013 г., посвященная одному из поппулярнейших инструментов тест-менеджмента Test Link, автор Вадим Зубович
Как построить свой фреймворк для автотестов?Dmitry Buzdin
Мы пройдемся по всем основным блокам построения тестового фреймворка и тому, как они связаны между собой. Вы научитесь собирать свое решение по автоматизации из библиотек с открытым кодом и делать так, чтобы они дополняли друг друга.
3. Сначала вопрос
Как можно тестировать? Результат – только видимые извне итоги
работы системы, не обладая знаниями о
реализации.
Поведение – система имеет зависимости,
взаимодействие с которыми можно
отследить и протестировать.
Контракты, интерфейсы, поверхность –
аналогично результату.
3
5. Когда тестировать
В ОБЩЕМ СЛУЧАЕ
Высокая стоимость ошибки
Поведение не очевидно
Требуется подтверждение результата
работы
АВТОМАТИЗИРУЯ
Высокая частота релизов
Контракты стабилизированы
CI
5
10. Основные артефакты
Тест план
◦ Назначение данного плана
◦ Что тестируется (система, модуль, билд, …)
◦ Описание рисков
◦ Тестируемые фичи
◦ Не тестируемые фичи
◦ Стратегия тестирования
◦ Критерии успешного и не успешного завершения тестирования
◦ Описание окружения
◦ …
10
IEEE 829
11. Зачем нужен план?
◦ Определяет цель тестирования
◦ Описывает стратегию и необходимый объём работ по тестированию
◦ Определяет объект тестирования
◦ Позволяет определить покрытие функциональных требований
◦ Ограничивает скоуп тестирования
◦ Описывает исходы тестирования и условия успешного прохождения тестирования
11
12. Тест кейс
• Название
• Тестируемые фичи
• Определение входных данных
• Определение результата выполнения
• Серьёзность и приоритет бага
• ...
12
15. Проблема
Когда закончить писать код?
Test-driven development требует определить критерий полноты выполнения требования до того, как
приступать к реализации.
15
16. Определим Объект тестирования
Web API, принимающий на вход дату и возвращающий интервал времени,
прошедший (или предшествующий) этой дате с Unix Epoch
Тестируем:
◦ Обработку входного параметра времени с указанием часового пояса
◦ Возможный интервал дат
Не тестируем:
◦ Обработку входного параметра без указания часового пояса
◦ Даты вне интервала допустимых значений
16
17. • DotNetMsk.10.DemoTestProject.Contracts – DTO
контракты нашего сервиса
• DotNetMsk.10.DemoTestProject.Client – реализация
клиента
• DotNetMsk.10.DemoTestProject – веб-сервис. Его
мы и будем тестировать
• DotNetMsk.10.DemoTestProject.IntegrationTests,
DotNetMsk.10.DemoTestProject.UnitTests – проекты
с тестами
• DotNetMsk.10.DemoTestProject.Tests.Shared –
общий код для тестов. В нём находятся
SeverityAttribute и PriorityAttribute классы
17
26. 26
[TestFixture]
public class TimerClientShould : IDisposable
{
private readonly IHttpServer _httpMock;
private readonly string _baseUrl;
public TimerClientShould()
{
_httpMock = HttpMockServer.LaunchTimeStub(ConfigurationManager.AppSettings["stub.baseUrl"]);
_baseUrl = ConfigurationManager.AppSettings["stub.baseUrl"];
_baseUrl.Should().NotBeNullOrWhiteSpace();
}
[Severity(Severity.Critical)]
[TestCase("2017-01-01T00:00:00.0000000Z", Description = "Basic positive test without time zone",
ExpectedResult = "17166.21:00:00")]
public async Task<string> CalculateTimestampFromStartOfUnixEpoch(string tillDate)
{
var sut = new TimerServiceClient(_baseUrl);
return (await sut.GetTimePassedTillDateAsync(DateTime.Parse(tillDate))).ToString();
}
public void Dispose() => _httpMock?.Dispose();
}
27. 27
public static class HttpMockServer
{
public static IHttpServer LaunchTimeStub(string baseAddress)
{
var result = new HttpServer(new Uri(baseAddress));
//Setup error routes for test purposes
result.SetupErrorStubMethod(HttpStatusCode.BadRequest)
.SetupErrorStubMethod(HttpStatusCode.Unauthorized)
.SetupErrorStubMethod(HttpStatusCode.NotFound)
.SetupErrorStubMethod(HttpStatusCode.UnsupportedMediaType)
.SetupErrorStubMethod(HttpStatusCode.InternalServerError)
.SetupErrorStubMethod(HttpStatusCode.NotImplemented);
//Setup actual methods
result.Stub(rf => rf.Post($"/{TimerServiceClient.GetTimePassedTillDateRoute}"))
.Return(JsonConvert.SerializeObject(new TimePassedResponse
{
TimePassed = TimeSpan.Parse("17166.21:00:00"),
StartingPoint = new DateTime(1970, 1, 1)
}))
.AsContentType("application/json")
.WithStatus(HttpStatusCode.OK);
result.Start();
return result;
}
}
28. Обо мне
.NET C# разработчик, тим лид
Skype: lleyte
Email: leyte@live.ru
Facebook: https://facebook.com/an.zaytsev
GitHub repo: https://github.com/zaytsevand/DotNetMsk
28
Editor's Notes
Это не совсем обычный мост – это летающий паром.
Для того, чтобы такой мост появился, нужно было сочетание нескольких факторов: достаточной зрелости технологий, потребности в транспортировке ограниченного количества людей и грузов с одного берега на другой, потребности в сохранении судоходной этой части реки.
Почему я решил начать рассказ с него?
Потому, что интеграция различных систем напоминает наведение мостов, потому что Addison Wesley обожают помещать фото мостов на обложки своих книг и потому, что этот мост до сих пор работает, что для меня является прекрасным примером успешности инженерного решения.
Результат – только видимые извне итоги работы системы, не обладая знаниями о реализации.
Поведение – система имеет зависимости, взаимодействие с которыми можно отследить и протестировать.
Контракты, интерфейсы, поверхность – аналогично результату.
Тестировать можно практически все части системы, систему в сборе, отдельные инсталляции, конфигурации.
Если не удалось разглядеть картинку с предыдущих слайдов, то её можно найти на гитхабе
S1 Блокирующая (Blocker)Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major) Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor) Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial) Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
P1 Высокий (High) Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium) Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low) Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Определим объект тестирования в коде.
Контракты;
Интерфейс;
Тест.
Вопрос: каким должен быть первый тест для Web API?
До того, как начинать функциональное тестирование, стоит убедиться, что наш сервис работает.
Этот тест по сути smoke – мы проверяем, что API отвечает.
Прохождение данного теста является критическим для определения работоспособности приложения.
Обратите внимания на проверки - они последовательно проверяют разные части ответа. Чем подробнее проверки, тем легче определить источник проблемы.
Для их написания я использовал пакет FluentAssertions, так как он приблежает написание ассерта к естественному языку.
Ключевые моменты:
Разделение тестовых данных и логики выполнения теста;
Использование того же клиента к API, что и в коде приложения. Клиент покрывается тестами отдельно, и в его работоспособности мы уверены, плюс при разработке мы не тратим лишнее время на поддержку тестов;
Скоуп тест-кейса жёстко ограничен. Гранулярность скоупа позволяет тратить меньше времени на идентификацию части приложения, в которой произошла ошибка, а так же степени важности и приоритета самой ошибки.
После реализации клиента и API останется запустить тесты ещё раз, чтобы убедиться, что они стали зелёными; отрефакторить код и запустить тесты снова.
HttpMock очень полезен, когда нужно протестировать клиент к REST сервису.