| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
|
||
| #define TEST_CASE(F) (testcase(#F, F, argc, argv)) | ||
|
|
||
| static std::string writeFile(const char code[], std::size_t size, const std::string &filename) { |
There was a problem hiding this comment.
I feel that it's a good idea to avoid using real files in tests.
Sorry, something went wrong.
There was a problem hiding this comment.
In general I totally agree with you. But we allow the input of actual files so we should actually test this.
Sorry, something went wrong.
There was a problem hiding this comment.
I still feel skeptic. if we assume that the stream input is bug free then the test should work the same with a string input or a file. if we extrapolate this then this should be done in cppcheck also. I fear I don't like this.
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry for the late reply.
Keeping tests simple is great but I think there should be proper coverage and historically that is something we don't have in either Cppcheck or simplecpp. 😐
Also all the include files are always being read from the disk and not from memory. Not having any tests which rely on temporary files indicates that there is no coverage for reading includes at all. I have not looked into this yet.
So it seems instead of avoiding tests with files on disk we actually need to add much more.
Sorry, something went wrong.
There was a problem hiding this comment.
Having some system test that uses files is good but we do have some such system tests. Testing that APIs work as they should is out of scope.
Sorry, something went wrong.
There was a problem hiding this comment.
Without this I am not able to test the changes in #244. If that is fine with you I will try to finish up that PR without any unit tests.
I will prepare another PR to highlight with more tests to highlight the underlying testing issue.
Sorry, something went wrong.
There was a problem hiding this comment.
If that is fine with you I will try to finish up that PR without any unit tests.
yes I would prefer that in this case.
Sorry, something went wrong.
There was a problem hiding this comment.
Great.
After thinking about it a bit more the usage with Cppcheck could be considered an integration test.
Sorry, something went wrong.
There was a problem hiding this comment.
yes it's more like a integration test.
Sorry, something went wrong.
|
This could be implemented in the Python tests instead by making this modes available via simplecpp (as already is via -is). That would require to parameterize each invocation but I am not sure how to do this. @Tal500 any idea? |
Sorry, something went wrong.
|
Thinking about it I think this is still valid except for the file input. |
Sorry, something went wrong.
|
I removed everything which generates a file. I will add flags to the CLI to be able to use those in the Python tests but that won't have the same coverage as using it in the unit tests and might detect some issues only as in drive-by way (as experienced in #566). |
Sorry, something went wrong.
sorry for the very late reply. see https://github.com/danmar/simplecpp/blob/10c96815e402299da1d3ab1f753dda4c1b0b12f8/integration_test.py#L37-L39 |
Sorry, something went wrong.
No problem at all. Thanks for replying. I do get have parameterizing works but this requires every simplecpp call to gain an additional parameter so this needs needs something global. Possibly requiring a fixture (or whatever it is called in Python). BTW I moved that to #625. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
No description provided.