Re: Starting a test suite for Web Audio

On 05/21/2013 02:46 PM, Chris Lowis wrote:
>
> James Graham writes:
>> To be clear about this, there is nothing that stops you/people in your
>> wg submitting PRs to web-platform-tests and having the policy that only
>> other WG members should review things in the webaudio folder for now.
>> That does have a number of advantages; e.g. your tests (including those
>> in unaccepted pull requests) will automatically be mirrored on
>> w3c-test.org so that people can run them without a local checkout. There
>> is also an instance of the critic code review tool set up for the main
>> web-platform-tests repository, and this would allow people in your wg to
>> get notified of changes/submissions for webaudio tests alone (using the
>> filter system). Using this location also makes it more likely that
>> people familiar with the infrastructure will comment on whether you are
>> following common idioms with testharness.js or idlharness.js.
>
> Ah! Thank you that makes a lot of sense now! I think that is what I'm
> primarily concerned about - that tests need to be written with the spec
> in mind, and as our spec is a moving target at the moment I'd hate for
> someone at a hackathon to spend a lot of time writing tests for an
> obsolete bit of the spec, for example.
>
> I think if we can have a policy/tools that help audio wg members review
> PRs to w3c/web-platform-tests that will be perfect!
>
> Where is the critic code review tool?

https://critic.hoppipolla.co.uk

You can set up filters on the homepage so, for example, you might set 
yourself as reviewer for all tests in web-platform-tests/webaudio by 
selecting "web-platform-tests" as the repository and "/webaudio" as the 
filter.

If you need help getting started with this, or any other aspect of 
testing, please track me down on irc; #whatwg on freenode is a good bet, 
or #testing on irc.w3.org.

>> On the other hand I don't really object if you iterate the testsuite in
>> another location at first and then make a submission later. But it does
>> mean that you will have worse tooling and could lead to unnecessary work
>> later on.
>
> I think we just need to nail down which of our alternatives to use to
> actually test audio generation, and then I'll send a pull request, close
> down our "fork" and let people know how to contribute moving forward.

Sounds good to me.

Received on Tuesday, 21 May 2013 13:13:27 UTC