Chai assertion failures don't show any line numbers.

[btbinhtran]

Currently tests are harder to debug because it doesn't show a line number of an assertion failure.

I'm setting

chai.Assertion.includeStack = true

to deal with this. It doesn't give the exact line number, but at least it shows an approximate line number.

What are your thoughts?

[thehydroimpulse]

@btbinhtran @viatropos I'm currently working on a better testing environment for 0.5.0. You'll be able to run the following: tower test which will run all the tests. Because everything will become a package (even your application), the tests will reside inside their respective package. This makes the whole testing structure extremely modular. Your package file could look like this:

Tower.Packager.create('example-package')
  .server()
    .add('server.js', true) // True marks this file for initialization search.
    .tests('tests/server/**/*')
.client()
    .add('client.js', true)
    .tests('tests/client/**/*')

Still in the prototype stage and the API can change but that's basically the gist of it.

You'll also be able to do the following (still thinking of the syntax)

tower test include,filename,pattern=/[A-Za-z0-9](hello\_world)/

You could do the same with exclude searching, and you could search for something other than the filename, maybe a pattern for test names it('should ...') or group names describe('hello world'). Still thinking of other possibilities, but this could dramatically increase the testing environment.

Maybe, if you're inside a Tower app, running tower test would only run the app's tests and not the frameworks. Maybe having a flag like tower test include,tower then you can specify which tests you want to run like:

tower test include,packages=['tower-cli', 'tower', 'tower-generator']

Searching types could be:

• include
• exclude

Haven't thought of anything else.

And, you could have the following criterias:

• packages
• package
• filename
• group
• test

Thoughts?

[btbinhtran]

Your syntax idea seems like a good start.

Possible syntax assuming the singular search criteria can be a string or regex:

• For multiple files, packages, ... the user can have an array of filename search strings and regex: *tower test include,filenames=['filename1', /A-Za-z0-9/, 'filename2'],packages=['pack1', /tower/] exclude,filenames=['filename3', /.txt/]**
• For 1 file, package, ... the search criteria can be a search string or regex: tower test include,filename='filename1' package='pack1' exclude,filename='filename2'

[thehydroimpulse]

Yeah, so right now, I'm basically writing an extremely light lexer and parser for the test syntax. It's currently super fast, and works with strings, regex, numbers, etc...

Once Tower 0.5.0's repository is up, then we'll be able to test it out to see how we can improve it.