Re: test vs check naming consistency
Using these definitions, anything run in taskotron that reports a
PASS/FAIL/OTHER status (ie, everything) would be a check. I'm not
saying that checks are bad or anything like that, just that there are
limitations to what a check (and an automated check, in particular) can
do.
My main motivation is to give more clarity to emails in this mailing list, because the
word 'test' is really overloaded with meaning in our field of work. I think that
if we start calling taskotron-runnable tasks 'checks', and use 'tests'
only for unit tests etc, it will be easier for all of us to understand what we try to say.
And of course the end-user (new check developer) can benefit as well. If I understood you
correctly, you're fine with this distinction.
> At the moment, I'm working on porting autoqa.test.TestDetail
class
> into Taskotron. When following these directions, I guess it should be
> called libtaskotron.check.CheckDetail then?
Yes, pretty much anything that was a test in autoqa would be a check in
the context of taskotron.
OK, I'll update my review request.