We should warn on empty files about busted HOT 10 CLOSED

Something isn't necessarily wrong - it's possible that someone made a placeholder file to fill out later.

from busted.

then still a warning is appropriate, becasue imho the placeholder should have had a 'pending' test. No warning might give the impression complete and done, which is not correct in that case.

from busted.

It is both complete and done, though; the only things that would be wrong would be you didn't write any tests (which shows 0 completions) or the test framework is bad (which we should have caught in busted core specs.)

We could update the terminal verbose output to show the files that have been loaded and run, and how many tests failed/succeeded/pended in each of them.

from busted.

I think showing files and the test from each would suffice

from busted.

I think we should show the number of pending tests, like we do now, if a test file is run that contains only pending tests. If no tests are found in a file, we should throw a warning.

We can optionally show extra information when verbose output is selected.

from busted.

We should not warn on empty describe blocks, however.

from busted.

@DorianGray +1

Using the verbose option sounds good, I ran into my issue when setting up a new project, and the output just didn't tell me everything I wanted to know to rest assured it simply worked.
So using verbose option should not only display detailed errors, but also version info, filenames and the options used for the test run (including the ones not provided and defaulted). Then once your new setup works, simply remove the verbose option.

from busted.

I had a thought this morning about using mediator_lua to do messages to output over a pub/sub pattern instead of function calls so that we have a ton of flexibility. We could fire events when we load a file, run a test, etc and let the output lib decide what it cares about and how to format it.

from busted.

Further, it would be nice if the stdout of the code under test could be separate from how the output formatters work. Both json and my own junit xml formatters will break badly if any code that is being tested includes a print() anywhere at all.

from busted.

closed, #144

from busted.