Include and mandatory-include behaviour in test plans
Maciej Kisielewski
maciej.kisielewski at canonical.com
Wed Jun 17 12:27:26 UTC 2015
>
> What it is a dependency. Then it will run simply because it's pulled
> into the run list automatically. What you specified is good but let's
> be explicit if we're talking about _run_ list or _desired_ list.
I approached the subject from the user perspective.
Using run_list and desired_list nomenclature, 1) should never be listed on
the desired_list.
On Wed, Jun 17, 2015 at 2:19 PM, Zygmunt Krynicki <
zygmunt.krynicki at canonical.com> wrote:
> On Wed, Jun 17, 2015 at 2:09 PM, Maciej Kisielewski
> <maciej.kisielewski at canonical.com> wrote:
> > With the advent of a field specifying mandatory jobs for test plan units
> > (which I will call 'mandatory-include' from now on), there are a few
> design
> > decisions we have to make.
> >
> > If you have better alternatives for my approach below, please, do share
> :-)
> >
> > As the job may be present in the 'include' and/or 'mandatory-include'
> > fields, we have 4 scenarios. This is my proposed behaviour for them:
> >
> > 1) not included, not mandatory-included
> >
> > Job shouldn't be available on job-selection screen. Job should never run.
> > Note that if the job is required by other job it may become visible and,
> > when selected, might be run.
>
> What it is a dependency. Then it will run simply because it's pulled
> into the run list automatically. What you specified is good but let's
> be explicit if we're talking about _run_ list or _desired_ list.
>
> >
> > 2) included, not mandatory-included
> >
> > Job should be available on job-selection screen, user should be able to
> > select and deselect it. It should be run only when selected or required
> by
> > other jobs.
> >
> > 3) not included, mandatory-included
> >
> > Job should not be listed in job-selection screen and it should ALWAYS
> run.
> >
> > 4) included and mandatory-included
> >
> > Job should be listed in job-selection screen, but user should not be
> able to
> > deselect it. It should always run.
> > Jobs that are not deselectable should be rendered differently to cue the
> > user (e.g. greyed-out)
>
> I think cases 3 and 4 are not necessary. I'd rather see that as a
> mistake and treat all cases like 4 (jobs should be visible as this is
> simply useful) but all mandatory inclusions should take precedence. If
> this happens within one test plan I would issue simple diagnostic
> during validation.
>
> >
> > As an alternative, 3) could behave like 4) with advice from validators,
> that
> > when placed in 'mandatory-include' the job doesn't have to be specified
> in
> > the 'include'.
>
> Oh, that :-)
>
> > What do you think?
> >
> > --
> > Have a good one,
> > Maciek
> >
> > --
> > Checkbox-devel mailing list
> > Checkbox-devel at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/checkbox-devel
> >
>
--
Have a good one,
Maciek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/checkbox-devel/attachments/20150617/1bd14cd6/attachment.html>
More information about the Checkbox-devel
mailing list