Automated Testing Service Group

Оператор typeof используется для определения типа переменной. Существует 6 возможных значений, которые возвращает typeof: "number," "string," "boolean," "object," "function," and "undefined".

В этом посте мы немного улучшим этот оператор, чтобы иметь возможность определять такие типы данных, как дата ("date") и массив ("array").
 

В любой программе есть недокументированные возможности. Некоторые из них явно добавлены в программу (как, например, пасхальные яйца), некоторые являются недоработкой программистов, а какие-то - просто нереализованными возможностями.
В этой статье речь пойдет о недокументированном параметре функции LogError.

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

Очень часто при автоматизации тестовых сценариев можно натолкнуться на шаги вида: "повторите шаги 1-12" или еще интересней, "повторите все шаги" + некоторые поправки. То есть в конечном итоге при реализации нам надо будет полностью продублировать код определенных шагов. А излишнее дублирование может вызвать ряд трудностей при модификациях тестов, при поддержке тестов. Любые изменения надо вносить во все вхождения повторяющегося кода. А это дополнительная потеря времени. Как этого избежать:

В очередной раз, наталкиваясь на различные публикации по автоматизированному тестированию, наталкиваюсь на мнение людей, что как только упоминается какое-нибудь heavy-weight big vendor средство автотестирования (кстати как правило стараются не называть конкретное средство ), то к нему сразу же привязывается "диагноз" что ли - unmaintainable scripts. Но если упоминается что-нибудь писанное на коленке или представляющее собой некоторую библиотеку, то такой проблемы изначально якобы нет. Я, конечно, склоняюсь к идее, что лучше взять что-то мелкое, но оно будет успешно выполнять поставленные задачи, чем взять что-то здоровое и громоздкое, а потом думать, куда бы его прикрутить.

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