All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: IGT development <igt-dev@lists.freedesktop.org>,
	Daniel Stone <daniels@collabora.com>
Subject: Re: [igt-dev] [PATCH i-g-t] tests/kms_getfb: Use fixtures and subtest groups
Date: Thu, 5 Apr 2018 10:44:49 +0200	[thread overview]
Message-ID: <CAKMK7uF+mQ_E7GL3KMO8MdH2qT5fBBad=rF+cR1TJVj4y0Kc7Q@mail.gmail.com> (raw)
In-Reply-To: <e5ed19e2-829e-ad2d-3968-ba0f19c8d059@intel.com>

On Mon, Apr 2, 2018 at 7:13 PM, Antonio Argenziano
<antonio.argenziano@intel.com> wrote:
>
>
> On 02/04/18 06:02, Daniel Stone wrote:
>>
>> Hi Antonio,
>>
>> On 30 March 2018 at 22:01, Antonio Argenziano
>> <antonio.argenziano@intel.com> wrote:
>>>
>>> Since both test_handle_input and test_duplicate_handles define some
>>> sub-tests and some fixtures, I think it would be better to unwrap those
>>> functions and do all fixtures and subtest definition in igt_main to make
>>> it
>>> more readable. It seems like you would also be able to reuse the same
>>> fixture across the two subtest_groups.
>>
>>
>> To be clear, does this mean that each piece of fixture and igt_subtest
>> definition should live inside main?
>
>
> I don't think there is a rule for that, it looks better that way
> (fixtures/igt_subtest/subtest_group all in the main) IMO :). Also it is what
> I've found in most if not all tests I've looked at.
>
> Still the patch makes sense with or without my suggestion.
> Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>

igt_subtest and igt_fixture in functions, to group stuff, and then
having an overall igt_subtest_group seems a perfectly fine pattern to
me. Especially with simple tests that just check tons of uapi
combinations for input validation on the kernel side igt_main
otherwise gets extermely unwieldy.

I think this here is perfectly fine as-is.

Cheers, Daniel

>
> Thanks,
> Antonio
>
>
>>
>> Cheers,
>> Daniel
>>
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

      parent reply	other threads:[~2018-04-05  8:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30 15:49 [igt-dev] [PATCH i-g-t] tests/kms_getfb: Use fixtures and subtest groups Daniel Stone
2018-03-30 16:46 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2018-03-30 17:47 ` [igt-dev] ✗ Fi.CI.IGT: warning " Patchwork
2018-03-30 18:20   ` Daniel Stone
2018-03-30 21:01 ` [igt-dev] [PATCH i-g-t] " Antonio Argenziano
2018-04-02 13:02   ` Daniel Stone
2018-04-02 17:13     ` Antonio Argenziano
2018-04-04 14:00       ` Arkadiusz Hiler
2018-04-04 16:28         ` Daniel Stone
2018-04-05  9:18           ` Arkadiusz Hiler
2018-04-05  8:44       ` Daniel Vetter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKMK7uF+mQ_E7GL3KMO8MdH2qT5fBBad=rF+cR1TJVj4y0Kc7Q@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=antonio.argenziano@intel.com \
    --cc=daniels@collabora.com \
    --cc=igt-dev@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.