[Gridflow-dev] test suite (fwd)

[Claude Heiland-Allen]

Hi,

I think automated tests are a good thing too, and the [#expect] object 
sounds reasonable too.

I'm not sure how to fully automate tests in Pd though - my ideal output 
would be like configure's output - a text list of tests with 
passed/failed, with more info on failure - a patch-loader patch 
controlled with pdsend could do the job, if each testpatch runs its 
tests and closes itself when done?

Basically the minimum of interaction, one command to activate the 
test-suite.

I think a text to guide human testers for non-fully-automatable display 
objects would be essential, too.


Claude

Alexandre Castonguay wrote:
> Bonjour Mathieu,
> 
> I agree with automating the tests, what do ou have in mind for the GUI tests?  
> 
> Cheers,
> 
> Alexandre
> 
> Le Samedi 12 Novembre 2005 01:54, Mathieu Bouchard a écrit :
> 
>>any comments on the following?
>>
>>---------- Forwarded message ----------
>>Date: Wed, 13 Jul 2005 19:07:32 -0400 (EDT)
>>From: Mathieu Bouchard <matju at artengine.ca>
>>To: gridflow-dev at artengine.ca
>>Subject: [Gridflow-dev] test suite
>>
>>
>>GridFlow could afford a better test suite. base/test.rb should be replaced
>>by something more appropriate i'm thinking something that would look like:
>>
>>[#expect, send 1 2 3, get 4 5 6] X [# + 3]
>>
>>so [#expect] would be a new control object destined to do quality
>>assurance. actually there's already one sort of like that in
>>base/test.rb, but it's not usable outside of Ruby.
>>
>>there could be a [, radius 42] option so that instead of using exact
>>equality like [# ==] -> [#ravel] -> [#fold &] it would use euclidean
>>distance [# sq-] -> [#ravel] -> [#fold +] -> [# sqrt] as is used in
>>statistics and acoustics to evaluate the energy or the RMS amplitude.
>>Alternatively it could use manhattan distance [# abs-] -> [#ravel] ->
>>[#fold +] which is what used in chemistry labs to compute error
>>propagation. Which one to use could be controlled by a message "norm 2"
>>and "norm 1" respectively.
>>
>>This "radius" extension to the normal Extreme Programming testing is
>>necessary to address two issues:
>>
>>1. the usual equality testing can't be used successfully with floats
>>   because slight deviations in computation can be obtained quite easily.
>>   For example you just can't rely on (A+B)+C==A+(B+C), ever, although the
>>   error radius could usually be about 16 million times smaller than the
>>   involved numbers.
>>
>>2. similar rounding issues can occur in integer math and that it can be
>>   sometimes okay for one high-level effect to yield slightly different
>>   numbers as long as it appears roughly the same on-screen.
>>
>>Other automated testing patterns should be developed to address issues
>>such as testing GUI objects like [display] [#peephole] [#edit].
>>
>>Possibly that it's time to introduce semi-automated testing, in which the
>>part that is fully automatable gets automated, but is interleaved with
>>documentation taking the tester by the hand, so that the tester doesn't
>>have to think too much and doesn't forget what it is s/he is supposed to
>>test; this makes testing time shorter thus tests become more affordable.
>>
>>What do you think?
>>
>>,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow |
>>
>>| The Diagram is the Program tm| | ,-o-------------o--------------o-.
>>
>>`-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) |
>>
>>  | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
>>
>>_______________________________________________
>>Gridflow-dev mailing list
>>Gridflow-dev at artengine.ca
>>http://ns.artengine.ca/mailman/listinfo/gridflow-dev
>>
>>_______________________________________________
>>Gridflow-dev mailing list
>>Gridflow-dev at artengine.ca
>>http://ns.artengine.ca/mailman/listinfo/gridflow-dev
> 
> 
> _______________________________________________
> Gridflow-dev mailing list
> Gridflow-dev at artengine.ca
> http://ns.artengine.ca/mailman/listinfo/gridflow-dev