From: Sergey Bronnikov via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Igor Munkin <imun@tarantool.org>, Sergey Kaplun <skaplun@tarantool.org> Cc: Sergey Bronnikov <estetus@gmail.com>, max.kokryashkin@gmail.com, tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit 1/2] test: introduce asserts assert_str{_not}_equal Date: Fri, 10 Nov 2023 14:41:50 +0300 [thread overview] Message-ID: <639a0c42-13a6-4a2e-ac4f-6077b89ff6fe@tarantool.org> (raw) In-Reply-To: <ZUIMNddwFvQ9RIq_@tarantool.org> Hi, Igor On 11/1/23 11:28, Igor Munkin via Tarantool-patches wrote: > Sergey, > > On 01.11.23, Sergey Kaplun via Tarantool-patches wrote: >> Hi, Sergey! > <snipped> > >> If some test fails we got the following output: >> >> | TAP version 13 >> | 1..1 >> | not ok 1 - lua_concat_testcase >> | --- >> | location: /home/burii/reviews/luajit/lj-881-lua-concat/test/tarantool-c-tests/lj-881-fix-lua-concat.test.c:81 >> | failed_assertion: assert_str_equal >> | got: 1652880104 >> | expected: -1138225337 >> | ... >> | # Failed 1 tests out of 1 >> >> Failed assertion field is incorrect (see the comment above). >> But the most important is "got" and "expected" fields, that returns the >> addresses of strings, which isn't very meaningful. >> >> I suggest dumping the strings instead if they are not long enough (less >> than 128 symbols, I suppose). The maxdump string length should be >> a customizeable parameter. I suggest defining a macro `MAX_DUMP_STRLEN` >> inside the <test.h> header. So the user can redefine it before the >> `assert_str_{not_}equal()` and use a custom value. >> >> If the string is too long, we should dump the offset of the mismatched >> symbol. Or maybe it's better to always dump it. >> >> Thoughts? > What if the different part starts after 128 symbols? I believe the most > valuable part is the one where the difference starts, so you have to > dump the beginning (for convenience), the difference and some numeric > parameters (length, offset where strings differ, etc). > > Furthermore, I suggest implementing <*_str_*> helpers for nul-terminated > strings and <*_mem_*> helpers for length limited memory blobs. I would postpone implementation of <*_mem_*> helpers until we will need them in tests. > >> Side note: >> >> Also, this comparing "by eye" isn't very convenient if values aren't >> aligned, so maybe it is better to use spaces instead of tabs to align >> values? This may be added within the separate patch series later. > I believe, this is quite minor thing (at least for now). > > <snipped> > >> -- >> Best regards, >> Sergey Kaplun
next prev parent reply other threads:[~2023-11-10 11:41 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <cover.1698775628.git.sergeyb@tarantool.org> 2023-09-26 6:56 ` [Tarantool-patches] [PATCH luajit] LJ_GC64: Fix lua_concat() Sergey Bronnikov via Tarantool-patches 2023-09-29 8:24 ` Maxim Kokryashkin via Tarantool-patches 2023-10-03 15:35 ` Sergey Bronnikov via Tarantool-patches 2023-10-04 10:48 ` Maxim Kokryashkin via Tarantool-patches 2023-10-06 13:51 ` Sergey Bronnikov via Tarantool-patches 2023-10-31 18:11 ` [Tarantool-patches] [PATCH luajit 1/2] test: introduce asserts assert_str{_not}_equal Sergey Bronnikov via Tarantool-patches 2023-11-01 7:40 ` Sergey Kaplun via Tarantool-patches 2023-11-01 8:28 ` Igor Munkin via Tarantool-patches 2023-11-10 11:41 ` Sergey Bronnikov via Tarantool-patches [this message] 2023-11-14 8:55 ` Sergey Kaplun via Tarantool-patches 2023-11-15 9:32 ` Sergey Bronnikov via Tarantool-patches 2023-11-16 8:02 ` Sergey Kaplun via Tarantool-patches 2023-11-18 16:40 ` Sergey Bronnikov via Tarantool-patches 2023-11-20 9:28 ` Sergey Kaplun via Tarantool-patches 2023-11-20 13:19 ` Igor Munkin via Tarantool-patches 2023-11-10 11:40 ` Sergey Bronnikov via Tarantool-patches 2023-11-23 6:31 ` [Tarantool-patches] [PATCH luajit] LJ_GC64: Fix lua_concat() Igor Munkin via Tarantool-patches
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=639a0c42-13a6-4a2e-ac4f-6077b89ff6fe@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=estetus@gmail.com \ --cc=imun@tarantool.org \ --cc=max.kokryashkin@gmail.com \ --cc=sergeyb@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit 1/2] test: introduce asserts assert_str{_not}_equal' \ /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