Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

On 21/10/11 16:04, Michael Meeks wrote:
> Hi August,
>         Well - of course, it'd be nice to have some more complex tests of
> StarBasic (and VBA) macros, potentially loaded from .bas files inside a
> unit test.
>
>         Noel - do you have any really nasty syntax / built-in basic
> functionality corner cases embedded into xls files that could be
> extracted and turned into compile-time unit tests in basic/ ?
hmm off hand can't think precise hard examples, we surely have known 
problems buried in bug reports that we have previously identified ( 
specifically to do with VBA compatability mode ) . But.. I guess that's 
not the focus here, I suppose the idea here is to regression and/or unit 
test existing behaviour ? Probably we want to split testing of 'normal' 
basic v's 'vba compatability mode' basic.

Unit testing the the core basic is of course a good idea but I would 
imagine very very time consuming, another problem is related to the 
question below
> I'm also curious about VBA
> support and whether there exists a grammar or similar documentation
> for the StarBASIC language.
sorry to say I don't know of any such descriptions :-( and this is one 
of the problems at least for 'normal' basic operation where the 
historical behaviour of libreoffice/openoffice basic is more or less 
taken as the specification, it can be unclear as to whether some 
behaviour is intended or just a bug. Behaviour around visibility 
specifier ( public. private etc. ) come to mine here which are more or 
less ignored for 'historic' reasons

My gut feeling for testing basic is it is probably easier to write stand 
alone macros that self test themselves  either deployed as mentioned  in 
some sort of flat file or in a document ( not sure how easy/hard it is 
to get basic to use a standalone file ). Certainly I see the use for 
more finegrained unit tests like the one shown in this thread when 
modifying the core code  maybe to check runtime behaviour pre/post 
changes. Personally I don't think I would write such tests 'cold' ( of 
course no reason why you shouldn't if you really want to, this is just 
my personal opinion )

We have some bit-rotting vba tests in sc/source/ui/vba/test, most of 
these aren't really self testing but relied on writing output to a log 
file and comparing the results with 'known' output. This didn't work 
that well ( ambiguous output, differently output of different platforms 
etc. ) it would be great to get at least some of those converted to run 
within the qa test framework that moggi is working on. ( hopefully I can 
update with details of some updated test there later today )

Regarding the core basic I am of the opinion that even simple testing 
that captures the existing behaviour of things like precedence, results 
of logical/bitwise/arithmetic operators on different data types etc. 
that could serve as regression tests are useful. Part of the problem 
here is the scope for testing is quite huge

Noel