2016-03-07 2 views
3

В настоящее время я использую Karma + Jasmine для запуска тестов в моем проекте на основе TypeScript, и я хочу «разорвать тесты», когда компиляция TypeScript завершится неудачно в режиме просмотра кармы.Ошибка компиляции скрипта и выполнение теста Karma?

Я использую стандартную конфигурацию Karma и компилирую TS с помощью препроцессора webpack (который компилирует TS-файлы). Все работает отлично, за исключением того, что , видя, что все тесты проходят, когда возникает ошибка компиляции, очень вводит в заблуждение (karma повторно запускает предыдущие тесты, даже если компиляция webpack не работает).

Это кажется довольно тривиальным, но через час или два, глядя на документацию и поиск в Google, я отчаянно ищу решение, которого я не нашел.

Есть ли решение, включающее карму, жасмин, webpack и TypeScript, которые могут нарушить тесты при возникновении ошибки компиляции без нарушения режима просмотра?

Редактировать: Точность в режиме часов добавлена.

+0

трудно сказать что-либо конкретное, не видя конфигурационных файлов, и лучше всего было бы увидеть какой-то очень простой изолированный проект. – ciekawy

+0

На самом деле вопрос не в том, «это моя конфигурация в порядке или нет», а скорее «Возможно ли это?» И если да , как вы это сделали в своем проекте с аналогичным стеком? ». –

ответ

2

лично я не использую карму вместе с веб-пакетом в одном рабочем процессе. Но не забудьте сделать некоторые исследования по их использованию вместе, включая машинопись, и есть проблемы https://github.com/webpack/karma-webpack/issues/49 и https://github.com/webpack/webpack/issues/708, с которыми вы могли столкнуться. Так как упомянутый параметр bail не работает должным образом, вы можете попробовать использовать упомянутый плагин, который будет терпеть неудачу при ошибке TS (предложение предложения от this comment to issue #708).

UPDATE: Что касается watch случае я хотел бы рассмотреть изменения, предотвращающие Webpack от поломки, но в то же время поднимая ошибку и предотвратить карму от выполнения тестов, а также (на основе этого suggestion).

module.exports = function (config) { 

    config.set({ 

    browsers: [ 'Chrome' ], 
    frameworks: [ 'mocha' ], 
    reporters: [ 'mocha' ], 

    files: [ 
     // ... 
    ], 

    // ... 
    webpack: { 
     plugins: [ 
      function() 
      { 
       this.plugin("done", function(stats) 
       { 
        // Log each of the errors 
        stats.compilation.errors.forEach(function (error) { 
         console.log(error.message || error); 
        }); 

        // Pretend no assets were generated. This prevents the tests 
        // from running making it clear that there were errors. 
        stats.stats = [{ 
         toJson: function() { 
          return this; 
         }, 
         assets: [] 
        }];      
       }); 
      } 
     ] 
    } 
    }) 

} 

Я только что проверил добавление выше плагин к довольно простой проект https://github.com/itajaja/tslib-webpack-starter и тесты терпят неудачу за ошибки компиляции TS.

+0

Сначала это выглядело неплохо, но потом я увидел, что режим часов не был «чисто» поддержан ... ошибка компиляции убила его при возникновении ошибки. –

+0

и какое поведение вы ожидаете в режиме просмотра? обычный способ, который я знаю, состоит в том, что весь рабочий процесс (т.е. компиляция и тесты) должен пройти, чтобы запустить режим просмотра. Затем в случае отказа он должен правильно перепроверять в случае каких-либо новых изменений. – ciekawy

+1

Вот и все! Превосходный ! Код, который вы только что опубликовали, отлично работает: тесты не выполняются при возникновении ошибки компиляции, и ошибка регистрируется в консоли. Мне просто пришлось обернуть «stats.stats = [{...}]» с помощью «if (stats.compilation.errors.length> 0) {« ... –

0

У меня была проблема с tslint предупреждениями. Все, что я получал, это Compilation failed due to tslint errors. Добавление этого параметра в webpack.config.js заботилась о нем:

bail: true, 

Это идет вместе со всеми регулярными webpack.config.js настройками. Например:

{ 
    context: __dirname + "/app", 
    entry: "./entry", 
    output: { 
     path: __dirname + "/dist", 
     filename: "bundle.js" 
    }, 
    bail: true 
} 

Теперь я, по крайней мере, вижу первую ошибку tslint перед ее сбоем.