Всем привет!
Что происходит после того, как падает тест? Его отладка, не так ли? Хорошо, если причина ясна из тест-репорта, но часто это не так. Отладка заключается в вызове дебаггера (н-р: ipdb) в месте падения, и в интерактивном режиме исследуется проблемное место. Т.е. требуется добавить команду отладчика и запустить заново тест. Но:
- во-первых это требует лишних телодвижений;
- во-вторых мигающий тест может и не упасть с первого раза;
Подумав над этим, я добавил в свой фреймворк glacejs опцию --debug-on-fail
, при котором в случае падения теста (исключение в стэпе) автоматически включается режим отладки с интерактивной консолью.
###Техническая реализация (JavaScript)
Для тех, кто любит больше читать код, чем статьи - сюда.
Поскольку основная идея фреймворка в том, чтобы в тесте не писать низкоуровневый код, а использовать дополнительный слой абстракции - стэпы, то решение свелось к перехвату исключения от стэпа и вызове интерактивного отладчика, который был реализован ранее.
В JavaScript
для перехвата методов и свойств объекта стоит использовать объект Proxy.
Steps.getInstance = function (cls) {
return new Proxy(
new (cls || Steps),
{
get: (target, property) => {
var func = target[property];
if (!util.isFunction(func)) return func;
if (!CONF.debugOnFail) return func.bind(target);
return async function () {
try {
var result = await func.apply(target, arguments);
} catch (e) {
console.log(e.toString().red);
CONF.debugOnFail = false;
await target.debug();
CONF.debugOnFail = true;
throw e;
};
return result;
};
},
});
};
Т.о. в случае использовании дебаг-флага, возвращается асинхронная функция - враппер над оригинальной функцией и дебаг-стэпом.
При этом до активации дебаг-режима флаг отключается, чтобы избежать повторной активации, если какой-либо стэп выбросит исключение в самого дебаг-режиме.