From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff McGee Subject: IGT conventions Date: Wed, 15 Jan 2014 17:26:28 -0600 Message-ID: <20140115232628.GC14542@jeffdesk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 810ABFD491 for ; Wed, 15 Jan 2014 15:20:05 -0800 (PST) Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org I have a few questions about conventions observed in writing IGT tests. I don't see any standard wrapper for logging other than the logging that goes with certain igt_ control flow functions. Is it recommended to limit logging to just these? I see some different approaches to supporting verbose modes. Is it just up to each test? Any recommendations on subtest granularity? Testing boils down to repeated cycles of 'do something' then 'assert something'. Just wondering if there is a guideline on how many of those cycles should each subtest contain. Probably this is very case specific. Also wondering if something like an igt_warn function to go with igt_require and igt_assert has been considered. There might be a case where some condition is not met which causes the test to become limited in its effectiveness but still valid. We might still want to run the test and let it pass but attach a caveat. Or would adding this gray area just be too complicating. Thanks Jeff