Re: Testing

julian.rohrhuber-QYZGCWsIODmAF8UT6DzBU6xOck334EZe@public.gmane.org Thu, 17 May 2018 09:20:12 +0200

Newsgroups	gmane.comp.audio.supercollider.devel
Message-ID	<[email protected]>

thank you for bringing this up. Just a few thoughts:

- It can be hard to formulate a spec. It can even be impossible to do it adequately. This problem has a long history in logic: should understanding come before formalisation or should it come in retrospect? There are good examples for both.

- It can be worth *trying* to formulate a spec. In particular because code and natural language may address a problem together. When something doesn’t work properly, one can move in between the two. Also, it can help to avoid “false friends”, where code looks as if having a particular meaning, but is intended to be more general. But a spec doesn’t have to come before, and a spec can be changing just as code can. The code may justifiably contradict a spec, and vice versa.

So by consequence:

The process of specification is a slow and continuous one, which is a fore and back between actual use patterns, implementations, intuitions, counter-intuitions, and desires. It is not something we can expect to generally *require* for pull requests. It is something we can look out for.

In many cases, the person who fixes a bug or suggests a feature is not the right person to write a spec and/or unit test. The risk is that specs are over-specific. Also English may be not the right language for some to formulate their thoughts.

There are also simple and beautiful specs like “reverse(reverse(a)) == a)”, and it would be good to find and document them.
A practical question: in cases where we have found one, where should we put it?

signature.asc (application/pgp-signature, 833 B)