[Cuis] Fwd: Re: DIRECT version number

[Peter van Rooijen]

On Mon, Jul 20, 2015 at 3:55 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

>
> If you have specific requirements, a package with Feature/Unit-tests is a
> good way to express this.
>

I was thinking: "What should a Feature Test be?". I tried to look up what
others have written, but found nothing useful (I probably did not look hard
enough). Now, I don't mind thinking of something new, so here goes:

1. Clearly (to me), it should not be a kind of Unit Test. When you run a
unit test, you assume that the unit under test is present in the system and
you are trying to ascertain if it does certain things you expect. For this,
unit tests have built-in facilities to detect execution errors and failed
expectations, If such problems happen, unit tests are able to continue the
testing process and report on the problems that occurred after the tests
are run (this is the step forward that SUnit - or TSTTestingFramework as it
ws known at the time - brought).

2. On the other hand, when you run a Feature Test, you may be testing one
or more units, and one or more (or all) of those might not even be present.
Therefore, a feature test should be able to run even if in the absence of
the unit(s) supposed to implement the feature. So then, perhaps what a
class FeatureTest should offer its subclasses, is a #run: aString method
that tries to compile aString and if it compiles, execute it and look for
any foreseen side effects and/or expression value.

a test method might then look like:

testApiReceiverIsPresentAndCanBeSetUp

self run: 'ApiReceiver version > ''1.1.4''' expectEvaluationResult: true
.
self run: 'ApiReceiver setUp'
.
self expectSideEffect: 'ExpectedApiReceiver isSetUp'

3. Then it should be able to report that everything went well, or that
there was a problem compiling (ideally with detailed info such as 'global
Xxx was expected but was not present in the system'. If compiling went
well, the execution should be protected and monitored similarly to unit
tests that are already able to catch exceptions during execution.

4. Perhaps something along these lines would be the simplest thing that
could possibly work?

Would it help anyone if they had the FeatureTest class that they could
subclass and as a result they could always, safely, test if some feature
was present and did what you needed/expected of it? And you could have a
Feature Test Runner that ran your feature test, made sure nothing crashed,
and reported the results in a useful fashion.

Just some thoughts, cheers, Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150720/9cfb5cc4/attachment-0004.html>