should issueshttps://gitlab.inria.fr/vidjil/should/-/issues2024-02-09T10:31:45+01:00https://gitlab.inria.fr/vidjil/should/-/issues/74JSON not ok if no value present in dict2024-02-09T10:31:45+01:00THONIER FlorianJSON not ok if no value present in dictBy json; I try to check an empty dict but it fail.By json; I try to check an empty dict but it fail.https://gitlab.inria.fr/vidjil/should/-/issues/73JSON match by value matches only a factor of the value2023-06-08T19:03:58+02:00Mikaƫl SalsonJSON match by value matches only a factor of the valueIn the examples given in [json.should](https://gitlab.inria.fr/vidjil/should/-/blob/master/demo/json.should), we can see that with JSON we don't need to have an identical value to pass the test. For instance `rth` matches one value, so t...In the examples given in [json.should](https://gitlab.inria.fr/vidjil/should/-/blob/master/demo/json.should), we can see that with JSON we don't need to have an identical value to pass the test. For instance `rth` matches one value, so the test passes, even if there is no value that is equals to `rth`.
I understand the point as `should` is based on matching. However this is a bit counter-intuitive regarding value matching in the JSON output, where one would expect an identity. This is especially the case for integer matching. Still in json.should, this test:
```
j:numbers:12
```
would also pass with `j:numbers:2` as `2` matches the numbers, even though there is no number 2.
I know that I can use a regex to match the whole value (eg. `rj:numbers:^2$` to check if a value is 2) but this is not my point.https://gitlab.inria.fr/vidjil/should/-/issues/72Build tmLanguage file2023-01-05T15:20:02+01:00Thonier FlorianBuild tmLanguage fileI have make two tmLanguage file for tap and should-get file.
This can be use with vscode and probably sublimetext and other text editor.
Question: how to distribute these files ? Present in git repository of should ? Distribute the vsc...I have make two tmLanguage file for tap and should-get file.
This can be use with vscode and probably sublimetext and other text editor.
Question: how to distribute these files ? Present in git repository of should ? Distribute the vscode extension ?https://gitlab.inria.fr/vidjil/should/-/issues/71Allow to install should by pip2023-01-05T15:12:47+01:00Thonier FlorianAllow to install should by pipI wanted to launch should pipeline without having to find path of script.
I 've take a look for how to make it. It is pretty simple to do: [here](https://dzone.com/articles/executable-package-pip-install).
2 points:
* Who push the cod...I wanted to launch should pipeline without having to find path of script.
I 've take a look for how to make it. It is pretty simple to do: [here](https://dzone.com/articles/executable-package-pip-install).
2 points:
* Who push the code on pypi ?
* What project name set (because should is already taken) ? should-get ? shouldget ? Other ?
cc @magiraud @mikael-shttps://gitlab.inria.fr/vidjil/should/-/issues/70Correctly report test duration in .xml2022-01-26T00:21:37+01:00Mathieu GiraudCorrectly report test duration in .xmlhttps://gitlab.inria.fr/vidjil/should/-/issues/69Do not support end-of-life Python releases2022-01-25T22:47:15+01:00Mathieu GiraudDo not support end-of-life Python releases3 years 1/2 ago, our goal was to support Python 3.4 #59, that was then an [active Python release](https://www.python.org/downloads/).
Now even Python 3.6 is ` end-of-life`, released more than 5 years ago and with no security fixes, and ...3 years 1/2 ago, our goal was to support Python 3.4 #59, that was then an [active Python release](https://www.python.org/downloads/).
Now even Python 3.6 is ` end-of-life`, released more than 5 years ago and with no security fixes, and without any official Docker image #50
We could stick to provide support for active releases of Python, that would mean anything released in the 5 last years.https://gitlab.inria.fr/vidjil/should/-/issues/68Json, allow to test empty string value2021-09-08T11:59:23+02:00Mathieu GiraudJson, allow to test empty string valueSomething like `j: key[0]: ""` don't work.Something like `j: key[0]: ""` don't work.https://gitlab.inria.fr/vidjil/should/-/issues/67!OUTPUT_FILE with several !LAUNCH2021-04-06T09:43:15+02:00Mathieu Giraud!OUTPUT_FILE with several !LAUNCH
When there are several !LAUNCH, the existence for !OUTPUT_FILE is now checked after each !LAUNCH. This should not be the case.
When there are several !LAUNCH, the existence for !OUTPUT_FILE is now checked after each !LAUNCH. This should not be the case.https://gitlab.inria.fr/vidjil/should/-/issues/66Multiple occurrences with multiline2021-02-22T11:56:47+01:00Mathieu GiraudMultiple occurrences with multilineI noticed that one cannot check if multiple occurrences span on multiple lines.
For instance let's consider this [file `text`](/uploads/3fe1c69b21fc06465aef78432fb73067/text)
```
Twice the same
multiple lines
Twice the same
multiple l...I noticed that one cannot check if multiple occurrences span on multiple lines.
For instance let's consider this [file `text`](/uploads/3fe1c69b21fc06465aef78432fb73067/text)
```
Twice the same
multiple lines
Twice the same
multiple lines
```
And [this should](/uploads/40effdf9298c70ca7c7308bbb0e970dc/test.should) :
```
cat text
lr2:Twice the same\s*multiple lines
```
The output is
```
test.should
failed (1/2)
lr2:Twice the same\s*multiple lines
```
Meaning that one occurrence matched, not the second one.https://gitlab.inria.fr/vidjil/should/-/issues/65!NO_LAUNCHER and !REQUIRES may be not fully working anymore2022-01-25T20:36:12+01:00Mathieu Giraud!NO_LAUNCHER and !REQUIRES may be not fully working anymoreProbably since !20
See https://gitlab.inria.fr/vidjil/vidjil/-/issues/4460Probably since !20
See https://gitlab.inria.fr/vidjil/vidjil/-/issues/4460https://gitlab.inria.fr/vidjil/should/-/issues/62Add wilcards in json keys2020-12-04T18:13:43+01:00Mathieu GiraudAdd wilcards in json keysThe following expressions could be useful:
```
0:abc.*.def: foo
2:abc.**.def: foo
:abc[*].def: foo
```
(`**` could work for any number of nested keys)The following expressions could be useful:
```
0:abc.*.def: foo
2:abc.**.def: foo
:abc[*].def: foo
```
(`**` could work for any number of nested keys)https://gitlab.inria.fr/vidjil/should/-/issues/59Allow to parse for json keys with `.` inside2022-01-25T22:41:15+01:00Mathieu GiraudAllow to parse for json keys with `.` inside`'foo': {'0.01': 2}` can not be tested through `j:foo.0.01:2`.
We could have a way to protect `.` inside keys.`'foo': {'0.01': 2}` can not be tested through `j:foo.0.01:2`.
We could have a way to protect `.` inside keys.https://gitlab.inria.fr/vidjil/should/-/issues/58Distribute should through pip2020-08-07T18:25:46+02:00Mathieu GiraudDistribute should through piphttps://gitlab.inria.fr/vidjil/should/-/issues/57!OUTPUT_FILE and log files2020-08-07T16:44:27+02:00Mathieu Giraud!OUTPUT_FILE and log filesReported by @flothoni: when we use `!OUTPUT_FILE`, we do not have access the stdout/stderr log of the tested commands. Probably `.log` is badly named here: there could be both
- a `.log`, stdout/stderr
- and a `.out` for tested lines
...Reported by @flothoni: when we use `!OUTPUT_FILE`, we do not have access the stdout/stderr log of the tested commands. Probably `.log` is badly named here: there could be both
- a `.log`, stdout/stderr
- and a `.out` for tested lines
But should we have two files when we are testing stdout ? There won't be the same (stderr...)
(and #56)https://gitlab.inria.fr/vidjil/should/-/issues/56Remember log when there are several tests2021-09-21T12:55:37+02:00Mathieu GiraudRemember log when there are several testsWhen several commands/tests are run, we should keep the log of each file, either in one file, or in successive `.log.1` files.
This is currently not the case, at least when using `!OUTPUT_FILE`, as noted by @flothoni.When several commands/tests are run, we should keep the log of each file, either in one file, or in successive `.log.1` files.
This is currently not the case, at least when using `!OUTPUT_FILE`, as noted by @flothoni.https://gitlab.inria.fr/vidjil/should/-/issues/55Modifier to require to match all the json element / line2020-08-07T12:22:35+02:00Mathieu GiraudModifier to require to match all the json element / lineFrom #54 and !26
`j:foo:8` matches `{ 'foo': 8 }`, but also `{ 'foo': 0.8 }`, as we always look for an *expression* inside the values.
There should be a modifier to specify that we want to parse the whole element (or even the whole li...From #54 and !26
`j:foo:8` matches `{ 'foo': 8 }`, but also `{ 'foo': 0.8 }`, as we always look for an *expression* inside the values.
There should be a modifier to specify that we want to parse the whole element (or even the whole line when not using `j`).
cc @flothonihttps://gitlab.inria.fr/vidjil/should/-/issues/53Checks whether REQUIRES: with EXIT_CODES: actually work2022-01-25T22:48:57+01:00Mathieu GiraudChecks whether REQUIRES: with EXIT_CODES: actually workReported by @mikael-s.
See https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/669#note_350195Reported by @mikael-s.
See https://gitlab.inria.fr/vidjil/vidjil/-/merge_requests/669#note_350195https://gitlab.inria.fr/vidjil/should/-/issues/52Allows to ignore EXIT_CODE, or allow to mark as 'f' or 'a' an EXIT_CODE test?2020-06-04T12:01:35+02:00Mathieu GiraudAllows to ignore EXIT_CODE, or allow to mark as 'f' or 'a' an EXIT_CODE test?The `!EXIT_CODE:` directive creates an `ExternalTestCase`. There should be a way to specify that this test may fail, or is expected to fail, or at least to ignore these test.
~bikeshedding: something like `!EXIT_CODE: f0` ?The `!EXIT_CODE:` directive creates an `ExternalTestCase`. There should be a way to specify that this test may fail, or is expected to fail, or at least to ignore these test.
~bikeshedding: something like `!EXIT_CODE: f0` ?https://gitlab.inria.fr/vidjil/should/-/issues/50Use Docker to run the tests, image with python 3.42022-01-25T22:47:15+01:00Mathieu GiraudUse Docker to run the tests, image with python 3.4It would prevent issues like #49 of running tests on a server that may change over time.It would prevent issues like #49 of running tests on a server that may change over time.https://gitlab.inria.fr/vidjil/should/-/issues/48Provide an option to stop the tests when one commands fails2020-06-01T20:01:49+02:00Mathieu GiraudProvide an option to stop the tests when one commands failsThis would `foo ; bar` behave as `foo && bar`.
@mikael-s : `set -e` ?
Enabled by default ?
In some cases, we do not want this.
But what happens when there are commands on several lines ?This would `foo ; bar` behave as `foo && bar`.
@mikael-s : `set -e` ?
Enabled by default ?
In some cases, we do not want this.
But what happens when there are commands on several lines ?