visionmedia / jspec

>0 when failures are present

and have a wrapper checking if the binary exists..

to documentation and in templates?

Nothing works in IE... because IE sucks

IE.. I hate you, MS, I hate you. Your browser sucks, your dev tools suck, and your error messages make no sense. Is this your way of saying "no your not allowed to alter setTimeout() etc" ?

... anyways we need to fix this

Error cause when using --server ... reporting issue with puts()?

ProxyAssertion can then become subclass of Assertion.. etc

continues to use the jspec gem

People are getting confused.. thinking the grammar is manditory

and the methods which go along with it

For setting options / manifest

something like this http://gist.github.com/178041

make default for templates

mock_request('/path').and_return(...)

When non-verbose the whitespace is a bit messed up

$ jspec run --rhino --failures-only $ jspec run --server --verbose --failures-only

etc..

to test against with --bind and just to test faster without starting the server each time

$ jspec server start
$ jspec server stop 

etc

now that mock_it() is available, move throw_error and other specific failure message assertions to their appropriate locations

Documenting changes

CIJoe :)

for matchers etc... all core modules should supply several

Currently valid:

foo.should.be_a Function
foo.should_be_a Function

RSpec style

foo.should be_a(Function)

currently 'before_each' is required

Look into it. although more dependencies sucks

Add a contrib guide

do not return.. utilize return value for something else useful?..

iteration... profile again and optimize

segregate everything into their own files for readability, then build with rake task.

Annoying to maintain several places

Would be nice to have, alot of people want to just run all specs without maintaining a manifest

Just wrap with a conditional checking of jQuery is available..

When 3.x becomes the mainline

just for fun

that lovely green color does not show on my windows command box. Windows does not support ANSI encodings. We need to find another way :)

JSpec 2.x does not use this for historical reasons, (when jQuery did not check dimensions) however we should use this for the next version

this would allow for users to leave the server running or daemonized for quicker responses

everything :D

move all readme to the site. make the site more like io's
dont forget to change fixture stuff!

Or at least wrap in #macos? and issue warnings etc

For Safari just use open -a -g like the rest

currently you would need to:

jspec run --rhino path/to/your.js

with no --browsers specified all supported browsers will run, which may
duplicate a browser if Default runs as well

to fix FF's crabby pants

Whenever possible the origin of the specs should be listed.

Locating a failing spec in a dozen files can be tedious.

Tagged specs would allow for running logical groups of tests or, conversely, identifying groups of problems when they fail.

For example:
I'm routing out a bunch of failing JSpec specs which are failing in IE only. Now that I understand the source of the problem the longterm fix is to tag them as flaky in IE, citing something like, "These JSpec features do not function correctly in your browser."

One such IE failure goes something like this:
function Foobar () {}
alert(Foobar.name)
// IE: undefined / Everyone else: "Foobar"

People will have to mock and stub like mad since JSpec is not queued yet but I need it for express

Better cross-platform compat

They do not appear to be working correctly. Also we should have
a different construct for shared behaviors, they should not be run they
should only provide as a list collection of specs

Both providing as documentation for doing so, and ... well testing for node.js

Perhaps auto-detect and bake support in.

When showing the output in the browser, it would be great to show the line numbers of the failing specs when you hover over the spec.

When showing the output in the browser, it would be great to show the origin filename to see where the spec came from.

Not sure when or why this went wrong, but I liked the assertion graphs on
the far right

To large to flat-out display unconditionally ... option? DOM could display this in a nice way but Terminal cant

It would be nice to have a way of adding global hooks so all suites can share and execute them.
Something like JSpec.addHook(hook, body).