Статьи

Автоопределение библиотеки JavaScript TDD / BDD

Июнь 26, 2018

Уникальная особенность Venus.js , JavaScript- бегуна из LinkedIn, заключается в том, что конфигурация теста может быть в форме исходной аннотации . Это полезно, например, для выбора библиотеки тестов ( Mocha , Jasmine , QUnit ), которая будет использоваться для выполнения тестов. Разве не было бы здорово, если бы тестируемый мог автоматически выводить указанную библиотеку?

Во время беседы за чашкой кофе я предложил такую ​​идею обнаружения наилучшего усилия моему коллеге-инженеру Shape Security Сету (который связан с Venus.js). Очевидно, что этот тип обнаружения может быть не на 100% точным. Однако я постулирую, что это должно быть достаточно хорошо в большинстве случаев, особенно в случае, когда аннотация отсутствует.

В качестве подтверждения концепции я реализовал detect-testlib.js(см. Репозиторий Git по адресу bitbucket.org/ariya/detect-testlib ). Он использует Esprima для анализа кода теста, сбора важных глаголов (подробнее об этом позже), а затем с помощью собранной информации решите, написан ли тест в Jasmine или qUnit, или он полностью неизвестен. Чтобы продолжить, клонируйте репо, запустите npm installсначала и попробуйте следующее:

node detect-testlib.js test/jquery-attributes.js

Это jquery-attributes.jsвзято из реальных модульных тестов jQuery. Как и ожидалось, обнаружение-testlib с уверенностью скажет, что эти тесты используют qUnit. Для другой попытки, проверьте test/yeoman-env.js(снова, взятый из основанных на жасмине Еоманских тестов).

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

describe("sqrt", function() {
    it('computes the square root of 9 as 3', function() {
        expect(My.sqrt(9)).toBeCloseTo(3, 10);
    });
}

затем он будет собираться describeв группе верхнего уровня и itв группе уровня тестирования. Через некоторое время мы заполним эти два массива (без дубликатов). Например, его запуск test/jquery-attributes.jsдаст массивы как:

{ topLevel:
   ['module', 'test' ],
  testLevel: 
   [ 'expect',
     'deepEqual',
     'equal',
     'ok',
     'strictEqual',
     'testVal',
     'testAddClass',
     'testRemoveClass',
     'testToggleClass' ] }

Как только массив получен, специальная decide()функция будет использовать простую эвристику для определения библиотеки, используемой в тестовом коде. В качестве иллюстрации для приведенного выше примера будет сделан вывод, что в тесте используется жасмин (в зависимости от наличия describeи it). Для другого тестового кода, подобного следующему:

test("sqrt", function() {
  equal(My.sqrt(4), "2", "Check for square root of 4" );
});

тогда decode()пойдет на QUnit в качестве решения.

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

Как насчет мокко? Поскольку Mocha может поддерживать стиль TDD и BDD, фактор принятия решений более сложный. Возможное решение состоит в том, чтобы обнаружить механизм утверждений и сопоставить его с типичным шаблоном утверждений (wait.js, Chai и т. Д.), Используемым с Mocha.

Удачи с автоопределением!

35
Share: