Re: Testing respec3

Thanks for this!

The problem I am seeing right now is that the core util tests are all 
failing. And they are failing because the 'require' statement is 
failing.  Basically it does not think the util.js is getting loaded.  I 
don't know why it doesn't think this because it clearly gets loaded 
once.  But then there is a second attempt to load it (according my local 
apache log) and that attempt uses an incorrect URI (/js/core/utils.js) 
for some reason.

Anyway, I continue to poke at it.

While I have your attention, is there a way to tell what version of 
respec actually gets served up by the W3C Tools/respec/respec-w3c-common 
?  It doesn't seem as if the diffmark stuff is being included when 
respec loads from there.  At least I can't make it appear from there, 
but when I work locally it appears (when I press ctrl-alt-shift-S).

On 10/11/2012 4:28 AM, Robin Berjon wrote:
> On 11/10/2012 10:49 , Shane McCarron wrote:
>> I see that respec3 has a test suite of sorts, and when I make changes I
>> would like to test them, but it is not clear to me how to *run* the
>> tests.  Mostly because I am obtuse I expect.  Is there documentation on
>> how to set up a local git repository so I can test before I commit my
>> changes?
>
> You're not obtuse — none of this is documented (which I intend to fix, 
> but not this very second).
>
> One of the design decisions in RSv3 was to ensure that editors could 
> use it locally, without setting up a local web server, while at the 
> same time making use of templates and a host of resources that would 
> be impossible to load from a file: origin. So there's a build step 
> that packages everything up into one nice script file.
>
> But if you're hacking on the actual code and want to test it, the 
> build step's a PITA. So the solution is to point a local web server to 
> the root of the repo, and open SpecRunner.html from there. It'll run 
> everything, which in some cases can take a while. You're usually 
> better off just running the parts that you're working on.
>
> I think that test-writing should be relatively self-documented. It's 
> using Jasmine (http://pivotal.github.com/jasmine/) which isn't 
> wonderful but gets the job done.
>
> One very useful trick for testing: when you load a ReSpec document, 
> you can append configuration information to its URL as part of the 
> query string, e.g. 
> foo.html?specStatus=FPWD;publishDate=1977-03-15;maxToc=5 and it will 
> override the doc's configuration. So if you want to test a bunch of 
> variations for a feature, you only need to have one document (that may 
> already exist, e.g. simple.html) and you can set the config in that way.
>

-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
+1 763 786 8160 x120

Received on Thursday, 11 October 2012 09:37:28 UTC