[Cuis] Canonical test cases?

[Wolfgang Eder]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4139 bytes
Desc: not available
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150222/d99b35da/attachment-0004.p7s>