[Enhancement] Allow to use decorators and to filter what to run based on them

[thiagodp]

ES6 (a.k.a. ES2015) supports decorators. It would be very nice if CodeceptJS had its own decorators and we could use them for filtering the test cases to run.

This is specially needed for small applications with slow tests and, of course, medium-big applications - that have hundreds of tests.

Let's suppose that we have this:

// feature1.js ---

@importance( 9 )
Feature( 'Feature 1' );

@slow @importance( 6 )
Scenario( 'Scenario 1', ( I ) => { ... } );

// defaults to @importance( 5 )
Scenario( 'Scenario 2', ( I ) => { ... } );

@fast @importance( 4 )
Scenario( 'Scenario 3', ( I ) => { ... } );

@importance( 9 )
Scenario( 'Scenario 5', ( I ) => { ... } );

// feature2.js ---

@importance( 4 )
Feature( 'Feature 2' );

@fast
Scenario( 'Scenario 1', ( I ) => { ... } );

@importance( 3 )
Scenario( 'Scenario 2', ( I ) => { ... } );

We would have these decorators:

• @slow: indicates a slow test.
• @fast: indicates a fast test.
• @importance( <number> ): indicates the importance of a feature or a scenario, with a number varying from 1-10. The default importance of a feature or a scenario could be 5.

...and we also could do this:

1. Run slow/fast scenarios only:

codecept run --slow
codecept run --fast

2. Avoid to run slow/fast scenarios (or both):

codecept run --no-slow
codecept run --no-fast
codecept run --no-slow --no-fast

3. Run scenarios with a minimal/maximal feature importance (or both):

codecept run --min-feature-importance=7
codecept run --max-feature-importance=5
codecept run --min-feature-importance=1 --max-feature-importance=4

4. Run scenarios with a minimal/maximal scenario importance (or both):

codecept run --min-scenario-importance=6
codecept run --max-scenario-importance=8
codecept run --min-scenario-importance=1 --max-scenario-importance=4

5. All together:

codecept run --no-slow --min-feature-importance=7 --min-scenario-importance=6

I think it would benefit a lot of projects.

[thiagodp]

BTW, an alternative to use decorators would be passing an "option" object as argument to features or scenarios. Example:

Feature( 'Feature 1', { importance: 9 } );

Scenario( 'Scenario 1', ( I ) => {
    // body here
}, { importance: 6, slow: true }  );

[vitalics]

Hi @thiagodp, unfortunately, it impossible to use decorators on function, it works only on the class, method, property and parameter.
It can be possible only something like this:

// feature-1.js 
@Feature('Feature 1', {importance: 9})
class MyCoolFeature{
  @Scenario('Scenario 1', { importance: 6, slow: true })
  someScenario(I) {
    // scenario here
  }
}

or

// feature-1.js 
@Feature('Feature 1')
@importance(9)
class MyCoolFeature{
  @Scenario('Scenario 1')
  @importance(6)
  @slow()
  someScenario(I) {
    // scenario here
  }
}

I support your suggestion for allowing decorators because more and more libraries supporting decorators(e.g. node-decorators, di-typescript, inversify-js)

Use full links for decorators:
https://github.com/tc39/proposal-decorators
https://medium.com/google-developers/exploring-es7-decorators-76ecb65fb841
https://www.typescriptlang.org/docs/handbook/decorators.html

[thiagodp]

Hi @vitalics,
yep, at that time I thought that JS could make it. Later I noticed that it couldn't, but I forgot to update this issue. :-P Anyway, these parameters could be implemented with the current code by passing options.
Thanks for supporting the idea of using decorators, although it would probably require changing the way on how CodeceptJS tests are written. The OO-ish way is also interesting...