Use simple response file format in test code. NFC #22976
Conversation
The simple one-line-per-element format is recommended these days.
| 'onlylist_b_response': ([], True, '["main","__original_main","foo(int, double)","baz()","c_baz","Structy::funcy()"]'), | ||
| 'onlylist_c_response': ([], False, '["main","__original_main","foo(int, double)","baz()","c_baz"]'), | ||
| 'onlylist_b_response': ([], True, 'main\n__original_main\nfoo(int, double)\nbaz()\nc_baz\nStructy::funcy()\n'), | ||
| 'onlylist_c_response': ([], False, 'main\n__original_main\nfoo(int, double)\nbaz()\nc_baz\n'), |
There was a problem hiding this comment.
In this case, isn't the original clearer actually? It avoids \nc and such, where the reader needs to think how to separate into tokens.
And isn't it good to keep testing for the older format, or do we have that testing elsewhere?
There was a problem hiding this comment.
See the PR description (I updated it). We have plenty of testing for old/new format.
There was a problem hiding this comment.
Sorry I missed that. Then I still think this would be clearer the other way, but I don't feel strongly.
There was a problem hiding this comment.
In this case, isn't the original clearer actually? It avoids
\ncand such, where the reader needs to think how to separate into tokens.
Its easier to read here in the python, but if you look at the test directory after the test runs and inspect the resp file, the one-element-per-line format is way easier to read.
I'd like to one day deprecate the old rsp json format.. (so not using outside of test_dash_s_list_parsing is a good first step)
There was a problem hiding this comment.
Its a little complex here because this python test file is trying to to encode the contetns of a file into a single-line-string in python, which will always look at little odd.
2 participants
The simple one-line-per-element format is recommended these days.
We have other tests that actually test both formats work (
test_dash_s_list_parsingandtest_dash_s_response_file_list)