[Cuis] Canonical test cases?

[H. Hirzel]

Hi Phil and Wolfgang

Test cases mentioned by Phil are

T1. canonical examples of how to compress/decompress files/streams

T2. package loading. Phil writes "I've been calling CodePackageFile
installFileStream:packageName:fullName: but that no longer appears to be
the correct entry point if I want dependency checking"

Are there more?

There is as well a workspace called 'useful expressions' which might
be used to add a few of these test cases.

And updates to these files

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation
(just fork the Cuis repo, update the md file and issue a pull request)

You may as well add an issue
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues

like I just did for T1 and T2
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/39

--Hannes


On 2/22/15, Wolfgang Eder <edw at generalmagic.at> wrote:
> hi,
> I believe you have an excellent point here!
> I believe that tests are a very valuable and fitting
> way of documenting an API.
>
> And I believe that there needs to be a distinction made
> alone the lines of blackbox vs. whitebox testing,
> where the distinction is whether the internal functioning
> is tested or not.
>
> Blackbox tests should test just the API, treating the code
> as a "black" box, meaning it does not assume or know a lot
> about its internal workings.
>
> Whitebox tests should test the internal workings, and these
> may break, or not even compile, when refactorings or
> restructurings are done.
>
> My point is, all tests need to be documented whether
> they are blackbox or whitebox tests, because a user of the
> code and tests needs to know whether the tests are
> testing the API or the inner workings of the code.
>
> kind regards
> wolfgang
>
>
>
>> Am 22.02.2015 um 01:02 schrieb Phil (list) <pbpublist at gmail.com>:
>>
>> My code migration to Cuis 4.2 has gone from a saga to an ordeal... lots
>> of breakage.  As I've been going through and fixing things I am thinking
>> that I'm possibly going from doing some things in a broken way in
>> Squeak/earlier Cuis to a broken way in current Cuis simply because I
>> don't know what the 'correct' way is.
>>
>> One example is related to compression: there aren't any canonical
>> examples of how to compress/decompress files/streams so I poke around
>> the classes until I get to something that works for me right now having
>> no idea if what I come up with will still work a few versions from now.
>> Another example is package loading: I've been calling CodePackageFile
>> installFileStream:packageName:fullName: but that no longer appears to be
>> the correct entry point if I want dependency checking.  While I
>> understand that things are subject to change, would it make sense to
>> have some documented, fixed entry points that would attempt to make the
>> most sane choices by default going forward?
>>
>> My thought was why not use test cases to help document the preferred
>> (and therefore, longer term supported) way of doing things.  They could
>> be put in Tests-Examples or something similar and could serve double
>> duty in the sense that they would not only help point people in the
>> right direction on how to use a given class, but would also serve as a
>> warning/reminder to anyone wanting to make changes that these are the
>> core calls that need to be maintained from a code compatibility
>> standpoint or otherwise need to be called out when compatibility needs
>> to be broken.  I imagine this would be a fairly small subset of
>> classes/methods and not try to anticipate all the edge cases, just deal
>> with the most common ones.
>>
>> Does what I'm suggesting make sense / seem worthwhile?
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>