Right, specially when rapidly driving your development by testing on
real browsers, prefer reloading instead of re-typing a command, and/or
when some browsers enforce blind sandboxes between frames in file:///
schemes and you need that.
It's sanely useful when your QA dept. has their own approval process,
split apart from the development process.
Personally I find jspec attractive vs. the rspec-cucumber-harmony-
culerity-celerity salad just because it runs in plain javascript (and
thus is extremely portable), and because it allows a quite smooth
integration with jscoverage to provide acceptable code coverage
statistics -- which is something the ruby salad mix can't provide,
although give a way easier marketing-proof DSL (gherkin).
This jscoverage integration is made through a custom command & module
and some templates. It describes its own suite with a "should cover
all of the available code" requirement expecting jscoverage's result
to be 100 at runtime in the 'running' hook, and then beforeSuite waits
until this exact suite is executed to calculate jscoverage's results.
Soon I'll push it to my github repo as well.
Kudos to your also handy commander and bind :)
A.
On May 10, 3:45 am, "vision media [ Tj Holowaychuk ]" <t...@vision-
media.ca> wrote:
> I still think its probably best to get rid of this. You really SHOULD
> be handling cross browser stuff with a CI server IMO, but I guess sometimes
> its
> nice to have a quick sanity check
>
>
>
>
>
> On Sun, May 9, 2010 at 8:47 AM, acorretti <
acorre...@gmail.com> wrote:
> > Hi,
>
> > I've solved this issue by making JSpec::Server a subclass of
> > Sinatra::Application, while detecting the first rack handler available
> > from %w[thin mongrel webrick].
>
> > You can check my commit here:
>
> >
http://github.com/acorretti/jspec/commit/0c14f30ab157018a7de30979c773...
> > > unsubscribe:
jspec+un...@googlegroups.com<
jspec%2Bunsu...@googlegroups.com>
> > unsubscribe:
jspec+un...@googlegroups.com<
jspec%2Bunsu...@googlegroups.com>