Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: sergeyb@tarantool.org
Cc: o.piskunov@tarantool.org, tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v2] Add option to update file with reference output
Date: Wed, 3 Jun 2020 20:27:11 +0300	[thread overview]
Message-ID: <20200603172711.2dmy5bfekkzhi4as@tkn_work_nb> (raw)
In-Reply-To: <e0f00f4f70d21f8ae251ed5dd73b403257c65440.1589883920.git.sergeyb@tarantool.org>

I'm mostly okay with the patch, but decided to share several thoughts
around it. Whether you'll follow them or not, I'll consider it
ready-to-go. Just ping me, when you'll update everything that you want
to update.

WBR, Alexander Turenko.

> diff --git a/lib/test.py b/lib/test.py
> index 8bc1feb..733b90c 100644
> --- a/lib/test.py
> +++ b/lib/test.py
> @@ -15,6 +15,7 @@ except ImportError:
>      from StringIO import StringIO
>  
>  import lib
> +from lib.options import Options

Unused.

flake8 complains about this.

> @@ -235,9 +236,20 @@ class Test(object):
>          elif (self.is_executed_ok and not
>                self.is_equal_result and not
>                os.path.isfile(self.result)) and not is_tap:
> +            if lib.Options().args.update_result:
> +                shutil.copy(self.tmp_result, self.result)
> +                short_status = 'new'
> +                color_stdout("[ new ]\n", schema='test_new')
> +            else:
> +                short_status = 'fail'
> +                color_stdout("[ fail ]\n", schema='test_fail')

(In brief: there are two way to do so; please choose one, which looks
better for you.)

In [1] I proposed to keep this if-elif-else branching to be splitted by
status and to fall into 'else' at fail. The reason is that the 'else'
branch already do everything that we should do at fail: print output
diff, tarantool log, valgring log where appropriate.

However in this certain case we have nothing to report:
self.is_crash_reported is set to True in check_tap_output() and 'TAP13
parse failed' message is already shown.

So I would just note that falling into 'else' branch would look more 'in
the spirit' of this code block, but I would let you decide how the code
would look better.

The change upward your patch would look so:

-        elif (self.is_executed_ok and not
-              self.is_equal_result and not
-              os.path.isfile(self.result)) and not is_tap:
-            if lib.Options().args.update_result:
-                shutil.copy(self.tmp_result, self.result)
-                short_status = 'new'
-                color_stdout("[ new ]\n", schema='test_new')
-            else:
-                short_status = 'fail'
-                color_stdout("[ fail ]\n", schema='test_fail')
+        elif (self.is_executed_ok and
+              not self.is_equal_result and
+              not os.path.isfile(self.result) and
+              not is_tap and
+              lib.Options().args.update_result):
+            shutil.copy(self.tmp_result, self.result)
+            short_status = 'new'
+            color_stdout("[ new ]\n", schema='test_new')

(Also moved 'not' from line ends, because it was confusing.)

Actual behaviour of both variants is the same.

BTW, the 'TAP13 parse failed' message may now appear in the case, when
non-tap13 test fails and --update-result option is not passed. I would
add a few words here, like: 'No result file found. TAP13 parse failed'.
Maybe even 'Run the test with --update-result option to write the new
result file' on a separate line. It would give a developer better
understanding what actually occurs.

[1]: https://lists.tarantool.org/pipermail/tarantool-patches/2020-May/016775.html

> +        elif (self.is_executed_ok and
> +              not self.is_equal_result and
> +              os.path.isfile(self.result) and
> +              lib.Options().args.update_result):
>              shutil.copy(self.tmp_result, self.result)
> -            short_status = 'new'
> -            color_stdout("[ new ]\n", schema='test_new')
> +            short_status = 'updated'
> +            color_stdout("[ updated ]\n", schema='test_new')

It looks okay.

>          else:
>              has_result = os.path.exists(self.tmp_result)
>              if has_result:
> @@ -256,7 +268,8 @@ class Test(object):
>                  server.print_log(15)
>                  where = ": test execution aborted, reason " \
>                          "'{0}'".format(diagnostics)
> -            elif not self.is_crash_reported and not self.is_equal_result:
> +            elif (not self.is_crash_reported and not self.is_equal_result and
> +                not lib.Options().args.update_result):
>                  self.print_unidiff()
>                  server.print_log(15)
>                  where = ": wrong test output"

As far as I see, we should not fall here, when --update-result is passed
(I failed to find any such situation). But even if it would be possible,
it would be not correct to just hide diff and set 'fail' status under
--update-result.

I think it is safe enough to assume that update_result is False when
we're going to report failed status due to different results. I would
just remove this check and left the code as is.

  parent reply	other threads:[~2020-06-03 17:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 10:25 sergeyb
2020-05-20  8:03 ` Alexander V. Tikhonov
2020-05-20  8:23   ` Sergey Bronnikov
2020-06-03 17:27 ` Alexander Turenko [this message]
2020-06-04 13:07   ` Sergey Bronnikov
2020-06-08  9:19     ` Alexander Turenko
2020-06-08 15:31       ` Sergey Bronnikov

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=20200603172711.2dmy5bfekkzhi4as@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=o.piskunov@tarantool.org \
    --cc=sergeyb@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v2] Add option to update file with reference output' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox