[rspec-users] HTML Story Formatter

Joseph Wilk lists at ruby-forum.com
Mon Jul 28 05:54:05 EDT 2008


> 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.

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.

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?

--
Joseph Wilk
http://www.joesniff.co.uk

Ben Mabey wrote:
> David Chelimsky wrote:
>> On Fri, Jul 25, 2008 at 8:08 AM, Joseph Wilk <lists at ruby-forum.com>
> wrote:
>>
>>> To handle this I wrote a patch which delivered the styles in the html
> formatters output. In much the same way as the html spec formatter
> does.
>>> I know Aslak Helles�y has been looking at the editable html stories. Is
> it acceptable to have stories have styles embedded in the html
> formatter until Aslak's editable stories project evolves?
>>> I could imagine there are some arguments that the HTML output of
> stories
>>> is something people might want to control the look and feel of, more so
> than specs as they are seen more frequently by customers.
>>> Perhapes by default the styles are embedded in the html formatter but
> if
>>> a CSS stylesheet is passed to the formatter than it will suppress this
> output and use your custom css.
>>> something like:
>>> ruby stories/all.rb --format html --css my_own.css
>>>
>> That all sounds reasonable to me. Sensible defaults, yet configurable.
> Other opinions?
>>
> 
> I like that idea.  I haven't wanted to push back any of my changes to 
> the
> HTML formatter because I knew that Aslak's goal was to create a 
> customer
> facing editable HTML page.
> 
> However, for CI builds it is more useful as a programmer to not have 
> that
> functionality and inline the backtrace as well (which is something  most
> customer's wouldn't want to see.)  I vote for inlining the basic  styles
> and providing the way to configure it as suggested above.  I  think the
> HTML formatter should include the backtrace and then JS can be  used to
> hide it for a customer-facing version.
> 
> 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:
> http://github.com/bmabey/rspec-story-tmbundle/tree/master/Support/resource/rspec.js
> (The JS commented out in the file was the original JS that Aslak did for
> the editable version.)
> My JS is untested though (and only works for rspec 1.1.4), so I don't
> know if you want to incorporate it into rspec, plus it would require the
> additional lowpro.js lib.
> 
> The bigger question, I think, is how to handle the required JS files.  I
> don't think inlining the whole prototype lib is a good solution.  So,
> maybe we could default to generating full paths to the JS files which
> reside in the rspec lib folder?  Then we could allow options to be 
> passed
> in to modify the JS path, just like the CSS option above?
> 
> Any other suggestions/ideas of how to handle the external JS files?
> 
> -Ben

-- 
Posted via http://www.ruby-forum.com/.


More information about the rspec-users mailing list