Canonical test cases?

On Mon, 23 Feb 2015 14:43:26 -0500

"Phil (list)" <pbpublist at gmail.com> wrote:

>> I started playing around with a couple of example test cases to see what

>> I ran into and came up with a distinct class to store all of these per

>> test category (i.e. under Test-Files a class ApiFile which could have a

>> method testWriteTextFile)  The rationale was that it might make sense to

>> keep these test cases separate from traditional test cases which are

>> free to make calls that users of the class (i.e. who are calling the

>> supported API) should not.

>You bring up a good point.

>I suspect there are three basic cases:

>  [1] A number of small test cases for a wide, shallow API.  E.g. Collection classes.  Many "small" usage tests.

>  [2] A few deep calls which demonstrate a usage protocol.  E.g. open/read/close files, sockets; use library wrapper.

>  [3] Sample/example UI code which illustrate how to build apps/applets/tools  [Color Picker, File List, ..]

>A test class, as you point out, is probably appropriate for case [1], where there would be a zillion >test<collection><access>API kinds of things would swamp a name search.  A class naming convention would be good here.

>Individual test methods, with a searchable name convention, would be best for [2] where there would be few illustrative usage tests.

>We could call out example code in a README doc for [3] where examples might have auxiliary architectural documentation.

It just so happens that I've been looking at porting the terse guide from Squeak and that effort may have some bearing on the above. The Squeak terse guide brings with it the help manager and therefore a lot of stuff requiring rewrites. However, a much lighter weight and more readable version can be had by using the existing facilities of Cuis. What you see when you open a topic is code which has the same appearance as in a browser. I'm still wrangling a UI for it, but as it stands you can do:

    TerseGuideHelp display: #<topic>

to see a Workspace with the text presented by SmalltalkEditor. <topic> is from #pages in the Squeak guide.

- Dan Norton

On Mon, 23 Feb 2015 14:43:26 -0500

"Phil (list)" <pbpublist at gmail.com> wrote:

>> I started playing around with a couple of example test cases to see what

>> I ran into and came up with a distinct class to store all of these per

>> test category (i.e. under Test-Files a class ApiFile which could have a

>> method testWriteTextFile)  The rationale was that it might make sense to

>> keep these test cases separate from traditional test cases which are

>> free to make calls that users of the class (i.e. who are calling the

>> supported API) should not.

>You bring up a good point.

>I suspect there are three basic cases:

>  [1] A number of small test cases for a wide, shallow API.  E.g. Collection classes.  Many "small" usage tests.

>  [2] A few deep calls which demonstrate a usage protocol.  E.g. open/read/close files, sockets; use library wrapper.

>  [3] Sample/example UI code which illustrate how to build apps/applets/tools  [Color Picker, File List, ..]

>A test class, as you point out, is probably appropriate for case [1], where there would be a zillion >test<collection><access>API kinds of things would swamp a name search.  A class naming convention would be good here.

>Individual test methods, with a searchable name convention, would be best for [2] where there would be few illustrative usage tests.

>We could call out example code in a README doc for [3] where examples might have auxiliary architectural documentation.

It just so happens that I've been looking at porting the terse guide from Squeak and that effort may have some bearing on the above. The Squeak terse guide brings with it the help manager and therefore a lot of stuff requiring rewrites. However, a much lighter weight and more readable version can be had by using the existing facilities of Cuis. What you see when you open a topic is code which has the same appearance as in a browser. I'm still wrangling a UI for it, but as it stands you can do:

    TerseGuideHelp display: #<topic>

to see a Workspace with the text presented by SmalltalkEditor. <topic> is from #pages in the Squeak guide.

- Dan Norton