86/469a8a448acd5c53e3ddbbb849545c0f87f392

   1 Return-Path: <dmitry.kurochkin@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 5B34E429E21\r
   6         for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 03:46:16 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.799\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 82dbsBGRSxdl for <notmuch@notmuchmail.org>;\r
  17         Thu, 17 Nov 2011 03:46:14 -0800 (PST)\r
  18 Received: from mail-fx0-f53.google.com (mail-fx0-f53.google.com\r
  19         [209.85.161.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id A8DC5431FD0\r
  22         for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 03:46:14 -0800 (PST)\r
  23 Received: by faan15 with SMTP id n15so3213659faa.26\r
  24         for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 03:46:13 -0800 (PST)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
  27         :mime-version:content-type;\r
  28         bh=X7Gte+UMXEQF6ZV7CovNyrJjQXjYhzAUD7pOh/9XTEY=;\r
  29         b=bLJFa+mv0w3OsF1VAI06Tds98hu+KCQvNDl/cHZWQ0+eFUmYbS0BZBF8SWKlCEXtia\r
  30         c2lc5T6xKPIVa71Qt4CWsUHxvEJIdpQ0uUKFIawVcUKk4TZOakvEheKUUtUbvvu8qg+m\r
  31         tjOwwtFuyHg0nyDhHlkLaztNpVpVZ2eNVwLBc=\r
  32 Received: by 10.204.151.193 with SMTP id d1mr22600639bkw.26.1321530373187;\r
  33         Thu, 17 Nov 2011 03:46:13 -0800 (PST)\r
  34 Received: from localhost ([91.144.186.21])\r
  35         by mx.google.com with ESMTPS id fu17sm41041541bkc.9.2011.11.17.03.46.11\r
  36         (version=TLSv1/SSLv3 cipher=OTHER);\r
  37         Thu, 17 Nov 2011 03:46:12 -0800 (PST)\r
  38 From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>\r
  39 To: Thomas Jost <schnouki@schnouki.net>, notmuch@notmuchmail.org\r
  40 Subject: Re: [PATCH 0/9] test: (hopefully) better test prerequisites\r
  41 In-Reply-To: <87d3craxnx.fsf@thor.loria.fr>\r
  42 References: <1321494986-18998-1-git-send-email-dmitry.kurochkin@gmail.com>\r
  43         <87d3craxnx.fsf@thor.loria.fr>\r
  44 User-Agent: Notmuch/0.10_rc1+9~g8270095 (http://notmuchmail.org) Emacs/23.3.1\r
  45         (x86_64-pc-linux-gnu)\r
  46 Date: Thu, 17 Nov 2011 15:45:55 +0400\r
  47 Message-ID: <87ehx7nf9o.fsf@gmail.com>\r
  48 MIME-Version: 1.0\r
  49 Content-Type: text/plain; charset=us-ascii\r
  50 X-BeenThere: notmuch@notmuchmail.org\r
  51 X-Mailman-Version: 2.1.13\r
  52 Precedence: list\r
  53 List-Id: "Use and development of the notmuch mail system."\r
  54         <notmuch.notmuchmail.org>\r
  55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  58 List-Post: <mailto:notmuch@notmuchmail.org>\r
  59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  62 X-List-Received-Date: Thu, 17 Nov 2011 11:46:16 -0000\r
  63 \r
  64 On Thu, 17 Nov 2011 10:46:58 +0100, Thomas Jost <schnouki@schnouki.net> wrote:\r
  65 > On Thu, 17 Nov 2011 05:56:17 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:\r
  66 > > Hi all.\r
  67 > > \r
  68 > > The following patch series is an attempt to introduce proper\r
  69 > > dependencies for external binaries in a less intrusive way than\r
  70 > > [1].  The primary aim was to avoid changing every subtest that\r
  71 > > uses external binaries.\r
  72 > > \r
  73 > > There are still failing tests if a dependency is\r
  74 > > missing (e.g. "Verify that sent messages are\r
  75 > > saved/searchable (via FCC)" fails if there is no emacs).  It\r
  76 > > happens because such tests depend on others which are skipped.\r
  77 > > This issues are not addressed by this patch series.\r
  78 > > \r
  79 > > If others do like the approach and it is pushed, I will work on\r
  80 > > updating tests that use the old style prerequisites (atomicity).\r
  81 > > \r
  82 > > A careful review is needed!\r
  83 > > \r
  84 > > Regards,\r
  85 > >   Dmitry\r
  86 > > \r
  87 > > [1] id:"1321454035-22023-1-git-send-email-schnouki@schnouki.net"\r
  88 > \r
  89 > Hi Dmitry,\r
  90 > \r
  91 > This series looks quite good to me. It's a good approach, cleaner than\r
  92 > explicitely adding the prereqs to each test as in my previous patches\r
  93 > (and Pieter's).\r
  94 > \r
  95 > Now, a few questions:\r
  96 > \r
  97 > - same as Jamie: emacs_deliver_message hangs if dtach is not installed.\r
  98 >   In my patches I had to do this: "test_have_prereq EMACS &&\r
  99 >   emacs_deliver_message ...". Any idea how to handle this?\r
 100 > \r
 101 \r
 102 Answered to Jamie already.  That is a separate bug which is fixed in [1].\r
 103 \r
 104 > - what about indirect, "hidden" dependencies? The crypto test need to\r
 105 >   have a signed message delivered by emacs, so actually *all* the crypto\r
 106 >   tests depend on emacs. Right now, when dtach is not installed, the\r
 107 >   first test ("emacs delivery of signed message") is skipped and all the\r
 108 >   others fail. Would it be possible to handle this case without having\r
 109 >   to add explicit prereqs?\r
 110 > \r
 111 \r
 112 Dependencies between the tests are not trivial (e.g. a test expects\r
 113 notmuch to have a message delivered by the previous one).  I see two\r
 114 solutions here:\r
 115 \r
 116 * Remove such dependencies.  E.g. the code which sends a message may be\r
 117   put in a function.  Every test who needs it will call that function.\r
 118   No dependency on a previous test.\r
 119 \r
 120 * Declare explicit prerequisites in some tests and use them in other\r
 121   tests.  IMO this is the only proper way to handle dependencies between\r
 122   tests.\r
 123 \r
 124 We can (and probably should) use both approaches to resolving such\r
 125 dependencies.\r
 126 \r
 127 We can make it easier to implement the latter approach: add a function\r
 128 like test_other_subtest_prereq which takes ID of subtests this one\r
 129 depends on.  This way every subtest implicitly provides a prerequisite\r
 130 later test can depend on.  Still we would have to explicitly check the\r
 131 prerequisite in every test case that needs it.  I see no way to get rid\r
 132 of it.\r
 133 \r
 134 Note that inter-subtest dependencies is an existing issue.  Currently,\r
 135 you can skip a single test.  Then all others that depend on it would\r
 136 fail.\r
 137 \r
 138 Also, we can move common stuff that is used by all subtests to the test\r
 139 initialization (before the first subtest).  Then if it fails, all\r
 140 subtests would be skipped.  Because of this all crypto tests would be\r
 141 skipped if gpg is not installed.\r
 142 \r
 143 > - right now functions like test_expect_success can be used as\r
 144 >   "test_expect_success COMMAND" or "test_expect_success PREREQ COMMAND".\r
 145 >   If we use your approach (and I hope we will!), do we need to keep that\r
 146 >   second syntax available in test-lib.sh too, or should we do some\r
 147 >   cleanup to get rid of it?\r
 148 > \r
 149 \r
 150 At first, I wanted to clean it up.  But then I decided to leave it.  The\r
 151 "old-style" prerequisites are more general.  So this patch series does\r
 152 not fully replace it.  Besides there are tests that use it now\r
 153 (atomicity at least), I have not updated them yet.\r
 154 \r
 155 We may use general prerequisites for inter-subtest dependencies (though,\r
 156 we probably can make it a little more convenient, see above).\r
 157 \r
 158 I am not sure if we should remove general prerequisites even if they are\r
 159 not used.  They work and they do not hurt.  I will left it for others to\r
 160 decide.\r
 161 \r
 162 Regards,\r
 163   Dmitry\r
 164 \r
 165 [1] id:"yf639dnsqtc.fsf@taco2.nixu.fi"\r
 166 \r
 167 > Thanks,\r
 168 > \r
 169 > -- \r
 170 > Thomas/Schnouki\r