On Mon, May 02, 2016 at 01:49:08PM +0200, Xavier Hernandez wrote:
> Hi,
>
> I've found an spurious failure caused by an incorrect check of the expected
> value in EXPECT_WITHIN.
>
> The problem is that the value passed to EXPECT_WITHIN (EXPECT also has the
> same problem) is considered a regular expression but most tests do not pass
> a full/valid regular expression.
>
> For example, most tests expect a '0' result and they pass "0" as an argument
> to EXPECT/EXPECT_WITHIN. This will match with "0", that's ok, but it will
> also match with 10, 20, 102, ... and that's bad.
>
> There are also some tests that do use a regular expression, like "^0$" to
> correctly match only "0", however current implementation of EXPECT_WITHIN
> uses the following check:
>
> if [[ "$a" =~ "$e" ]]; then
>
> Where "$e" is the regular expression. However putting $e between quotation
> marks (") makes special regular expression characters to not be considered.
> This means that "^0$" will be searched literally and it won't never match.
> When the timeout expires, test_expect_footer is called, which does the same
> check but without using quotation marks. At this time the check succeeds,
> but we have waited an unnecessary amount of time.
>
> This is not the first time that I've found something similar.
>
> Would it be ok to change all regular expression checks to something like
> this in include.rc ?
>
> if [[ "$a" =~ ^$e$ ]]; then
>
> This will allow using regular expressions in EXPECT and EXPECT_WITHIN, but
> will enforce full answer match in all cases, avoiding some possible side
> effects.
>
> This needs some changes in many tests, but I think it's worth doing.
>
> What do you think ?
Sounds like a good approach to me. New test-cases will fail if
developers dont use it correctly, so they'll fix it automatically. How
much work is it to fix existing tests?
Thanks,
Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
