Константин Книжник: статический анализ, взгляд со стороныTatyanazaxarova
Статья представляет интервью, взятое у Константина Книжника, сотрудником компании "Системы программной верификации" Андреем Карповым. Затронуты вопросы статического анализа кода, актуальность решений в этой области, а также перспективы использования статического анализа при разработке параллельных приложений.
Behavior Driven Development - подход к разработке ПО, основывающийся на ориентации на business value и исполняемых спецификациях, написанных на человеческом языке
Андрей Зайцев - TDD в кровавом энтерпрайзеElias Fofanov
Поговорим о том, когда, как и для чего писать тесты, а так же научимся проходить интервью на позицию junior test automation engineer. Подумаем над тем, почему TDD не взлетает, и может ли что-то быть хуже. Рассмотрим на примере использование таких инструментов, как NUnit, FluentAssertions, Moq, HttpMock.
Константин Книжник: статический анализ, взгляд со стороныTatyanazaxarova
Статья представляет интервью, взятое у Константина Книжника, сотрудником компании "Системы программной верификации" Андреем Карповым. Затронуты вопросы статического анализа кода, актуальность решений в этой области, а также перспективы использования статического анализа при разработке параллельных приложений.
Behavior Driven Development - подход к разработке ПО, основывающийся на ориентации на business value и исполняемых спецификациях, написанных на человеческом языке
Андрей Зайцев - TDD в кровавом энтерпрайзеElias Fofanov
Поговорим о том, когда, как и для чего писать тесты, а так же научимся проходить интервью на позицию junior test automation engineer. Подумаем над тем, почему TDD не взлетает, и может ли что-то быть хуже. Рассмотрим на примере использование таких инструментов, как NUnit, FluentAssertions, Moq, HttpMock.
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Статический анализ исходного кода на примере WinMergeTatyanazaxarova
Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам - WinMerge.
Как создать качественный статический анализаторAndrey Karpov
В докладе я расскажу о методиках достижения высокого качества продукта, которые наша команда использует при разработке статического анализатора. Упор сделаю на особенности разработки, а также на повышение качества именно анализа, то есть поиска реальных ошибок и потенциальных уязвимостей в коде.
Я регулярно общаюсь с потенциальными пользователями, озабоченными ошибками в программах на языке Си++. Их озабоченность выражается в том, что они пробуют инструмент PVS-Studio и начинают писать о том, что при испытаниях что-то подозрительно мало ошибок было найдено. И хотя, вроде чувствуется, что инструмент им интересен, их реакция полна скептицизма.
Статический анализ кода: современный взглядAndrey Karpov
Статический анализ - это методология выявления ошибок в исходном тексте программы, основанная на просмотре кода программистом, помеченного статическим анализатором там, где потенциально может находиться ошибка. Многие относятся к статическому анализу как к устаревшему и не актуальному методу. Действительно, существует ряд моментов, из-за которых кажется, что статический анализ приносил пользу раньше, когда средства разработки были намного менее функциональны. Однако если отбросить устаревшее, то оказывается, что методология статического анализа по-прежнему позволят существенно сократить цену устранения многих дефектов, за счет их обнаружения еще на стадии конструирования (кодирования). Более того, развитие языков, появление таких технологий программирования как OpenMP, увеличение среднего размера проекта делают применение статических анализаторов все более привлекательным для контроля качества проекта.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Статический анализ исходного кода на примере WinMergeTatyanazaxarova
Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам - WinMerge.
Как создать качественный статический анализаторAndrey Karpov
В докладе я расскажу о методиках достижения высокого качества продукта, которые наша команда использует при разработке статического анализатора. Упор сделаю на особенности разработки, а также на повышение качества именно анализа, то есть поиска реальных ошибок и потенциальных уязвимостей в коде.
Я регулярно общаюсь с потенциальными пользователями, озабоченными ошибками в программах на языке Си++. Их озабоченность выражается в том, что они пробуют инструмент PVS-Studio и начинают писать о том, что при испытаниях что-то подозрительно мало ошибок было найдено. И хотя, вроде чувствуется, что инструмент им интересен, их реакция полна скептицизма.
Статический анализ кода: современный взглядAndrey Karpov
Статический анализ - это методология выявления ошибок в исходном тексте программы, основанная на просмотре кода программистом, помеченного статическим анализатором там, где потенциально может находиться ошибка. Многие относятся к статическому анализу как к устаревшему и не актуальному методу. Действительно, существует ряд моментов, из-за которых кажется, что статический анализ приносил пользу раньше, когда средства разработки были намного менее функциональны. Однако если отбросить устаревшее, то оказывается, что методология статического анализа по-прежнему позволят существенно сократить цену устранения многих дефектов, за счет их обнаружения еще на стадии конструирования (кодирования). Более того, развитие языков, появление таких технологий программирования как OpenMP, увеличение среднего размера проекта делают применение статических анализаторов все более привлекательным для контроля качества проекта.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Презентация делалась для JuJa конференции - Java конференции для (пре) Juniors: https://juja.com.ua/materials/jujacon-2017/
В ней
- описываются основные темы-вопросы, которые часто спрашивают на собеседовании на позицию Junior Java Developer;
- советы, что спросить собеседующего;
- как себя позиционировать, как относиться к собеседованию, как не бояться и как понять, что вам "туда".
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
Здесь вы найдёте 60 вредных советов для программистов и пояснение, почему они вредные. Всё будет одновременно в шутку и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
В докладе я постарался рассазать о том, как я вижу и применяю TDD, почему мне это нравится и почему я хочу, чтобы это нравилось другим. Все это на примере мини-приложения на базе Django.
Видео: http://www.youtube.com/watch?v=077DmBBTS3o
XP Days Ukraine 2014 - Refactoring legacy codeDmytro Mindra
Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail.
Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests. When code is refactored and unit tests are added, changes to functinality can be introduced.
We will take an open source C# project and will refactor it showing step-by-step examples of the techniques. This session is full of tips and tricks you can start applying immediately. Although the code is in C#, the same principles can be applied in any language.
В докладе я расскажу о том как я вижу и применяю TDD, почему мне это нравится и почему я хочу, чтобы это нравилось другим. Все это на примере какого-нибудь мини-приложения на базе Django.
QA Fest 2019. Андрей Солнцев. Десять причин моей ненавистиQAFest
Меня часто спрашивают, за что я не люблю в тестах Page Objects, TestNG, ReportPortal, try/catch, циклы и условия, неявные ожидания, явные ожидания, Dependency injection, Spring и т.д.
Расскажу коротко и быстро. На каждую тему 5 минут.
2. Немного о себе
Меня зовут Сергей
Я разрабатываю backend у Злых Марсиан
Я люблю писать тесты
3. Сегодня мы:
Поговорим о том, зачем мы пишем тесты;
Уменьшим объем тестов без потери качества;
Уменьшим время написания и цену тестов;
Упростим поддержку.
4. Disclaimer
Спорить о тестах можно много и долго. Все сказанное
здесь - мое мнение, основанное на личном опыте
7. Почему нужно писать тесты?
Чтобы беречь свое время при разработке;
Факт от Капитана: автоматические тесты выполняются на
порядок быстрее ручных.
8. Почему нужно писать тесты?
Чтобы беречь свое время при разработке;
Чтобы не бояться что-то сломать;
Факт от Капитана: Все делают ошибки. Кто не делает
ошибок, тот нагло врет.
9. Почему нужно писать тесты?
Чтобы беречь свое время при разработке;
Чтобы не бояться что-то сломать;
Чтобы держать архитектуру приложения в форме.
(касается в основном unit-тестов)
10. Почему нужно писать тесты?
Тесты - это взгляд на код со стороны.
Код сложно тестировать?
⬇
Код сложен, запутан
⬇
Код нуждается в рефакторинге
11. Почему иногда мы не пишем
тесты?
Потому что часто тесты выглядят вот так:
15. Test coverage
Не дает никакого представления о том, насколько
хорошо протестирован код;
Показывает, какие места точно не протестированы, но
не наоборот;
Не дает никакого представления о качестве кода;
Не та метрика, за которой стоит гнаться.
16. Test coverage
100% не стоит вашего времени;
90% — это очень хорошее покрытие;
70% вполне достаточно.
17. Test coverage
“Мне платят за код, который работает, а не за
тесты, поэтому моя философия заключается в
том, чтобы тестировать настолько мало,
насколько это возможно для достижения
нужного уровня уверенности„
(Кент Бек)
19. Выбрасываем лишнее
Тесты некритичного кода
Если ошибка в коде не повлечет за собой серьезных
последствий, то тестирование этого участка кода совсем
не обязательно.
20. Выбрасываем лишнее
Тесты поведения сторонних библиотек
Большинство библиотек уже протестированы
разработчиком;
Если вас не устраивает, как они протестированы, лучше
сделать контрибьют, чем держать тесты у себя.
21. Выбрасываем лишнее
Косвенно выполненные проверки
Проверка на наличие классов и методов;
Проверка количества аргументов функций;
Проверка на отсутствие исключений.
Иногда такие проверки необходимы, но такие случаи
редки.
25. Приводим оставшееся в порядок
“Пишите код так, как будто сопровождать
его будет склонный к насилию психопат,
который знает, где вы живёте„
(Мартин Голдинг)
Верно и для тестов.
28. Используйте говорящие имена
тестов
Если фреймворк не позволяет в полной мере описать тест
с помощью имени, напишите комментарий
# Sends email to the user
def test_send_message
# ...
end
29. Один тест - одна проверка
По выводу тестового фреймворка должно быть понятно,
какие конкретно действия выполняются не так, как
ожидалось.
30. Один тест - одна проверка
Bad:
it 'creates message and sends it to the user via email' do
# ...
end
Good:
it 'creates message' do
# ...
end
it 'sends message to the user via email' do
# ...
end
31. Один тест - одна проверка
Аналогично для фреймворков без возможности подробно
описать тест
# Creates message
def test_send_message__message_creation
# ...
end
# Sends message to user
def test_send_message__message_sending
# ...
end
32. Один тест - одна проверка
Некоторые фреймворки позволяют писать комментарии к
проверкам. В таком случае разделение не так важно.
Пример для testify (go):
// Creates message
func Test_sendMessage(t *testing.T) {
// ...
assert.Equal(t, expected, actual,
"Should create message")
// ...
assert.Equal(t, expected, actual,
"Should send message to user via email")
// ...
}
34. Используйте контексты
Bad:
it 'creates message when user is signed in' do
sign_in(user)
# ...
end
Good:
context 'when user is signed in' do
before { sign_in(user) }
it 'creates message' do
# ...
end
end
35. Используйте контексты
Если фреймворк не поддерживает контексты, можно опять
обратиться к комментариям
# = When user is signed in ==============================
# Creates message
def test_send_message__signed_in__message_creation
# ...
end
# = end When user is signed in
37. Правильные ожидания
Примеры хороших ожиданий:
Возвращаемое значение;
Изменения состояния класса, видимого извне;
Внешнее воздействие a.k.a. side effect;
Обращение к сторонним объектам.
38. Правильные ожидания
Примеры плохих ожиданий:
Изменения внутренних переменных класса;
Изменение состояния хранилища, используемого для
хранения состояния тестируемого объекта;
Вызовы приватных методов.
39. Правильные ожидания
Bad:
it "puts provided value to redis" do
subject.set("the value")
expect(REDIS.get("the key")).to eq("the value")
end
Good:
it "saves provided value" do
subject.set("the value")
expect(subject.get).to eq("the value")
end
41. Mocks & stubs
Палка о двух концах:
Помогают достичь нужного уровня изоляции;
При злоупотреблении могут сделать тест бесполезным.
42. Mocks & stubs
Хорошие кандидаты:
Передаваемые на вход объекты;
Сетевые службы;
Функции с трудно прогнозируемым или трудно
выводимым результатом, используемые в тестируемом
методе.
43. Mocks & stubs
Нужно очень осторожно подходить к стабу БД.
Если не уверены на 100%, не делайте этого
44. Работа с внешними связями
Ситуация №1:
Функция foo объекта A (A.foo) проводит вычисления со
сложной логикой, основываясь на результатах функции
bar объекта B (B.bar);
B.bar в свою очередь тоже проводит вычисления со
сложной логикой.
Необходимо протестировать метод A.foo
45. Работа с внешними связями
Вариант решения №1:
Написать тест, учитывающий логику функции B.bar.
Нарушение DRY, повторное тестирование B.bar,
тестирование логики, не относящейся к тестируемому
методу
46. Работа с внешними связями
Вариант решения №2:
Создать условия для получения заранее известного
результата B.bar, использовать этот результат для
тестирования A.foo.
Тест становится зависимым от логики B.bar.
Изменение логики стороннего метода сломает тест.
47. Работа с внешними связями
Вариант решения №3:
Сделать stub B.bar с известным результатом,
использовать этот результат для тестирования A.foo.
Тест не зависит от логики B.bar
48. Работа с внешними связями
Проблема варианта №3: Изменение интерфейса
функции B.bar сломает код, но оставит тест ложно
положительным.
Решение: Это тот самый случай, когда чистый прогон
функции с проверкой на отсутствие исключений имеет
место быть.
49. Работа с внешними связями
Ситуация №2:
Метод foo объекта A (A.foo) проводит вычисления со
сложной логикой и затем вызывает метод bar объекта B
(B.bar);
B.bar в свою очередь тоже реализует сложную логику.
Необходимо протестировать метод A.foo
50. Работа с внешними связями
Вариант решения №1:
Проверить side effect метода B.bar, учитывая его логику.
Нарушение DRY, повторное тестирование B.bar,
тестирование логики, не относящейся к тестируемому
методу
51. Работа с внешними связями
Вариант решения №2:
Проверить некоторую неизменную часть side effect'а
метода B.bar, не зависящую от его логики. Пример: mailer
отправляет письмо с неизменным заголовком.
Тест не зависит от логики B.bar. Изменение
интерфейса B.bar будет обнаружено сразу.
52. Работа с внешними связями
Вариант решения №3:
Сделать stub B.bar, проверить факт его вызова после
выполнения A.foo.
Тест не зависит от логики B.bar
Имеет ту же проблему и аналогичное решение, что и
вариант решения №3 предыдущей ситуации.
55. Составьте договоренности
Если работаете в команде, составьте styleguide для тестов,
хотя бы на словах. Это существенно снизит порог
вхождения в чужие тесты.
57. Почему test first?
Если строить код на основе тестов, то у вас практически
не возникнет проблем с тестируемостью;
Хорошо организованные тесты позволяют продумать и
описать структуру кода до реализации.
58. Почему test first?
Главный аргумент
Не зная точной реализации, вы будете вынуждены
тестировать только интерфейс, что и требуется
59. Test first
Перед написанием тестов, постройте дерево с помощью
контекстов. Постарайтесь отобразить все возможные
варианты развития событий.
60. Итоги
Не гонитесь за test coverage;
Не будьте параноиком, определите для себя, что нужно
тестировать;
Описывайте тесты так, чтобы другой человек мог понять
тестируемый функционал;
Тестируйте интерфейс, а не реализацию;
Делайте unit-тесты независимыми от функционала
других классов/методов;
Используйте тесты как спецификацию для вашего кода;