2016-02-18 18 views
13

Come si può rilevare l'utilizzo di funzioni indesiderate nella base di codice nel nodo, in particolare Gulp?Rileva le funzioni indesiderate (fdescribe, describe.only) come Gulp task

Sono dopo aver controllato per le specifiche involontariamente viziati, cioè ddescribe/fdescribe e iit/fit per Jasmine o .only e .skip per Mocha:

// should be reported 
fdescribe(function() { 
    // should not be reported 
    it(function() { 
    var fit = ...; 
    this.fit = ...; 
    }); 

    // should not be reported 
    // fit(function() { ... }); 

    // should be reported 
    xit(function() { ... }); 

    // should be reported 
    fit(function() { ... }); 
}); 

// should be reported 
describe.only(function() { 
    // should not be reported 
    it(function() { ... }); 

    // should not be reported 
    // it.only(function() { ... }); 

    // should be reported 
    it.skip(function() { ... }); 

    // should be reported 
    it.only(function() { ... }); 
}); 

Il compito dovrebbe uscire con errore e produrre nomi di file e numeri di riga in cui vengono utilizzate le funzioni elencate.

I commenti non devono necessariamente essere rilevati, così come le funzioni/proprietà con lo stesso nome (molto probabilmente fit), in questo caso una semplice corrispondenza delle espressioni regolari non è un'opzione qui (come sarebbe per console.*). Una soluzione basata su AST che accetta nomi di funzioni definiti dall'utente sarebbe apprezzata.

risposta

7

Lo risolverei in una fase di analisi statica tramite ESLint utilità di linting javascript. Per catturare le esclusive specifiche moca/focalizzate accidentalmente lasciato nella base di codice, c'è un no-exclusive-tests rule implementato nel eslint-plugin-mocha plugin:

Mocha ha una funzione che consente di eseguire i test in esclusiva da aggiungendo .only ad un test-suite o un caso di prova. Questa funzione è in realtà utile per eseguire il debug di un test non funzionante, quindi non è necessario eseguire tutti i test . Dopo aver corretto il test e prima di commettere le modifiche , è necessario rimuovere .only per garantire che tutti i test vengano eseguiti su del sistema di generazione.

Questa regola ricorda di rimuovere .only dai test sollevando un avviso ogni volta che si utilizza la funzione di esclusività.

Se si vuole legare la corsa eslint a gulp - usare il plugin gulp-eslint.


Si potrebbe anche essere una buona idea per eseguire l'attività gulpeslint prima impegnarsi in un gancio git. Abbiamo usato il pacchetto pre-git per installare e tenere traccia dei git git.

In questo modo, i test mirati o esclusivi non entrano nella base di codici in primo luogo.

+0

Non ho pensato a linters per quello scopo. Mi piacerebbe avere a portata di mano la soluzione basata su AST per i nomi delle funzioni definite dall'utente, ma solo per i globulari del framework di test eslint-plugin-mocha potrebbe essere ciò di cui ho bisogno. Purtroppo, sembra che non supporti '.skip'. – estus

+0

@estus bene, abbiamo avuto lo stesso problema esatto ma con il gelsomino. Lo abbiamo risolto con 'eslint' e' eslint-plugin-jasmine', eseguendo il task 'grunt eslint' come un hook di pre-commit git - ora, dopo diversi mesi usando questa configurazione, posso dire che aiuta davvero a mantenere il codebase pulito di avanzi accidentali come specifiche mirate. Felice di aiutare. – alecxe

+0

@estus Penso che questa regola 'eslint-plugin-mocha' avvisi su skip: https: // github.com/lo1tuma/eslint-plugin-moka/BLOB/master/docs/norme/no-global-tests.md. – alecxe