[OpenStack-DefCore] Please review - lexicon, Public APIs only & capabilities definition text

Rob_Hirschfeld at Dell.com Rob_Hirschfeld at Dell.com
Fri May 2 21:11:08 UTC 2014


Dell - Internal Use - Confidential
Rocky & Will,

This is a bootstrapping problem.  Ideally Capabilities exist before tests; however, we're in the position where the only _verifiable_ capabilities today are build backwards from the existing test base.  That's why we always describe DefCore as iterative and incremental - we start where we can and don't wait for everything to be perfect.

The alternative is to score tests individually and that was overwhelming.  Troy's work to help cluster the tests has been instrumental to making progress.

While we could have called them "test clusters,"  the word capability is clearer and accurate.

I very much want to see use define capabilities and then tests.  Hopefully, our work here will encourage the community to invest yet more time into that needed work.

Rob

From: Rochelle.RochelleGrober [mailto:rochelle.grober at huawei.com]
Sent: Friday, May 02, 2014 2:04 PM
To: Hirschfeld, Rob; will.auld at intel.com; mark at openstack.org
Cc: Defcore-committee at lists.openstack.org
Subject: RE: [OpenStack-DefCore] Please review - lexicon, Public APIs only & capabilities definition text

Rob,

Yes, the tests define the capability, but the capability is not the tests.  By defining the function and saying there are no tests, hence no capability, those capabilities can still be identified for test development.  By not allowing even a named function if the tests don't exist, it becomes harder to identify sets of tests that need to be implemented.  I don't know exactly how to state it with adjectives to the capability noun, but something like "existing (or implemented or stable) capability" and "desired (or experimental or ?) capability.  Not sure, but we need to highlight capabilities that should be there but can't be for lack of tests.

--Rocky



From: Rob_Hirschfeld at Dell.com<mailto:Rob_Hirschfeld at Dell.com> [mailto:Rob_Hirschfeld at Dell.com]
Sent: Friday, May 02, 2014 6:12 AM
To: Rochelle.RochelleGrober; will.auld at intel.com<mailto:will.auld at intel.com>; mark at openstack.org<mailto:mark at openstack.org>
Cc: Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>
Subject: RE: [OpenStack-DefCore] Please review - lexicon, Public APIs only & capabilities definition text

Rocky & Will,

Here's the challenge > DefCore uses the tests to define core and we are constrained by what exists.   This was part of the discussion leading up to the principle definition.  I agree that it would be ideal to have the capabilities first and then map the tests; however, that would be more confusing in this context.

For now, using tests to define capabilities is a very helpful construct(tm).  I hope that the community is inspired to do what you are suggesting and identify capability gaps and then write code/tests to verify them.  Really, that's what blueprints are supposed to be.  Until that day arrives, we're playing the hand that we have.

Rob

Will Auld wrote:
I think this should apply to any product, commercial or otherwise, for which we grant a license.

As for my problem with "Capability," I think it should be more about the functionality than the tests:

Capability - the functionality ensured by a set of tests collected into a group as defined by the technical community (the DefCore committee has made preliminary assignments to start the process)

Yes, I agree that a capability is not "a set of tests" so much as a set of behaviors/interactions/functionality demonstrated by the system under test through the exercise of the specified test set.

--Rocky

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140502/eb94b06f/attachment-0001.html>


More information about the Defcore-committee mailing list