Re: Testing

[email protected] Thu, 17 May 2018 07:43:01 +0800
Newsgroups gmane.comp.audio.supercollider.devel
Message-ID <[email protected]>
On May 16, 2018 06:49:11 [email protected] wrote:

> On Sun, May 13, 2018 at 11:14 PM, <[email protected]> wrote:
>
>>   - I do agree specs are what we really need long-term, and Property Tests
>> (i.e. random fuzzing against a spec) to check reality against the spec!
>
> For the purpose of community discussion, can someone please define or give
> examples of "specs"? This is a nebulous term to me and since I'm not the
> one using/asking for it, I can't really talk about the suggestion until
> there's some clarification. My biggest question is - is it different than
> documentation? How/why? I can't really think of anything that is a
> specification that shouldn't also be documentation, unless you're also
> considering implementation details.

That could be a one-hour question, and I have about 20 minutes on a bus 
with a mobile keyboard that keeps autocorrecting eg "could" to "is" 🤔 and 
I literally have no more time today, so this answer will be unsatisfactory.

Documentation is descriptive. Specs are prescriptive. Documentation is what 
you write after everything is working and you want to explain how to use 
it. Specs are what you write before writing even one line of code.

A spec for a programming interface should detail not only expected inputs 
and outputs across ranges of scenarios, but also try to anticipate corner 
cases and define error handling. A spec for UGens might state that ar units 
should support ar inputs unless there is a very good reason for not doing 
so. UGen documentation is for users, not developers, so it doesn't 
necessarily have to detail that.

A spec for a user interface details what should happen for every user 
action, eg, clicking the server window's boot button when the server isn't 
running should start the boot process, and during boot, the button should 
read "booting" until it's up and running, at which point it should change 
to "running." It should also say what happens in the window if the server 
fails to start. You can read this spec and know what to test.

In the software company where I used to work, program managers had to write 
a spec for every new feature, no matter how small, to coordinate 
developers, testers, and manual writers. Not a huge software company. I 
believe it's standard practice in the industry.

The other points... unfortunately have to wait. My job is not good these days.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com