Hello Peter
I think your proposal to check the presence of an API is very interesting.
You suggest to have API descriptions in form of classes in an external
package which test the presence of an API.
Contrariwise to unit tests they only look for the presence of a
classes with certain methods.
It is an external tool (i.e. not included in the core) to check the
presence or absence of an API.
These tools can focus on a certain part of the system which is of a
particular interest for an external package and be kept with that
package.
--Hannes
On 7/19/15, Peter van Rooijen <
[hidden email]> wrote:
> Hey all,
>
> Just 2 cents from a Cuis noob:
>
...
>
A. Increase the number of improvements
> So, I am for adopting practices that increase the number of improvements.
B. Decrease the number of deterioations
> Practices that decrease the number of deteriorations seem helpful as well.
> See below if you wonder what my point is ;-).
>
...
> 3. Maybe what will help everybody is something that prevents functionality
> from being lost, especially *unintentionally*. This can include certain
> APIs as well. So what if an author who values a certain API, could invest
> some of his own time/money, to protect that API? What if he could write a
> software component (let's say a class) that was able to detect whenever an
> image did not provide the desired API? What if he could submit that class,
> and everybody who cared about not breaking that API, could use that class
> to see if perhaps they broke it?
>
> 4. I believe the idea could be generalized to include any feature of (the
> code in) an image for which presence or absence (as may be the case) can be
> determined by such a class. Bugs could be reified as classes, and the
> presence or absence of the bug could be determined by that class. Feature
> requests could be reified as classes, and whether or not the feature had
> actually been implemented could be determined by that class.
>
> 5. The things I am proposing would basically be Feature Tests, and would be
> rather different from Unit Tests (which apply to a unit and which you want
> to all be green when you share your software with users of it). Feature
> Tests would apply to a system (not a unit) and simply indicate which
> features are and which features are not present in the system. Every
> "release" could then come with a) the assertion that all the Unit Tests
> passed b) a list of the Feature Tests that passed and those that did not.
>
> 6. I think it would be pretty cool if people sent in feature requests in
> the form of Feature Tests, instead of messages to the mailing list (or the
> request tracker). So that anybody who (wished to impress somebody and) had
> some time on their hands, could then try to implement the functionality
> that made the Feature Test pass.
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Locked
