Better config file init/docs

[jasonkuhrt]

I wish this could be a PR but for now its just the idea.

There is incomplete documentation for the all-important testem.yml file. It is also too hard to get going with.

I suggest two things:

First

testem init command that will ask a series of questions on the command line to answer (think npm init etc). It should also enumerate the options when asking so instead of:

framework (mocha): |

It should be:

           (0 no / 1 jasmine / 2 mocha / 3 object)
framework: |

wherein the user may enter e.g. jasmine or simply 1.

Second

There should be a command to display the complete docs for config.yml:

testem docs --config

# or

man testem

Which would display https://raw.githubusercontent.com/airportyh/testem/master/docs/config_file.md and more (e.g. explain config.launchers object {command protocol}).

[airportyh]

I am still contemplating making testem completely modular and pluggable. So it the future it might look like (warning: vaporware).

npm install testem -g
npm install testem-mocha
npm install testem-sinon
npm install testem-chai

That is not to say semi-automation would not still be useful. But I'd wait for things to solidify first. Closing this for now.

[jasonkuhrt]

Sure, but the above doesn't preclude my comments regarding the config. Maybe you have even more in mind that would?

The point is that its currently a PITA to write config.yml and remember all its fields, especially when you're working on many different modules per day. The brain matter required to get testem going should approach nil.

Of course this can be achieved in another module rather than adding it to core.

[airportyh]

Oh yeah better/easier docs for the config would be awesome. Kinda like npm help json - sorry I kinda skimmed over. Currently if you do testem --help you get

testem --help

  Usage: testem [options]

  Commands:

    launchers              Print the list of available launchers (browsers & process launchers)
    ci [options]           Continuous integration mode
    server                 Run just the server

  Options:

    -h, --help              output usage information
    -V, --version           output the version number
    -f, --file [file]       config file - defaults to testem.json or testem.yml
    -p, --port [num]        server port - defaults to 7357
    --host [hostname]       host name - defaults to localhost
    -l, --launch [list]     list of launchers to launch(comma separated)
    -s, --skip [list]       list of launchers to skip(comma separated)
    -d, --debug             output debug to debug log - testem.log
    -t, --test_page [page]  the html page to drive the tests
    -g, --growl             turn on growl notifications

  Keyboard Controls (in dev mode):

    ENTER                  run the tests
    q                      quit
    LEFT ARROW             move to the next browser tab on the left
    RIGHT ARROW            move to the next browser tab on the right
    TAB                    switch between top and bottom panel (split mode only)
    UP ARROW               scroll up in the target text panel
    DOWN ARROW             scroll down in the target text panel
    SPACE                  page down in the target text panel
    b                      page up in the target text panel
    d                      half a page down in the target text panel
    u                      half a page up in the target text panel

Having a extra config --help command would be nice. As long as we are refactoring help, might as well split out the "keyboard controls" help as well. So probably something like:

• testem --help for top level help, showing options used with dev mode
• testem ci --help for options used with cd mode
• testem keyboard --help for the list of keyboard controls (maybe synonymous with testem keyboard)
• testem config or testem config --help for help with the config format.

[jasonkuhrt]

Keyboard help should go under:

testem dev --help

Then testem becomes/is just an alias for testem dev. This gives you a logical place to put keyboard help and the cli api is of uniform depth for behaviour: testem ci, testem dev, etc..

I don't think testem keyboard --help makes any sense. keyboard is not a command.

[airportyh]

Okay that makes sense.