Test case - array. #22
Conversation
|
@pavreh is not clear to me what this tries to do. Is better to open an issue for discussion before submit PR. I finally get progress in felipec/sharness#14 so the final workflow is already on master You can see it applied to this PR on: https://github.com/albfan/bash-ini-parser/tree/wip/array Basically, tests are always marked as expected and test suite needs to know what is expected to fail with XFAIL_TESTS var. For a test to be useful it should check one thing at time (I split your test into several ones) But that's only for the PR part, as said is better to first discuss feature your looking for and its backward compatibility I submit your solution (without the breakage fix) into: https://github.com/albfan/bash-ini-parser/tree/wip/array-fix-whitespace-breakage and with fix into: https://github.com/albfan/bash-ini-parser/tree/wip/array-fix After discussing on issue, is expected some new info on https://github.com/albfan/bash-ini-parser#drawbacks as changes how that is parsed Hope all this stuff don't bothers you, as you see workflow evolves as PR came in, if something don't works for you, just said it |
|
This test case tests usability of the output ini file. The test work like this: 1) read sec1 var1 array from array.ini. The array works (${var1[1]} can be called). 2) Update and save var2 variable in sec2. It has nothing to do with var1 array in sec1 so it should not be impacted. 3) read sec1 var1 array from the created array.out. The array do not work (${var1[1]} can not be called) because var1 is a multi word variable, not an array. In other words, when an ini file goes through the parser, every array is changed to a multi word variable (even it is still commented as array). Yes, this test case tests both, original ini file and created ini file. Only the second part is important. I can modify the test so only the one thing will be tested. Using of arrays is marked as drawback but it is the main reason why I started to use this parser. There is written in Drawbacks chapter (readme) that "multiword value vars will be arrays...". So, this test 8 tests exactly this thing. That array is still array. We can add info into readme that value in quotes is a variable and value without quotes is an array. Workflow goes well. |
|
Hi, I rebase this on #35 (as I cannot rebase here, permissions?) multiword are not keeped, nor values with spaces. Still have to think about what is the spec we should follow |
No description provided.