Re: Package-specific test case and critical path test case project: drafts for review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2011-01-04 at 17:57 +-0000, Adam Williamson wrote:
+AD4 On Mon, 2011-01-03 at 10:52 -0500, James Laska wrote:
+AD4 
+AD4 +AD4 Agreed ... I think it makes sense to keep Category:Test+AF8-Cases as just a
+AD4 +AD4 container for sub-categories if possible.  Mainly for the reasons you
+AD4 +AD4 note around +ACo-trying+ACo to keep content organized.
+AD4 
+AD4 OK. I think I actually went ahead and changed this in the current
+AD4 version, I'll go back and double check.
+AD4 
+AD4 +AD4 My
+AD4 +AD4 question (I guess I already re-stated above) was whether you consider
+AD4 +AD4 the terms +ACI-core+ACI and +ACI-extended+ACI as a designation of test case priority?
+AD4 
+AD4 Yes. The terms themselves aren't hugely important, sure, it's more
+AD4 expressing the concept of priorities, but I kind of conceived it in
+AD4 terms of the importance of the functionality being tested.

Gotcha, thanks.

+AD4 +AD4 Outside of the terminology, I have some concerns whether this is within
+AD4 +AD4 the scope of the initial project, or something we want to leave as a
+AD4 +AD4 phase+ACM-2 effort.  We definitely need to think about it as non-critpath
+AD4 +AD4 tests will come in, I just hope we don't spend all our collective energy
+AD4 +AD4 on defining non-critpath tests and then we are still exposed to a lack
+AD4 +AD4 of test documentation for the critpath.
+AD4 
+AD4 My thinking here is that one of the typical workflows for creating test
+AD4 cases will be 'let's create a set of test cases for package X'. Say the
+AD4 maintainer of package X decides to contribute some test cases. I suspect
+AD4 it's quite unlikely they'll restrict themselves strictly to critical
+AD4 path functionality in all cases+ADs so we should already have the
+AD4 groundwork for non-critical-path test cases laid out.

I see.  Yeah, we certainly need to be prepared for tests created outside
the initial scope.

+AD4 +AD4 +AD4 possibly. I was meaning those bits to be read simply as a potential
+AD4 +AD4 +AD4 illustration of programmatic use of the categories to illustrate why
+AD4 +AD4 +AD4 consistent categorization is important, but if you think it's confusing,
+AD4 +AD4 +AD4 we could take it out.
+AD4 +AD4 
+AD4 +AD4 No strong opinions here.  I thought I learned somewhere that one should
+AD4 +AD4 avoid future leading statements when documenting process.  I could have
+AD4 +AD4 sworn that was in the Fedora doc guide ... but I could be making it up.
+AD4 
+AD4 I'd agree with that - again the idea was to illustrate a design concept
+AD4 ('this is designed this way in order to enable this kind of programmatic
+AD4 usage') rather than to prescribe a particular form of programmatic usage
+AD4 on the part of particular tools. I tried to re-write it to be less
+AD4 specific in a later draft that's up now, is it better?

That looks good.  Your pages are looking really good IMO, thanks for the
time+-energy you've invested.

Thanks,
James

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux