Чудес не бывает или я ошибаюсь?

Коллеги в настоящее время выбирают себе тестовый фреймворк, на базе которого хотят разрабатывать автоматические тесты. Кстати, сейчас Болтоном и Бахом  активно  продавливается тема, что это не автоматические тесты, а автоматические проверки ( testing vs checking ). Но это тема отдельного поста , холиварить будем там. Я задумался над критериями, которыми, по моему мнению, должен обладать инструмент для написания приемочных тестов, конечно с учетом специфики нашего продукта (Windows (не-веб), продукт распределен по нескольким хостам, виртуализация). Тут же вопросы, на которые полезно знать ответы, когда тебя спросят почему именно этот инструмент, а не другой. 1. Я хочу посмотреть список тестов, какие проверки ими делаются и какая функциональность продукта проверяется. Можно ли это сделать с рабочего места, например Product Manager-а или меня как руководителя разработки, без установки дополнительного ПО? 2. Возможно ли написание одного теста в виде пользовательской исто

В этот раз не совсем солянка, скорее сборник :) В своем отчете о PiterPy#2  я упоминал, что познакомился там с Григорием Петровым. Порыв интернеты, нашел несколько интересных видео его докладов. Простые темы докладов не должны вас смущать, просто посмотрите. Как называть переменные Комментарии писались по другому видео с аналогичным докладом. Оно потерялось, но Гриша часто выступает, вот новый вариант. Возможно есть отличия - я не пересматривал. Тема неожиданная, но содержимое очень порадовало. Для начинающих - смотреть обязательно, остальным рекомендуется. Вот это очень понравилось: не нужно приводить существующий код в соответствие новым стандартам исходников. Зачем выступать на конференциях Кроме вопроса "зачем выступать", Гриша отвечает на вопросы как готовится, на что обратить внимание в презентации, а также зачем ходить на доклады :) Есть еще доклады  (в т.ч. про комментирование исходников и то, как их хранить) Интервью Гриши на конференции PiterPy &q

Наткнулся недавно на подборку интересных исследований проведенных Empirical Software Engineering and Measurement Research Group. Товарищи на примере деятельности команд разработки Microsoft попытались получить хоть какие-то цифры отражающие влияние различных инженерных практик и процессов, например TDD, на качество получаемых продуктов. Сюда вынес наиболее интересные результаты исследований. Ниже, в качестве критерия качества рассматривается количество ошибок обнаруженных после релиза и требующих зачинок (как самых дорогих для исправления). Влияние покрытия кода тестами на качество Покрытие кода рассчитывается, как процент (отношение) строчек кода, которые вызываются при запускаемых тестах к их общему количеству. Казалось бы логичным считать, что чем больше покрытие - тем лучше качество. Но результаты показали, что не все так просто ( кто бы мог подумать ). Одна метрика не может характеризовать качество для любых продуктов. Процент покрытия кода сам по себе ничего не говори

Часть 1.  Введение  Часть 2.  База  Часть 3. Advanced Часть 4.  Демо FitNesse + Jenkins Часть 5. Пример трансформации PowerShell скрипта в тест Плагин для sublime , который подсвечивает синтаксис теста на Fitnesse+PowerSlim В ходе недавнего начала обучения коллег выяснилось ряд моментов, которые нужно уточнить. Кто то доходит до них сам, а кому то, надеюсь поможет эта статья. Итак, "мы прочитали твои посты, позапускали примеры, дальше то что? С чего начать?" Давайте попробуем написать некое подобие теста для реальной (ну или почти реальной) ситуации. И, заодно, обратим внимание на один очень интересный момент, который облегчит написание тестов. В Hyper-V PowerShell API есть такие cmdlet'ы: New-VM, Get-VM, Remove-VM. Давайте попробуем проверить, что мы можем ими пользоваться. Ситуация выглядит немного синтетической, но представьте, что есть продукт, который стоит внутри Hyper-V и расширяет модель авторизации этой платформы виртуализации. Такой продукт даже в

taw's blog: The Rise and Fall of Unit Testing Ну вот, а я хотел это все написать. Но теперь не буду, потому что не люблю переписывать, то что уже написано кем то другим. Unit-тесты не спасают нас ни от "лапше-кода", ни от плохого дизайна, ни от нерабочего продукта. Но они помогают помогают этого избегать - это факт. Просто везде надо знать меру. А включение головы никто не отменял. И про mock-и я тоже писал

Сегодня обзор совсем небольшой (по количеству видео), но интересный. Видео всего два и начну с " Jira против PivotalTracker " (а то после анализа второго, до него не доберется никто). А оно интересное. Живо, динамично. Мне больше понравился Pivotal, наверно потому что я его использовал когда то. Защитник Pivotal'a креативен :) интересно, это Андрей? ( тут ) Дальше обнаружилось видео доклада Андрея Солнцева " Пацан накодил - пацан протестил ". Он выступал с ним у нас Питере, в соседнем здании бизнес-парка, но у меня не получилось туда сходить. Как оказалось - к сожалению. Краткое резюме: Java-стам, особенно начинающим надо посмотреть. Вот сначала посмотреть, а потом говорить "такие простые вещи тестировать понятно, что можно, а вот у нас все сложнее, умнее, жирнее, глупее, или просто 'не так' (нужное подчеркнуть)". Вещи, о которых говорит Андрей, базовые и если вы их не понимаете или не знаете, как писать тесты для простых приложений

( c ) Иногда коллеги спрашивают. Решил все свои рекомендации в одно место сложить. Ссылки для самообразования: Google's Python Class Microsfot Virtual Academy:  Introduction to Programming with Python " Learn Python the Hard Way " Книжка по которой я учился " Dive Into Python " (я учил еще 2й, но сейчас правильнее 3й) Эту не читал капитально, но выглядит интересно " Think Python " Свеженькое с примерами из реальной жизни " Python Projects " Анти-паттерны программирования на Python Сборник Invent with Python  (там даже про автоматизацию есть) 2019 Школа backend-разработки Яндекса статья  и плейлист записей  Неплохой список рекомендованных к прочтению книг Еще немного ссылок на Python для детей " Идеи проектов на Python , которые можно начать воплощать уже сегодня" PS буду признателен, если посоветуете еще интересных ресурсов.