четверг, 5 марта 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 2

Scott Meyers - Keynote @ Meeting C++ 2014

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

Первая часть - это история про главу из книги, посвященную разнице между insert & emplace в STL-контейнерах. На этом примере Скотт показывает важность пунктов из своего списка:

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

Вторая часть (ссылка со сдвигом по времени) больше познавательная и тренирующая английский. Разговор идет о том, как доносить информацию правильно. Часть скорее для тех, кто выступает, или хочет выступать. Есть немного и про то, как важно использовать современные технологии при печати книг (например использовать многоцветную печать). Резюме: готовьте доклады и выступления так, чтобы их было удобно смотреть в записи на видео. Пишите так, чтобы было удобно использовать современные гаджеты.


Добавляем докладик про автоматическое тестирование, для остроты вкуса солянки.
Никита в свое время проехался по нему танком легким броневиком. Собственно с тех времен доклад видимо у меня в запасниках и пылился. Пришло и его время.
Помнится был у меня опыт построения тестов, подобных тем, что описывает докладчик. Вспоминаю с ужасом. Мокировали все, что "движется"... Но, возможно тогда мозг еще не был готов и опыта не хватало.
Доклад в первую очередь для разработчиков, потому что у тестировщиков возникают резонные вопросы про проблемы, возникающие в реальном окружении (см. комментарии Никиты). Но разработчикам действительно важнее проверить максимально возможное количество сценариев (пресловутое покрытие) за минимальное время. А это можно сделать только через unit-тесты. Это действительно можно завести, но будет ли это эффективно?
Есть сомнения. Особенно если ваши тестировщики придерживаются legacy-взглядов на тестирование и никакой автоматики у них нет.
Использование юнит-тестов для проверки как раз исключительных ситуаций (обработка ошибок, граничных условий и тп) действительно оправдано. Часто воспроизвести такое в реальном стенде сложно (или приближается к невозможному). Но жизненные и простые ситуации (success path) проще и правильнее проверять на пользовательских сценариях с использованием всего продукта.
Итоговое резюме: классический пример случая "гладко было на бумаге, позабыли про овраги".


Наличие следующего доклада в этой подборке может показаться странным. Но нужно добавить аромата к солянке. Я настойчиво рекомендую его посмотреть всем. Даже тем, кому еще только за 20.
Меня торкнуло.

Комментариев нет:

Отправить комментарий