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