Joseph Wilk wrote:
Which brings up the other question.. how do we want to handle the JS?
Due to how the HTML is written out JS is required to change the Story's
and Scenario's styles when a step fails or is pending. I did this with
lowpro for the rspec-story-tmbundle:
The current html formatter in trunk no longer requires js to apply
styles for failure or pending.
Ahh, good to know. Does that mean that the HTML isn't outputted until
all of the scenario's are ran for a particular story?
So that moves us along to looking at js to hide/show the backtrace.
The idea of showing the backtrace in the html has been something I've
been debating for a while. I did come to conclusion that as a developer
I have the build log (or terminal stories are run from) as a source for
story errors. Hence I felt I was best left leaving my stories clean for
the non-developer users of the stories.
This is true for regular development, although having the backtrace can
also be helpful in the HTML version if you use that as your main
formatter (i.e. in textmate.)
The real use for the backtrace, IMO, is for providing a decent build
artifact for CI. Otherwise you could have to look through your test.log
file and try to match it up.. which would be no fun.
I can see from your post that there is a usecase for a more developer
centric output.
My goal with the default story output was to get a standalone .html file
which can then be moved around and played with without having to worry
about managing css & js files. Pretty much just as the spec reporter
does.
Thinking about a developer centric report and maintaining a standalone
html report starts to make me think about different formatters/reports.
* Default standalone
* Custom css
--
* Developer centric story report - js & customizable css
So this move us to something like:
*ruby stories/all.rb --format html
*ruby stories/all.rb --format html --css my_own.css
AND
*ruby stories/all.rb --format developer-html
I think the first two are important and represent the majority of use
cases.
If we can separate the idea of js and backtrace output to a separate
formatter then we can start work on the first two outputs now (and make
story reports usable out of the box).
Then we can use a developer formatter as a sounding board for
advanced/verbose output (profiling each story aswell perhaps?).
Potentially Aslak's new interface could move to this dev-formatter(or
some other formatter) so that we continue development without disturbing
those using the simple default output.
What do people think?
I really like that idea, and I agree with you that these two would cover
most use cases.
-Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
