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.
next prev 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