RamDisk – делаем всё быстрее!

Наверное, самый лучший практический совет, который я вынес из конференции XP Days – это совет по работе с Ram Disk'ами из доклада Crazy Talk: When 10 second builds start to make you nervous

Ram Disk – это технология не новая. Помню, как еще грузился с загрузочной дискеты Windows 95, где создавался такой диск с голым ДОСом. И в то время, при жестком дефиците оперативной памяти, навряд ли можно было использовать эту технологию каким либо другим способом.

Но, сейчас, когда 8 Гб – это уже так, средненько, а стоимость SSD как-то все еще неоправданно высока – для оптимизации процесса сборки большого проекта, особенно если он написан на С++ или Java – отлично подходят RAM-диски.

Простые тесты ввода-вывода показывают прирост производительности дисковых операций в 150 – 200 раз. Ну, а сам билд, со слов докладчика,  может собираться в 2 – 3 раза быстрее. Т.е. за 20 минут вместо 60-ти.

Для создания RAM-дисков существует множество как недорогих платных, так и бесплатных решений.

Я пока остановился на бесплатном ImDisk Virtual Disk Driver. Попробую, возможно получится оптимизировать некоторые операции backup/restore. 

Devnology Podcast 034 - Gojko Adzic

Я давно не пополнял запасы Спецификации через пример. В последнее время, по этой теме какое-то затишье, в смысле хорошых материалов и презентаций. Но, это подкаст действительно очень стоящий.

Гойко рассказывает о том, как он придумал "Спецификацию через пример", и где он подчерпнул нужные знания. Об успешном применении и причинах неудач в применении методологии. И о том, что создание рабочего софта – это главное, и намного важнее создания "запускаемой спецификации"

Ссылка на оригинальную страницу

MP3: Ссылкана аудиофайл 

О чем я расскажу на Test Automation Days

Так сложилось, что мы, тестировщики-автоматизаторы, зачастую идем позади программистов. Когда они говорят, что DRY (Не повторяйся ), и стараются умело жонглировать классами и абстракциями – то, нередко, мы копи-пастим целые куски кода.

Только сейчас, многие из нас, автоматизаторов, пытаются как-то использовать паттерн PageObject для того, чтобы и сделать код тестов понятней, и держать "все локаторы в одном классе". Буквально только сейчас люди начинают использовать некоторые преимущества объектно-ориентированного программирования. То есть применять то, чем программисты активно пользуются уже более 20-ти лет. И если они используют эти техники такой продолжительный срок – значит в этом что-то есть!

Так почему бы на не взять все самое лучшее? Все то, что заставит нас писать меньше кода, но, при этом покрывать больше функционала приложения.

Например, есть ли чего общего между страницей регистрации нового пользователя и формой обратной связи? И там и там есть некоторые ожидаемые поля. И там и там некоторые поля обязательны. Можем ли мы спросить у каждой страницы "А дай-ка мне список своих текстовых полей" и, получив список, – проверить каждое.

И все это одним участком кода? И код проверки будет единым для всех страниц, а для каждой страницы будет генерироваться отдельный тест. Но, только не путем копи-паста, а путем наследования.

Я покажу, как для каждой существующей страницы приложения прогнать целый набор тестов, а выполнятся, будут только лишь те, которые поддерживаться самой страницей.

Хорошо. Предположим, на страницу была добавлена фича "Если форма не сохранена и пользователь закрывает страницу – приложение должно известить о несохраненных изменениях". Сколько кода нужно написать, чтобы проверить эту фичу для 50-ти страниц в приложении?

Я покажу, как добавить 50 таких тестов, произведя изменения всего лишь в одном в файле.
Если интересно – приходите на мой доклад "За пределами PageObject" на конференции Test Automation Days, которая состоится в Киеве 9-го февраля 2013-го года.